Resumes for Infrastructure and Platform Roles

Product engineers have an easy time writing resumes. They shipped a feature, users used it, there’s a screenshot.

Infrastructure, platform, and SRE work has the opposite shape. Its success condition is usually that nothing happened: the service stayed up, the migration was invisible, the on-call rotation got quiet. When you sit down to write bullets about a year of that, the page can feel oddly empty — you did a great deal and none of it looks like an achievement in the standard template.

It is an achievement. It just needs a different framing, and there are about five that work.

Frame 1: the state change

Most infrastructure work moves a system from one state to a better one. Name both states.

Took the deploy process from a manual runbook with a 40-minute window and a required approval, to a merge-triggered pipeline that ships in under six minutes with automated rollback.

Before and after, both concrete. The reader doesn’t need a percentage; the shape of the change carries it. This frame works for CI, deploys, environments, provisioning, developer setup time — anything that used to be painful and now isn’t.

Frame 2: the thing that stopped happening

Reliability work is best described by what it eliminated.

Cut the on-call rotation from an average of nine overnight pages a week to under one by fixing the two alerts responsible for most of them and rewriting the rest to page on symptoms rather than causes.

Eliminated the class of incident caused by unbounded queue growth by adding backpressure at the ingest layer and a dead-letter path with alerting.

Both of these describe an absence, which is exactly what reliability work produces, and both are perfectly legible to anyone who has been on call. The second one also shows you think in terms of classes of failure rather than individual bugs, which is a strong signal.

Page counts, incident counts, and alert volumes are measurable and you’ll have them from whatever paging tool you used. These are among the most defensible numbers available to any engineer — use them.

Frame 3: the risky operation that went fine

Migrations and cutovers are the highest-stakes work most infrastructure engineers do, and “it worked” undersells it badly. What makes them impressive is the method, not the outcome.

Moved 40 services from self-managed Kubernetes to EKS over four months. Ran both control planes in parallel behind a weighted DNS split, migrated in batches by blast radius, and kept a tested rollback for every batch. No customer-facing incidents.

Migrated the primary Postgres instance from a 4-year-old major version with a logical replication cutover; rehearsed the switchover three times in staging, executed in a 90-second write pause.

Include the safety mechanism. “We rehearsed it three times” and “we kept a tested rollback” tell a hiring manager how you’d handle their risky operation, which is the actual thing they’re hiring for. A migration described only as “successfully migrated X to Y” is a claim; a migration described with its method is evidence.

Frame 4: the platform’s users

Platform teams have internal customers, and internal customers are still customers. Describe your platform the way you’d describe a product.

Built and ran the internal service scaffolding used by 14 teams — a create-service template with CI, observability, secrets, and deployment wired up, taking a new service from repo creation to production in about a day rather than a fortnight.

Ran quarterly office hours and wrote the migration guides for three breaking platform changes; got 90% of consumers onto the new client library before deprecating the old one.

That second bullet describes a genuinely hard part of platform work — getting other engineers to do something — and it’s the kind of thing that never makes it onto resumes because it doesn’t feel technical. It absolutely counts, and platform hiring managers care about it a great deal.

Adoption numbers, team counts, and service counts are honest, easy figures. Use them.

Frame 5: the cost line

Cloud spend is one of the few things in engineering that comes with an actual monthly invoice, which makes it one of the few places a dollar figure is fully defensible.

Reduced monthly AWS spend from roughly $48k to $31k over two quarters — rightsized the over-provisioned RDS fleet, moved batch workloads to spot, and deleted a Redis cluster and two environments nobody had used since 2023.

If you saw the bill, cite the bill. If you didn’t, don’t estimate — describe what you removed instead (“deleted two unused environments and an idle Redis cluster”) and let the reader infer.

What not to do

Don’t list technologies as accomplishments. “Worked with Kubernetes, Terraform, Prometheus, and Datadog” is a skills section that has wandered into the wrong part of the page. Those names belong in the skills block, or inside a bullet that says what you did with them.

Don’t claim uptime you can’t source. “Maintained 99.99% uptime” is extremely common and usually unverifiable — often the person writing it wasn’t measuring against a defined SLO, and sometimes the figure comes from a dashboard covering a component rather than the service. If you had a real SLO and hit it, say so precisely: “held the 99.9% availability SLO for the checkout path across four quarters, including two provider outages.” If you didn’t have one, describe the reliability work directly.

Don’t hide behind the passive voice. “The infrastructure was migrated to Terraform” — by whom? Infrastructure resumes are unusually prone to this, probably because the work is collective. Name your part.

Don’t skip the boring, valuable work. Runbooks, disaster recovery testing, access reviews, dependency and version upgrades, documentation. These are hard to make sound exciting and they are exactly what a team drowning in operational debt is hiring for. One bullet: “introduced quarterly DR exercises; the first one found and fixed three restore-path failures that had been silently broken.”

Titles and specialism

Infrastructure job titles are chaotic — SRE, DevOps Engineer, Platform Engineer, Infrastructure Engineer, Production Engineer, Cloud Engineer — and they mean different things at different companies.

Two practical notes. Use your real title, but if it’s unusual, add a short clarifier: DevOps Engineer (platform team; owned CI/CD and Kubernetes). And in your summary line, describe the work rather than the label: “infrastructure engineer, mostly Kubernetes and Terraform on AWS, with real on-call ownership” is more informative than any of those titles.

Be honest about which side of the line you sit on, too. Some roles are heavily software engineering with an infrastructure domain; others are operations-first. Both are legitimate, and applying to the wrong one because your resume was ambiguous wastes everyone’s time.

The reader you’re writing for

Your resume will very likely be read by someone who has been paged at 3am and would like that to happen less often. Everything above is really one instruction: write so that person can tell you’d reduce their pages rather than add to them.

That’s why the method matters more than the outcome, why the absence of incidents is worth stating plainly, and why “I rehearsed the cutover three times” is one of the most persuasive sentences you can put on an infrastructure resume.