Your DevOps resume — turning 90 days into bullets

Turning 90 days into a resume: impact bullets, grouped skills, three projects

Section 1 of 5 · ~3 min

You’ve built real things: linkstash containerized with Docker, deployed to AWS, then run on Kubernetes. The resume is where that work turns into a job — and it has two readers, both merciless. A human recruiter skims it in about six seconds, scanning for shape, titles, and two or three strong lines before deciding whether to read on. Before any human sees it, an Applicant Tracking System (ATS) parses your file into fields and matches its text against the job description’s keywords. Fail either reader and a great 90 days never gets read.

Three things carry a first DevOps resume: impact-first bullets, a grouped skills section, and your projects.

Impact-first bullets. A weak bullet names a duty — “Used Docker to run an app.” It only proves you were in the room. A strong bullet proves you changed something: an action verb, what you built, and a measurable result with the tech. “Containerized a FastAPI service with a multi-stage Dockerfile, cutting image size 60% (900 MB → 360 MB).” Same work; one reads as a task, the other as an outcome a hiring manager can picture.

The formula that makes this repeatable is the XYZ bullet, popularized by Laszlo Bock, Google’s former head of People Operations: “Accomplished [X], as measured by [Y], by doing [Z].” X is the result, Y is the number, Z is how you did it. Push every line through it and the metric can’t hide.

Real world: A resume bullet is a billboard you pass at 100 km/h, not a page in a manual. You get one line and one glance to land a single claim — what changed, and by how much. “Responsible for containers” is a billboard with an address and no offer; “cut image size 60%” is the number a driver still remembers a mile later. Write every bullet as if the reader will only ever see that one line.

Grouped skills. Don’t spray forty tools across one paragraph — that’s noise to a human and flat, unweighted keywords to an ATS. Group by area: Linux, Containers, Kubernetes, IaC, CI/CD, Cloud, Observability. Grouping does two jobs at once — a recruiter reads your breadth in one glance, and every keyword lands in a category the parser understands. The rule: list only what you could defend on a whiteboard.

Projects as the spine. With no DevOps title yet, your projects are the experience section. Your three linkstash builds tell a story a reviewer loves — Docker → AWS → Kubernetes, one app climbing the stack. Give each a name, one line of what it does, the stack, a metric, and a live GitHub link, so the claim is one click from proof.

One resume does not fit every job. The six-second skim and the ATS both reward a resume that mirrors the posting: if the job description says “Terraform” and “observability,” those exact words — where they’re true — must appear in your skills and bullets. Keep a master resume with every bullet, then cut and reorder per application so the top third answers this job. That’s not gaming the filter; it’s making the match the reader is already hunting for impossible to miss.

Hands-On Lab

Section 2 of 5 · ~2 min

No terminal today — the artifact is your resume. Open a blank doc and build four pieces in order: your project bullets, a rewrite drill, a grouped skills block, and a projects section wired to your repos. Steal the numbers from your own 90 days; where you don’t have a real number, go measure it before you write the line. Budget about 30 minutes.

# Project 1 — linkstash on Docker (weak -> strong)
WEAK:   Used Docker to containerize the app.
STRONG: Containerized a FastAPI service with a multi-stage Dockerfile,
        cutting the image 60% (900 MB -> 360 MB) and build time from ~4 min to 90 s.

# Project 2 — linkstash on AWS (weak -> strong)
WEAK:   Deployed the app to AWS.
STRONG: Deployed the container on AWS ECS Fargate behind an Application Load
        Balancer, with RDS Postgres across two AZs — rebuildable from scratch
        in under 5 minutes.

# Project 3 — linkstash on Kubernetes (weak -> strong)
WEAK:   Ran the app on Kubernetes.
STRONG: Ran linkstash on a k3s cluster with a Deployment, Service and ConfigMap;
        verified self-healing by killing a pod and watching it reschedule in ~8 s.

# Bonus bullet — the pipeline that ties them together (weak -> strong)
WEAK:   Set up GitHub Actions.
STRONG: Automated build-test-push with a GitHub Actions workflow, cutting manual
        release steps from 6 to 1 (git push) and blocking merges on failing tests.

# Skills — grouped by area, only what you can defend on a whiteboard
Linux:          Ubuntu 24.04, bash, systemd, ss/ip/dig, file permissions
Containers:     Docker, multi-stage builds, docker compose, image registries
Kubernetes:     k3s, Deployments, Services, ConfigMaps, kubectl, self-healing
IaC:            Terraform 1.9 (also OpenTofu), reproducible provisioning
CI/CD:          GitHub Actions (build, test and push workflows)
Cloud:          AWS (EC2, ALB, security groups, IAM basics)
Observability:  logs, health checks, docker/kubectl debugging

