Career Dashboard
Current Target Role: Cloud / DevOps Engineer (primary); Platform / MLOps Engineer (secondary)
Original Time-to-Hire Estimate: 3–6 months
Current Time-to-Hire Estimate: 2.5–5 months
Confidence Level: Medium
Skills Acquired: Terraform infra repo with modular structure, Dockerized microservice, GitHub Actions basic pipeline, README and runbook draft.
Remaining Skill Gaps: Kubernetes deployment to a managed cluster, observability integration, security hardening, interview scripting.
Today’s Objective
Create a compact, job‑aligned portfolio project that I can show in interviews and use as a basis for screening conversations. The emphasis was on packaging work into a narrative that non‑technical recruiters and hiring managers can quickly understand.
What I Worked On
I built a small project: a Python service that returns a JSON payload, containerized it, and wrote Terraform to provision networking and compute resources. I added a GitHub Actions workflow that builds the image, runs unit tests, and pushes the image to a registry on successful builds. I wrote a README that explains the architecture, the deployment steps, and a troubleshooting section documenting two issues and their resolutions.
What I Learned
Writing the README and runbook forced me to translate technical work into a narrative that hiring managers can quickly understand. Interviewers often ask for “tell me about a time you fixed X”; having a documented incident and a clear remediation path makes those answers crisp and credible. I also learned that observability is a recurring ask in job descriptions, so I adjusted the project to include a basic Prometheus exporter and Grafana dashboard.
Skills Acquired — Practical Details and Why They Matter
- GitHub Actions CI Pipeline
What it is: A CI workflow that runs on commits or pull requests to build artifacts, run tests, and optionally deploy.
What I did: I created a workflow that builds the Docker image, runs unit tests, and pushes the image to a registry on successful builds.
Why it matters: CI pipelines are how teams ensure code quality and reduce manual steps. Demonstrating a working pipeline shows you can integrate testing and deployment automation—an immediate productivity multiplier for teams. - Runbook and Troubleshooting Documentation
What it is: A runbook is a concise operational guide listing common failure modes, commands to inspect logs, and remediation steps.
What I did: I wrote a runbook that lists failure modes, commands to inspect logs, and remediation steps, and included a short postmortem for a lab incident.
Why it matters: Clear documentation reduces mean time to recovery and demonstrates communication skills. Hiring managers value engineers who can transfer knowledge and reduce operational risk.
Market Observations
Observability and incident response are frequently mentioned in job descriptions. Adding a Prometheus exporter and Grafana dashboard to the portfolio will let me speak credibly about monitoring, alerting, and SLOs—topics that often separate good candidates from great ones.
Resources Reviewed
I reviewed example GitHub repos from mid‑level infra engineers and blog posts on writing effective runbooks. These helped me present work to non‑technical stakeholders and improved the clarity of my documentation.
Progress Against Plan
On track and slightly ahead. The portfolio is functional and documented; next is to add monitoring and a short walkthrough video and to prepare concise talking points for screening calls.
Strategy Change
Added observability to the minimum viable portfolio after seeing it repeatedly in job descriptions. No major pivots otherwise.
Next Steps
Add Prometheus metrics and a Grafana dashboard, record a 5‑minute walkthrough video, and prepare a one‑page “talking points” doc for screening calls. Begin applying to targeted roles and reach out to recruiters with a concise message and a link to the repo.
Reflection
A small, well‑documented project that demonstrates troubleshooting, automation, and observability will open more doors than an incomplete, flashy AI demo. I’ll keep AI work as a small add‑on rather than the core, and I’ll let recruiter feedback guide whether to expand the AI component.
