SRE SLO Interview: The 43-Minute Error Budget Test

SRE SLO Interviews Are Won on Arithmetic, Not Vocabulary

Picture a mid-level Site Reliability Engineer (SRE) interview, 30 minutes, one topic: Service Level Objectives and Error Budgets. The candidate can define every term cleanly, SLI, SLO, SLA, error budget, in the first two minutes. Then the interviewer asks for the actual math behind a 99.9% target, and the fluent definitions stop translating into a number. That gap, between reciting the vocabulary and operationalizing it, is exactly what this interview is built to expose.

This walkthrough follows one candidate through a realistic version of that interview, scored against InterviewStack.io's production AI-interview rubric for this role and topic. The scenario, mistakes, and coaching below mirror how the SRE SLO and error budget mock interview actually runs.

Key Findings

• The rubric weighs 100 points across 4 dimensions: 30 for Interviewer Objectives Alignment, 30 for Level-Specific Expectations, 20 for Technical Proficiency, 20 for Communication and Problem Solving.
• The interview runs 30 minutes across 3 phases; the middle phase (minutes 8-20) packs 5 of the 13 total checklist items into just 12 minutes.
• A 99.9% monthly SLO allows roughly 43.2 minutes of downtime across a 30-day, 43,200-minute window, a calculation the rubric expects "without heavy prompting."
• Phase 1 (minutes 0-8) holds 4 checklist items, all about framing reliability around the user before any math appears.
• Phase 3 (minutes 20-30) tests incident and dependency judgment across 4 checklist items, including how to treat a third-party payments provider's failures.
• 4 topics are explicitly out of scope for this interview (deep distributed-systems algorithms, kernel or networking internals, infrastructure-as-code syntax trivia, formal SLA legal negotiation), so the bar is operational judgment, not trivia.

Level-Specific Expectations and Interviewer Objectives Alignment together account for 60 of the 100 points, and both hinge on whether the candidate's reasoning holds up once numbers enter the room.

The Interview Question

Checkout API depends on:
- a stateless application tier
- a primary database
- a downstream payments provider
- a feature flag system used for gradual rollout

The interviewer isn't grading a textbook definition here. The objective is to see whether the candidate can select user-relevant indicators, do the arithmetic that turns a target into a spendable budget, and connect that budget to real operational decisions: alerting, canary rollouts, incident response, and prioritization.

Where a Site Reliability Engineer SLO Interview Actually Gets Won

The candidate in this walkthrough, we'll call him Theo, opens strong. He separates the checkout API's user-facing behavior from internal component health and proposes both an availability SLI and a latency SLI, satisfying Phase 1's framing checklist. Then the follow-ups start, and that's where the real signal shows up.

Turn 1: Choosing the Right SLIs

Interviewer: "What SLIs would you choose for this service, and how would you decide whether they should be request-based, window-based, or endpoint-specific?"

Turn 2: The 99.9% Conversion

Interviewer: "If the team proposes a 99.9% monthly availability SLO, how would you convert that into an error budget and explain what it means operationally?"

Turn 3: The Canary That Looks Fine

Interviewer: "Suppose a canary rollout starts increasing p95 latency for write requests but overall availability still looks healthy. How would you use the error budget and rollout controls to decide what to do?"

Turn 4: After the Budget Is Gone

Interviewer: "After a major incident burns a large fraction of the monthly budget in one day, how would you expect the team to change release behavior and near-term priorities?"

Why Reading This Isn't Enough

Every mistake above is easy to spot once it's printed on a page with the correction sitting right next to it. Under real interview conditions, with a 30-minute clock running and follow-ups you haven't seen coming, the SLI-to-latency-budget connection in Turn 3 or the 43-minute arithmetic in Turn 2 has to surface in real time, out loud, without a chance to revise. That's a different skill from recognizing the right answer in a blog post, and it's the one the mock interview actually tests.

The Complete Blueprint

This is the blueprint a strong candidate hits, phase by phase, and it's the exact structure the AI mock interview tracks you against in real time as you talk.

Practice This Live

Reading the mistakes above is the easy part. Doing the arithmetic out loud, tying burn rate to a rollout decision, and defending a release-policy threshold, all inside 30 minutes of unscripted follow-ups, is what actually gets scored. Start the SRE SLO and error budget mock interview and get scored against this exact blueprint in real time, with feedback on which checklist items you hit and which you conceded.

If you want to drill the underlying concepts before you sit for the full simulation, the SLO and error budget question bank breaks the topic into individual practice questions, and the Site Reliability Engineer preparation guides cover the surrounding interview loop.

FAQ

Q. How do you convert a 99.9% monthly SLO into an error budget?

Take the observation window in minutes and multiply by the allowed failure rate. A 30-day window is 43,200 minutes; at 99.9% availability, the error budget is 0.1% of that, or about 43.2 minutes of downtime for the month. Mid-level SRE interviews expect this calculation without heavy prompting.

Q. What's the difference between an SLI, SLO, SLA, and error budget?

An SLI is the indicator you measure (availability, latency, error rate). An SLO is the internal target for that indicator over a time window (99.9% availability over 30 days). An SLA is an externally committed version of that target, often with financial penalties. The error budget is the allowed amount of unreliability implied by the SLO, the resource you spend on releases, incidents, and risk.

Q. Why do interviewers penalize alerting on CPU or pod restarts?

Because those are internal component health signals, not evidence of customer impact. A pod can restart cleanly with zero user-facing effect, while a slow database query with no restarts at all can burn real error budget. The rubric rewards alerts tied to objective risk (burn rate against the SLO) over infrastructure noise.

Q. What is the format of this SRE mock interview?

It runs 30 minutes across three phases: framing the reliability model (minutes 0-8), operationalizing objectives and budgets with real calculations (minutes 8-20), and handling incidents, dependencies, and tradeoffs (minutes 20-30). It targets a mid-level (2-5 years) scope: one service, not company-wide governance.

Q. What counts as a senior-enough answer at the mid-level for this topic?

Independently proposing SLIs and SLOs for a single service, performing the error budget math without heavy prompting, reasoning through alerting and release decisions using burn rate, and recognizing dependency and ownership boundaries, without being expected to design governance across dozens of teams.

Q. Is this a real company's interview question?

No. The scenario (a checkout API with a database, payments provider, and feature flags) is illustrative of how a mid-level SRE interview on this topic typically runs, not a leaked question from any specific employer.

Q. How should I practice for an SRE interview on SLOs and error budgets?

Practice the arithmetic until it's automatic (window in minutes times allowed failure rate), then rehearse it live under time pressure with unscripted follow-up questions, since that's where most candidates lose points that reading alone won't fix.

The Math Is the Judgment

Definitions are free; the interview is scored on what you do once a number is on the table. Getting comfortable converting a target into a budget, and a budget into a decision, is what separates a candidate who knows the vocabulary from one who can run the on-call rotation.