DevOps and SRE CVs share a problem with data engineering CVs: they read like a stack inventory. Kubernetes, Terraform, Prometheus, Argo, Datadog, Jenkins — the recruiter scans the list and learns nothing about whether you can actually keep things running.

What the hiring manager wants to know is harder: did you reduce outages, did you cut deploy time, did you survive Black Friday without paging the whole team. That's the CV that gets called.

What hiring managers actually look for

Three signals, in order of weight:

1. Reliability outcomes. SLO/SLA numbers, error budget management, MTTR cuts. Numbers from production systems with real users.
2. Scale. Requests per second, cluster size, deployment frequency, infra cost. "Managed 200 microservices" is not the same as "managed 12 microservices" — and both beat "managed microservices."
3. On-call and incident response. Page rate, postmortem cadence, runbook coverage. The unglamorous part of the job is the part the hiring manager has been burned on.

The stack list comes after. ATS systems look for the keywords, so include them, but never in place of an outcome.

The structure that works

One page if you have under 6 years, two pages otherwise. Order:

1. Headline — one line: role, years of experience, a domain signal ("DevOps engineer · 7 yrs · multi-region AWS").
2. Skills — 3 rows max: cloud / IaC / monitoring; languages; tooling. Comma-separated, no proficiency bars (they don't survive ATS parsing and look childish).
3. Experience — 4–6 bullets per recent role, fewer for older ones.
4. Projects / open source — only if you have something with real traffic or stars. A side project nobody uses doesn't help.
5. Certifications — CKA, CKAD, AWS / GCP / Azure equivalents. Date them; expired certs read worse than no certs.
6. Education — last on the page unless you graduated within the past 2 years.

Writing bullets that actually land

The formula recruiters and hiring managers respond to: action + system + metric + outcome.

Weak: Maintained Kubernetes clusters.

Stronger: Maintained 4 GKE clusters serving 12k RPS p99 across 2 regions, kept availability at 99.97% across 18 months.

Stronger still adds the what changed because of you: Maintained 4 GKE clusters serving 12k RPS p99 across 2 regions; introduced multi-region failover that reduced regional-outage user impact from 40 minutes to under 90 seconds.

The last version is what you keep. It shows the system, the scale, and the work you did to bend the curve.

Numbers worth quantifying

DevOps and SRE work is unusually number-rich. Bullets without metrics here look lazy. Things worth surfacing:

• Uptime / SLO numbers. "99.95% over 12 months" beats "high availability."
• MTTR. "Cut MTTR from 47 min to 12 min over 2 quarters."
• Deploy frequency. "Released 22×/day via rolling deploys."
• Infra cost. "Reduced cloud spend 31% YoY without instance reshape" or "saved $480k/year by rightsizing Redis."
• Throughput. RPS, events per second, queue depth at peak.
• Cluster and fleet size. Pod count, node count, multi-region split.
• On-call load. "Reduced pages per week from 9 to 2 by adding alerting on leading indicators."

If you don't remember the exact numbers from two years ago, get the order of magnitude right. A wrong order of magnitude (1k vs 10k RPS) gets caught instantly in the interview; an honest "around 10k" doesn't.

What to cut

Three common sources of CV bloat for this role:

• Multi-row tool inventories. "Docker, Kubernetes, Helm, Kustomize, ArgoCD, FluxCD, Jenkins, GitLab CI, GitHub Actions, CircleCI, Spinnaker, Buildkite, ConcourseCI, Drone, TeamCity" — pick 6 you actually use, drop the rest.
• Certifications older than 5 years that weren't renewed. They flag stale skills more than they help.
• Generic responsibilities. "Responsible for the production environment" — every DevOps engineer is. Replace it with what you specifically did.
• Soft-skill bullets. "Strong communicator" — the on-call rotation will reveal communication skills faster than your CV.

Tailoring for SRE vs DevOps vs Platform Engineer

The titles overlap but the emphasis shifts.

• SRE roles — lead with reliability math: SLO/SLI definition, error budget, toil reduction, capacity planning. Show the policy layer, not just the tooling.
• DevOps engineer roles — lead with delivery: pipelines, deploy frequency, lead time, infra as code coverage.
• Platform engineer roles — lead with developer experience: self-service abstractions you built, internal customers, paved-path adoption rates.

You'll often apply to roles that mix two of these. The fix isn't to write three CVs — it's to keep one master CV with all your strongest bullets and pick the 4–6 that match each role's emphasis.

If you keep your experience in a structured tool (LinkedIn, Postulit, anywhere with tagged bullets) it's trivial to swap the front-loaded bullets per application without rewriting the document each time.

On-call sections are not optional

Almost every DevOps/SRE CV underplays the on-call story. The hiring manager has been on-call themselves and is looking for someone who has survived it without burning out or being the one paging others.

A two-line on-call subsection at the bottom of each role is enough:

On-call: 1-week primary every 5 weeks across a 4-engineer rotation. Co-authored the team's runbook (24 services). Reduced unactionable pages from ~40% to ~8% by tuning alert thresholds and ownership routing.

That tells the reader more about you than any tool list.

Sample bullet rewrites

Before: Worked on Terraform and AWS infrastructure.

After: Owned the Terraform monorepo across 18 AWS accounts; introduced module versioning and review pipeline that cut bad deploys from ~1/week to <1/month.

Before: Set up monitoring with Prometheus and Grafana.

After: Built the Prometheus + Grafana monitoring stack from zero for 64 services; introduced SLO burn-rate alerts and cut false-positive page volume by 73% in the first quarter.

Before: Migrated services to Kubernetes.

After: Migrated 36 services from EC2 to EKS over 7 months; designed the rollback strategy that kept the 12 monolithic services available throughout, with zero customer-facing incidents during the cutover window.

The pattern is the same: name the system, quantify the work, end with the outcome.

DevOps and SRE CVs are evaluated by people who have done the job. They can smell tooling without context in two seconds. Lead with what stayed up, what got faster, and what cost less because of your work — the stack list is the trailing evidence, not the headline.