Here’s a question that separates the engineers who have carried a pager from the ones who have only read about it. Your service has a 99.9% availability SLO, and by the second week of the month you’ve already spent 80% of your error budget. What now?
A weak answer starts explaining what an error budget is. A strong one goes straight to the decision: freeze non-critical deploys, pull the incidents that burned the budget into a review, tighten the alerting that let them run long, and go have the awkward conversation with the product team about whether the next feature ships this week or waits. The interviewer isn’t checking whether you know the definition. They’re checking whether you’d make the reliability-versus-velocity call the way an on-call lead has to make it, with real cost on both sides of the choice.
That gap between knowing the vocabulary and reasoning like an operator is the whole game in a site reliability loop. Here is how the rounds tend to break down and what each one is really measuring.
The rounds you’ll actually see
An SRE loop looks like a backend loop that got pointed at failure. You still write code, but the design round is about what happens when a dependency dies, and there’s almost always a round built entirely around a production incident. Titles vary by company. Google splits it into a troubleshooting round and a non-abstract large-scale design round; most other shops fold those together and add a scripting round. The shape stays consistent even when the labels don’t.
| Round | Typical format | What a strong candidate shows |
|---|---|---|
| Recruiter screen | 30 min phone call | Fluency with SLI, SLO, toil, and postmortem vocabulary; a real reason for wanting reliability work over feature work |
| Coding / automation | 45 min in a shared editor | Scripting that removes toil, log parsing, sensible data structures, code that handles the error path |
| Linux and troubleshooting | 45-60 min debugging a broken system live | Scoping the blast radius before root-causing; comfort with top, strace, tcpdump, and reading dashboards under time pressure |
| Design under failure | 60 min whiteboard or shared doc | Graceful degradation, capacity headroom, dependency failure modes, where the retries and timeouts go |
| Incident retrospective / behavioral | 45 min, “tell me about a bad one” | Ownership, a blameless framing, and a concrete thing that changed afterward |
If you’re interviewing for a platform or DevOps-flavored version of the role, expect the automation round to weigh more and the pure-algorithms bar to drop. If it’s a Google-style SRE-SWE loop, expect the coding to look like a normal software interview with a reliability lens bolted on.
SLIs, SLOs, and the budget that gives them teeth
An SLI is a measurement: the proportion of requests served under 300ms, or the fraction of successful writes. An SLO is the target you hold that measurement to, like 99.9% of requests under 300ms over a rolling 28 days. The error budget is what’s left over, one minus the SLO, and it’s the number that turns reliability from an argument into arithmetic.
Interviewers probe two things here. First, do you pick SLIs that track user pain rather than machine health? CPU at 90% is not an SLI. A user watching a spinner is. If your proposed SLI could sit green while customers are furious, you’ve picked the wrong signal, and a good interviewer will push on exactly that. Second, do you understand what the numbers cost? Roughly, 99.9% monthly availability buys you about 43 minutes of downtime a month. 99.95% cuts that to around 22 minutes, and 99.99% to a little over 4 minutes. Each nine gets far more expensive to hold, and the person across the table wants to hear you say that a service nobody pages on at 3am probably doesn’t need four nines.
The trap answer is proposing a 100% SLO, or five nines for an internal tool. Nobody operates at 100%. A target of 100% means you have no budget to spend on deploys, experiments, or planned maintenance, which is another way of saying you can never change the system. The error budget exists precisely so that some failure is allowed, and the interesting engineering lives in how you choose to spend it.
The golden signals, and why p50 alerts page you for nothing
When the observability question comes, name what you’d measure before you name the tool. The four golden signals from the Google SRE practice are latency, traffic, errors, and saturation, and they cover most of what a request-driven service needs. If the interviewer works in infrastructure, the USE method (utilization, saturation, errors) for resources or RED (rate, errors, duration) for services are fine framings too. What matters is that you can explain why each signal earns a place on the dashboard.
Latency is where people show their level. Report it at p50, p95, and p99, not as an average, because an average hides the tail and the tail is what generates support tickets. The p50 tells you about the common case. The p99 tells you about the slowest one request in a hundred, which is often the one attached to your biggest customer. Alert on p99 crossing the SLO threshold, not on p50, because a p50 alert fires on normal weather and trains everyone to ignore the pager. Say that out loud and you’ve answered a question most candidates only half-answer.
On tooling, know one metrics stack well rather than name-dropping five. Prometheus with Grafana, or Datadog, for metrics. OpenTelemetry for traces so you can follow a single slow request across services. Something like PagerDuty or Opsgenie for on-call rotation and escalation. The interviewer cares less about which you’ve used and more about whether you know where a metric ends and a trace begins.
The incident question is a test of sequencing
A very common live prompt: you get paged at 2am, error rate on the checkout service is climbing, walk me through what you do. The single most common way to fail this is to start diagnosing root cause immediately. Reaching for the cause first feels like competence and reads as inexperience, because while you’re scrolling commit history the customer is still getting 500s.
The sequence a seasoned responder follows is mitigation before understanding. Look at the dashboards to confirm the alert is real. Scope the blast radius: one region or global, one service or a cascade, all users or a single tenant? Mitigate with the fastest lever available, which is usually a rollback, a traffic shift away from the bad zone, or flipping a feature flag off. Stabilize and confirm the graphs are recovering. Only then start the investigation into why it happened. If it’s a large incident, mention incident command: someone owns the incident, someone owns communications, and the responders aren’t also trying to write the status page. Stopping the bleeding buys you the calm to find the cause.
The postmortem round
Most loops include a conversation about a real incident you were part of, and it’s scored as much on tone as on technical depth. The frame they want is blameless. Walk the timeline: what broke, when you noticed, what the customer impact was, what you did to mitigate, and what you changed so it can’t recur the same way. Talk about contributing factors in the plural, because production incidents almost never have a single cause. There’s the bug, and the missing alert that let it run for twenty minutes, and the runbook that was out of date, and the deploy that went out on a Friday.
Watch how you talk about other people. If your story amounts to “a teammate pushed bad code,” you’ve told the interviewer you’d be a rough person to have in a retrospective. When someone offers “human error” as the root cause, a good SRE hears an unfinished sentence. The real question is why the system made that error easy to commit and slow to catch. A deploy that can take down checkout with one typo and no guardrail is a system problem wearing a person’s name.
Have two or three of these stories ready and told cleanly, with the metrics attached: how long detection took, how long recovery took, what the follow-up actions were and whether they actually shipped. “We added an alert” is weaker than “we added a p99 latency alert on the payment path and it caught the next regression in four minutes instead of forty.”
Prepping without just memorizing the book
Read at least the free chapters of the Google Site Reliability Engineering book and the SRE Workbook. Interviewers use that vocabulary, and they notice when a candidate uses it back correctly versus reciting it. But reading is table stakes. The candidates who clear the bar are the ones who can reason under a broken-system prompt in real time, who scope before they fix by reflex, and who can defend an SLO number against a business question instead of quoting a definition.
If you’ve never run a service in anger, build something small that pages you. Put a toy app behind Prometheus, set an SLO, break it on purpose, and watch how the signals move. An afternoon of that teaches you more about what a p99 alert feels like than any chapter, and it hands you a real incident to tell, which is the one thing the loop keeps asking for.
Keep sharpening your system design:
