SRE Interviews: 5 Error-Budget Questions to Own

Ask ten SRE candidates to explain an error budget and eight of them will recite the definition. Ask them to compute one, decide when to freeze a deploy, and defend the SLO against a skeptical product manager, and the room gets quiet.

That gap is exactly what interviewers probe. If you are a contract consultant walking into an SRE or platform reliability screen, these five questions come up in some form almost every time. Know the math cold and you separate yourself from candidates who only know the vocabulary.

1. Calculate an error budget from an SLO

The formula is simple. Error budget equals 1 minus your SLO, expressed as allowed unreliability over a measurement window.

Interviewers will hand you an SLO and a real incident count and ask you to state, in seconds, how much budget remains. Practice this until it is arithmetic, not a lookup table.

2. When do you freeze deploys?

This is the operational half of the question and it is where most candidates go vague. A defensible answer names a threshold and an escalation path, not a feeling.

• Budget exhausted (0% remaining): freeze non-critical deploys immediately; only reliability fixes and rollbacks proceed.
• Budget under 10% with a fast burn rate: require sign-off from the on-call lead before any deploy.
• Budget healthy but a single service is burning fast: scope the freeze to that service, not the whole platform.
• Freeze lifted when: burn rate returns below 1x and budget has recovered above an agreed floor, typically 20 to 30%.

State the thresholds as policy, not improvisation. Interviewers are testing whether you will actually stop a launch when the numbers say so, or whether you will get talked out of it by a VP.

3. Calibrate SLOs against real user impact

A common trap: candidates set SLOs off infrastructure metrics like CPU or raw uptime instead of what the user actually experiences. A checkout API that responds in 200ms but returns a 500 error is not reliable, no matter what the ping monitor says.

• Anchor the SLI to a user-facing signal: successful checkout completions, not server uptime.
• Segment by request type. A search query timing out matters less than a payment failing.
• Validate against support tickets or churn data before locking the target. If nobody complains at 99.5%, do not chase 99.99% and burn engineering time on it.
• Revisit the SLO quarterly. Traffic patterns and user expectations shift; a target set two years ago may be stale.

The strongest answer here ties the SLO back to a business cost. If you can say "a breach of this SLO correlates with X% cart abandonment," you have made the reliability target defensible to non-engineers, which is exactly what hiring managers want from a senior consultant.

4. Explain multi-window, multi-burn-rate alerting

A single threshold alert, like "page if error rate exceeds 1% for 5 minutes," produces two failure modes: it misses slow, sustained degradation, and it fires false alarms on brief blips. Multi-window burn rate alerting fixes both.

The Google SRE Workbook pattern, which most interviewers expect you to know by name, uses two paired windows per severity:

• Fast burn (page): a 1-hour long window paired with a 5-minute short window, alerting at roughly 14.4x burn rate, meaning the team would exhaust 2% of the monthly budget in one hour if the trend continued.
• Slow burn (ticket): a 6-hour long window paired with a 30-minute short window, alerting at roughly 6x burn rate, corresponding to 5% of budget over six hours.

The short window exists so the alert clears quickly once the incident is fixed, instead of staying hot for the full long-window duration. Be ready to draw this on a whiteboard. Interviewers ask candidates to sketch the two-window logic more often than they ask for the exact multipliers, so understand the reasoning, not just the numbers.

5. What happens after the budget is spent?

This question tests whether you understand error budgets as a negotiation tool, not a punishment. When budget hits zero, the answer is not "everyone panics." It is a structured sequence:

1. Declare the freeze per the policy from question 2.
2. Run a blameless postmortem to identify the dominant contributor to the burn, not just the latest incident.
3. Bring product and engineering leadership a specific tradeoff: ship the next feature later, or accept a lower SLO and document the risk.
4. Reset the budget at the start of the next measurement window and track whether the same failure mode recurs.

Candidates who can describe this cycle calmly, with numbers instead of adjectives, read as people who have actually been on call during a bad month. That is the signal clients are paying for.

Quick prep checklist

• Memorize the downtime-per-SLO table above for 99.9, 99.95, and 99.99 percent.
• Practice stating a deploy-freeze policy in three sentences, with thresholds.
• Have one real or hypothetical example of an SLO you tied to a user-impact metric.
• Be able to sketch the two-window burn rate alert on a whiteboard from memory.
• Prepare a 60-second answer for what happens the day after budget hits zero.

The Josh Pros LLC team places SRE and platform consultants into contract roles across the US and can walk through what specific clients probe for in these interviews. Reach out at contact@joshpros.com or visit https://joshpros.com to talk through your next placement.

#SREInterview #ErrorBudget #SLO #SiteReliabilityEngineering #ITContracting #TechConsultants #CloudCareers #DevOpsJobs #BurnRateAlerts #JoshProsLLC #ContractIT #ReliabilityEngineering

Back to all insights