Site Reliability Engineering interviews have a distinct flavour: they care less about clever algorithms and more about whether you can keep complex systems alive, reason about failure, and stay methodical when things break. A lot of the interview is essentially a controlled fire drill.
What tends to come up
- Reliability fundamentals: SLOs, SLIs, error budgets — and what they mean in practice, not just as definitions.
- Troubleshooting at scale: “Latency just doubled across the fleet — go.” A structured debugging method beats a lucky guess.
- Incident response: how you triage, mitigate, communicate, and run a blameless postmortem.
- Systems + Linux depth: how things actually work under the hood — networking, processes, resource limits.
- Design for failure: redundancy, graceful degradation, blast-radius thinking.
The troubleshooting question is the centrepiece
You'll get an open “something's wrong, find it” scenario. They're grading your method. Here's what a strong answer sounds like on the classic prompt.
“First I check scope: is it one service, one region, one endpoint, or everything? That immediately halves the search space. Say the dashboards show it's one service, all regions — so it's the service or a shared dependency, not the network.
Next, what changed? Deploys, config, traffic, or a dependency. I line up the latency graph against the deploy timeline and traffic volume. If latency rose without a deploy and without a traffic spike, I'm suspicious of a downstream dependency — a slow database, a degraded cache.
I follow the request path and check each hop's latency — the cheapest signals first, the ones already on a dashboard. Say the database's query latency climbed at the same moment: now I look at slow queries, connection pool saturation, a missing index after a data-growth threshold. I form the hypothesis out loud — 'the cache hit-rate dropped, so we're hammering the DB' — and say how I'd confirm it in one query.
Meanwhile, error budget: if this is burning budget fast, I mitigate now — shed load, scale the dependency, or roll back the suspect change — before I finish the root cause. Reliability first, curiosity second.”
That's the whole signal: scope it, ask what changed, follow the path with cheap signals, hypothesise, and mitigate against the error budget rather than chasing a perfect diagnosis while users suffer. It's the same calm, ordered reasoning a DevOps incident round rewards — the roles overlap heavily.
1. Scope: one service / region / endpoint, or everything? 2. What changed? Deploy, config, traffic, dependency. 3. Follow the request path — cheapest signals first. 4. Hypothesis out loud + how you'd confirm it in one step. 5. Error budget check: mitigate now if it's burning fast.
Error budgets, said simply
Expect to be pushed on error budgets, because they reveal whether you think like an SRE. The plain version: an SLO defines the reliability you promise (say 99.9%), and the error budget is the allowed unreliability (the other 0.1%). When the budget's healthy, ship features fast. When it's exhausted, you slow down and spend effort on reliability instead. It's a shared, quantitative lever for the “velocity vs stability” argument — and saying that, rather than reciting a definition, is what lands.
What changes by level
Junior
Solid fundamentals and a sensible method. In a troubleshooting scenario, checking scope, looking at the obvious signals, and knowing when to escalate is a strong pass. You're not expected to design the reliability strategy — just reason cleanly and not panic.
Intermediate
Drive the incident and the design. Reason about SLOs and error budgets as tools you'd actually use, justify mitigation choices, and handle “what if that's not it?” without stalling. You own the method end to end.
Senior or staff
It's about systems and organisation. How do you set SLOs with product, reduce toil, design for graceful degradation, and build a culture where postmortems are blameless and actually change things? They want blast-radius thinking and the human side of reliability, not just a clean debug.
The remote format
Usually a call with screen-share and a shared doc or diagram. As with any live technical round, narrate — say your hypothesis before you chase it, and think out loud while you scan a dashboard. That spoken, structured reasoning is the entire signal, and it's the first thing nerves take away. The out-loud narration habit transfers directly.
Chasing an elegant root cause while the error budget burns. In a real incident and in the interview, the reliability-first instinct — mitigate now, diagnose fully after — is exactly the judgment they're probing. Say it out loud: “this is burning budget, so I'd stabilise first.”
- Can you explain SLO, SLI, and error budget as tools, not definitions?
- Can you run a troubleshooting scenario from scope to mitigation, out loud, on a timer?
- Do you lead with scoping and “what changed?” before diving deep?
- Do you mitigate against the error budget before chasing root cause?
- Can you talk about blameless postmortems and reducing toil for senior rounds?
Pick a failure — “error rate spiking on one service” — set a 15-minute timer, and talk through it from scope to resolution as if you're in the war room. Record it and play it back: did you scope before you dived, and mitigate before you chased the perfect diagnosis? Those two reflexes are the whole exam, and they only get automatic with reps.
The throughline is judgment under pressure, expressed verbally. Run mock incident scenarios out loud, on a timer, until the calm narration is your default — and if you're prepping the broader infra loop, pair this with the realistic technical prep plan so design and behavioural rounds don't ambush you.
Practise the fire drill out loud
Run a realistic voice mock SRE interview, narrate a troubleshooting scenario from scope to mitigation, and get a scored report. Free to start — no card.
Start freeFrequently asked questions
What's the difference between SRE and DevOps interviews?
They overlap heavily, but SRE interviews lean harder on reliability concepts (SLOs, error budgets), systems depth, and troubleshooting at scale, while testing the same core skill: calm, structured reasoning out loud under pressure.
How do I prepare for SRE troubleshooting questions?
Practise mock incident scenarios out loud on a timer. Scope the problem, ask what changed, follow the request path with the cheapest signals first, form a hypothesis, and mitigate against the error budget before chasing root cause. They grade your method, not a lucky guess.
How do I explain error budgets in an interview?
Say it as a tool, not a definition: the SLO is the reliability you promise, the error budget is the allowed unreliability, and it's the shared lever for trading feature velocity against stability. Healthy budget, ship fast; exhausted budget, slow down and invest in reliability.