SRE interview prep: a 4-week plan built on practice, not flashcards

Most SRE interview preparation advice is a reading list. Read the Google SRE book, memorize the difference between SLI and SLO, know what an error budget is. That material is worth knowing, but it's the part of the interview you were probably going to pass anyway. The part that sinks candidates is the hands-on portion: a server with load average 90, a pod that won't schedule, a service that's down and a clock that's running.

You don't read your way out of that. You train for it. Here's a four-week plan that treats SRE interview preparation like exercise: specific drills, increasing load, measurable progress.

Week 1: Linux fluency under a timer

Everything in SRE work bottoms out in Linux, and interviews know it. This week is about making the basic diagnostic toolkit automatic.

Daily drill (30–45 min): spin up a throwaway VM or container and work through one fault class per day:

Disk: fill a disk, find the culprit, learn why du and df disagree when a deleted file is still held open (lsof +L1).
CPU/load: create load with stress or a fork bomb in a cgroup, then explain the number, our guide to high load average covers what it actually measures, including D-state processes.
Memory: trigger the OOM killer, read the dmesg forensics.
Ports/processes: bind a port twice, find the owner with ss -ltnp.
Services: break a systemd unit (bad ExecStart path), fix it with systemctl status → journalctl -xeu.

Fluency bar: ps, top, ss, lsof, df, du, free, vmstat, iostat, dmesg, journalctl, strace on a known binary. If you reach for a search engine to remember the flag, add it to a personal cheat sheet, then drill until the cheat sheet is unnecessary.

Week 2: Kubernetes failure modes

One fault class per day, self-inflicted on a kind cluster you can destroy without ceremony:

Day 1: image problems (bad tag, private registry) → ImagePullBackOff diagnosis.
Day 2: crash loops - config errors, OOMKilled, exit codes.
Day 3: scheduling - requests too big, taints, node affinity.
Day 4: services and DNS - wrong selector, empty endpoints, broken CoreDNS.
Day 5: probes - a liveness probe that kills a healthy-but-slow app.

The drill is always the same: inject, start the timer, diagnose out loud, fix, verify from the user's perspective, write three lines about what the fastest path would have been.

By Friday you should be able to take an arbitrary broken pod to a root-cause category in five minutes.

Week 3: full incident scenarios

Now combine the layers. This week, work on scenarios where you don't know which layer is broken - that ambiguity is the actual job, and the actual interview.

Free options: SadServers has excellent pre-broken Linux scenarios with a pass condition; KillerCoda has interactive Kubernetes labs. Faultybox sessions add the thing self-practice can't give you - grading and a replay, so you can see whether your process looks as methodical from the outside as it felt from the inside.

Three scenarios this week, full 45-minute timebox each. After each one, review with the harshest question: at which minute did I have enough evidence to know the answer, and how much later did I actually act on it? The gap between those two timestamps is the thing this week shrinks.

Also this week: practice recovering from being wrong. Deliberately chase a bad hypothesis for two minutes, then practice the pivot - say "that's ruled out, updating my model", and move. Interviewers score recovery from wrong turns heavily, because production does too.

Week 4: communication and the meta-round

The last week is about the layer that multiplies everything else: narration.

Think-aloud drills: re-run two scenarios from week 3, but record yourself and narrate continuously. Listen back. Painful, effective. We wrote a full guide to think-aloud debugging with phrases that work.
The incident story: prepare two real incidents from your past in a detect → diagnose → mitigate → root-cause → prevent structure, three minutes each. Every SRE loop includes "tell me about an outage". Have the story with the wrong turns left in, a story where you were never wrong reads as edited.
SLO vocabulary: one evening is genuinely enough for SLI/SLO/error budget/burn rate if you've done the practical weeks. These concepts stick better when you've just spent three weeks generating the telemetry they summarize.

The SRE interview preparation gate: a self-assessment

Before the real interview, all of these should be true:

I can triage an unknown slow server in ten minutes with a method, not a vibe.
I check evidence before changing anything, every time, even under a timer.
I state hypotheses out loud and say when they're ruled out.
I verify fixes against the symptom and clean up after myself.
I have two incident stories I can tell in three minutes without rambling.

FAQ

How much time does SRE interview preparation take per day? This plan is 30–60 minutes on weekdays with two longer (45–90 min) scenario sessions in weeks 3–4. Consistency beats volume: five short deliberate sessions outperform one Saturday marathon.

Should I prepare for coding rounds too? Most SRE loops include one coding round, usually scripting-flavored rather than LeetCode-hard. Being able to write a clean log parser in Python under 30 minutes covers a lot of it. Don't let DSA grinding cannibalize the hands-on weeks - that's the round that differentiates you.

What if I've never been on-call? You can build most of the skill anyway - the drills above don't require a pager, just a lab. Say so honestly in the interview and show the reps instead. A candidate who has broken and fixed fifty lab systems methodically beats a candidate with two years of pager duty and no method.

Is the Google SRE book necessary? It's the shared vocabulary of the field, so skim it at minimum (SLOs, toil, postmortems). But nobody fails an interview for not finishing the book. People fail interviews in the terminal.