# Projects — the spine of the resume (name - what - stack - metric - link)
linkstash — a self-hostable URL shortener.
  Docker:      multi-stage image, 360 MB     - github.com/<you>/linkstash
  AWS:         Fargate + ALB + RDS, 2 AZs     - github.com/<you>/linkstash-aws
  Kubernetes:  k3s, self-healing Deployment   - github.com/<you>/linkstash-k8s

# Point each resume link at a stable release, not a moving main branch.
git tag -a v1.0.0 -m "linkstash: resume snapshot"
git push origin v1.0.0
# Output:
#  * [new tag]         v1.0.0 -> v1.0.0

# Grab the exact remote URL so the link on your resume is copy-paste correct.
git remote get-url origin
# Output (yours will differ):
# https://github.com/<you>/linkstash.git   (drop the .git for the human-facing link)

Read your four bullets back cold: does each one name a result and a number, or just a task? If a line would still be true for someone who only sat next to you while you worked, it’s a duty — send it back through XYZ until it isn’t.

Common Errors & Fixes

Section 3 of 5 · ~3 min

These are the mistakes that quietly sink a strong candidate’s resume before anyone reads the good part. Read each one against your own draft.

Common error: Bullets that describe duties instead of impact — “Responsible for managing Docker containers,” “Worked on CI/CD pipelines.”

Why: A duty says what your job was, not what changed because you did it. Every other candidate for the same role has the identical duties, so the line does nothing to separate you — and a six-second skim slides straight past a bullet with no verb-and-number to catch the eye.

Fix: Rewrite each with the XYZ formula — an action verb, the thing you built, and a measured result. “Responsible for Docker” becomes “Containerized a FastAPI app with a multi-stage build, cutting image size 60%.” If you can’t attach a number yet, go measure it before you write the line.

How you’d catch it: Read each bullet and ask “would this still be true for someone who just watched me work?” If yes, it’s a duty. Any line starting with “Responsible for,” “Worked on,” or “Helped with” is a duty in disguise.

Common error: A skills section that lists thirty tools in one wall of text, none of them tied to anything the candidate actually shipped.

Why: A long, ungrouped list reads as noise to a human and as flat, unweighted keywords to the ATS — and it invites the one question that sinks people: “You listed Kubernetes; show me where you used it.” A tool you can’t defend on a whiteboard is a liability, not an asset.

Fix: Group skills by area (Linux, Containers, Kubernetes, IaC, CI/CD, Cloud, Observability) and list only what maps to a project or a lab you actually ran. Fewer, defensible skills beat a long list you’ll get caught on.

How you’d catch it: For every tool on the list, point to the exact project bullet or repo that proves it. Anything with no anchor comes off the resume.

Common error: Sending the same resume to every posting, ignoring the exact words each job description asks for.

Why: The ATS ranks you on how well your text matches this posting, and a recruiter skims for the terms in their own ad. A resume that says “infrastructure automation” when the job description says “Terraform” scores as a weaker match even when you did the identical work — the machine matches strings, not synonyms.

Fix: Keep one master resume with every bullet, then tailor per application: mirror the posting’s exact terms where they’re true, and reorder so the top third answers this job. That’s not keyword-stuffing — it’s making a real match easy to see. Never claim a keyword you can’t back up in the interview.

How you’d catch it: Paste the job description and your resume side by side and highlight the overlap. If the posting’s core tools aren’t in your skills or bullets — and you’ve genuinely done them — you left an easy match on the table.

Resume and Project Interview Questions

Section 4 of 5 · ~1 min

Your resume is the interviewer’s script — every bullet is a door they can open, so rehearse walking through your three projects out loud before anything else. Cover each answer, say your own version first, then compare. The four questions and answers render right after this note.

Go Deeper

Section 5 of 5 · ~1 min

Optional extras if you have ~25 more minutes:

• 5 min — Read your resume in six seconds flat and note whatever your eye lands on first; that’s what a recruiter sees. If it isn’t your strongest bullet, reorder so it is.
• 10 min — Take one real DevOps job posting, list its ten most-repeated keywords, and check each against your resume — mark which you can honestly claim and which you can’t yet.
• 10 min — Rewrite every remaining duty bullet through XYZ until each carries a verb and a number; if no number will come, that’s a project gap to close, not a line to fake.