SRE and DevOps Interviews: A Preparation Guide
SRE and DevOps loops are their own species: part software interview, part systems autopsy, part crisis simulation. A strong backend engineer can fail one badly by preparing as if it were a standard SWE loop — the coding bar is real but different, and half the rounds have no equivalent elsewhere. Here's the anatomy and how to train for each part.
The rounds
A typical loop: a coding screen (automation-flavoured), a Linux/systems internals round, a troubleshooting/incident scenario, a system design round with a reliability lens, and a behavioural round centred on incidents and on-call. Google-style SRE loops add a "non-abstract large system design" (NALSD) round — design it with real machines, real numbers, real failure math.
Coding: automation, not algorithms golf
Expect practical scripting over dynamic-programming trivia: parse this log and summarise error rates; implement a retry with exponential backoff and jitter; walk a process tree; batch-rename/verify a fleet of config files. Python and Go dominate. The bar is fluent, correct automation — clean handling of edge cases (empty input, malformed lines, timeouts) matters more than asymptotic cleverness. If you only train one thing, train writing small correct programs against messy text, fast.
The Linux round
Interviewers walk down the stack until you stop having answers — the honest depth marker:
- What happens between typing a URL and the page rendering? (DNS, TCP, TLS, HTTP — with real detail at each hop.)
- What does
fork()/exec()actually do? Zombies vs orphans? What is an inode? - The load average is 40 on a 8-core box but CPU is idle — what's happening? (I/O wait, D-state processes.)
- What's in
/proc? How would you find what's holding a deleted file open? (lsof, fd tables.) - Walk me through memory: RSS vs virtual, page cache, what the OOM killer chooses and why.
Preparation is genuinely fun here: take a Linux box, break it, and narrate your own debugging with strace, perf, ss, iostat, dmesg. Explaining out loud is the skill being graded — the same narration muscle every mock interview builds.
The troubleshooting scenario
The signature SRE round: "It's 3am. Checkout latency has tripled. Go." The interviewer plays the system; you ask questions, form hypotheses, and drive to root cause. The rubric is your method, not the answer:
- Clarify impact and scope first (all users? one region? since when? what changed?).
- Stabilise before root-causing — rollback, shed load, fail over. Say explicitly that mitigation beats diagnosis while users are hurting.
- Hypothesise → test cheapest-first → narrow. Announce your reasoning at every step; silent thinking scores zero.
- Root cause, then systemic prevention — not "be more careful", but a guardrail, alert or rollout change.
Candidates fail by tunnelling (one hypothesis, twenty minutes) or by touching nothing until they're certain. Breadth-then-depth, mitigation-first, out loud.
SLOs, error budgets, and design-for-failure
The conceptual layer that separates SRE from "ops with better tooling" — be fluent in: SLI vs SLO vs SLA (measurement, target, contract); why 100% is the wrong target and what an error budget buys you (a shared currency between feature velocity and reliability); alerting on symptoms not causes, and on budget burn rate rather than static thresholds; toil and its automation budget. In the design round, apply it: "given a 99.9% SLO, this dependency chain already spends the budget — so we cache/degrade here." That single move — turning reliability from vibes into arithmetic — is the strongest signal in the loop.
The behavioural round
Incident war stories are the medium: the worst outage you owned, an incident you made worse, a postmortem that changed something real, how you've handled unsustainable on-call. Use STAR, keep it blameless (systems fail, processes fail, "the intern did it" auto-fails you), and quantify — minutes of downtime, users affected, burn-rate before and after. A story bank of five incidents covers the round.
Prepping for an SRE or platform loop? Get matched with a coach who has run on-call and hiring at scale — incident scenarios included.