15 SRE Interview Questions With Answers, From SLOs to On-Call

SRE interviews check whether you can turn reliability into arithmetic and decisions. Be ready to say, without a calculator, that a 99.9% availability SLO over 30 days allows 43.2 minutes of failure, then explain what the team does when that budget runs out. Below are fifteen questions across SLOs, incidents, toil, on-call and design, with the answers that score.

SLIs, SLOs and error budgets

1. Define SLI, SLO and SLA. The SRE book calls an SLI a carefully defined quantitative measure of some aspect of the service, an SLO a target value or range for that SLI, and an SLA a contract with consequences for missing the SLOs it contains. A strong answer adds: if missing it has no consequence, it is an SLO.

2. Why not target 100%? Because the book says 100% is unrealistic and slows deployment while forcing expensive, conservative designs. The book's Embracing Risk chapter adds that a user on a 99% reliable smartphone cannot tell 99.99% from 99.999% service reliability. The gap is the error budget, and it buys release velocity.

3. Calculate the error budget for 99.9% over 30 days. 30 days is 43,200 minutes; 0.1% of that is 43.2 minutes. At 99.95% it is 21.6 minutes. For request-based SLOs, say it as a ratio: one bad request in a thousand.

# error budget, minutes = window_minutes * (1 - SLO)
30 * 24 * 60 * (1 - 0.999)   = 43.2
30 * 24 * 60 * (1 - 0.9995)  = 21.6

4. Averages or percentiles for latency? Percentiles. The book says most metrics are better thought of as distributions, and an average hides the slow tail. Quote p50 for the typical user and p99 for the plausible worst case.

5. What happens when the budget is exhausted? The agreed policy kicks in: feature releases pause, and engineering time moves to reliability until the budget recovers. Interviewers want "agreed in advance with product," because a policy written mid-incident is a negotiation. Our post on turning error budgets into roadmap decisions has a policy file you can describe.

Alerting and incident command

6. How would you alert on an SLO? Multi-window, multi-burn-rate. The SRE Workbook's starting point for a 99.9% SLO pages when the 1-hour and 5-minute windows both burn at 14.4x (2% of budget), or the 6-hour and 30-minute windows at 6x (5%), and opens a ticket at 1x over 3 days and 6 hours (10%). The short window makes the alert clear quickly after recovery. See burn-rate alerting for the PromQL.

7. When do you declare an incident? The SRE book's test: you need a second team, customers can see it, or it is unsolved after an hour of concentrated analysis. Strong candidates add that the book says it is better to declare early, because declaring is cheap and late coordination is not.

8. What are the incident roles? Incident command holds the high-level state and assigns work; operations is the only group changing the system; communication keeps stakeholders and the incident doc updated; planning handles longer-term work like bugs and handoffs. The answer that scores: the incident commander should not be the one typing commands.

9. Mitigate or root-cause first? Mitigate. Roll back, shift traffic or shed load, then investigate with the pressure off. Name the evidence you preserve before rolling back, such as a heap dump or the failing Pod's logs.

Toil, on-call and capacity

10. What is toil? The book lists its traits: manual, repetitive, automatable, tactical, lacking enduring value, and growing linearly with service size. Google's SRE organization aims to keep it below 50% of each SRE's time. A strong answer gives one example of toil you removed and how you measured it.

11. How much on-call load is sustainable? The book sets a maximum of two incidents per 12-hour shift, because each takes roughly six hours end to end, and limits on-call to 25% of an SRE's time. It puts the minimum single-site team at eight engineers, or six per site for two sites.

12. How do you plan capacity for a launch? Start from forecast demand at peak, add headroom for the loss of your largest failure domain, load test to find the real limit per instance, and check quotas and dependencies as well as your own service. Say N+2 and say why.

Postmortems and the design round

13. What makes a postmortem blameless? It focuses on contributing causes without indicting any person, assuming everyone acted in good faith with the information they had. "Human error" is where analysis starts, not where it ends: what made the mistake easy and the impact large?

14. What triggers a postmortem? User-visible impact past a threshold, any data loss, on-call intervention such as a rollback, resolution time past a threshold, or a monitoring failure that meant a human found it first. Triggers are set before incidents, not argued after.

15. Design: reliability for a checkout API at 2,000 requests per second. A scoring answer moves in order:

1. SLIs: availability as non-5xx over all requests at the load balancer, and latency as the share of requests under 300 ms.
2. SLOs: 99.9% availability and 99% under 300 ms over 30 days, chosen with product, not inherited.
3. Alerting: the two burn-rate page rules plus a ticket rule, and nothing that pages on host metrics.
4. Failure design: multi-zone, timeouts and retries with budgets on the payment provider call, a circuit breaker, and idempotency keys so retries do not double-charge.
5. Release safety: canary with automatic rollback on SLI regression.
6. Operations: runbooks per alert, a rotation within the book's load limits, and a postmortem trigger list.

Where this breaks

The Google numbers are Google's: an eight-person rotation and a 50% toil cap are targets for dedicated SRE teams, and a five-person startup will run differently. Say so in the interview. Interviewers at smaller companies want to hear how you would adapt the principle, such as follow-the-sun with two people, rather than recite the ideal.

Questions people ask

What is the difference between SRE and DevOps in an interview answer?

DevOps is a culture and set of practices for shared ownership of delivery and operations. SRE is one concrete implementation of it, using software engineering to run operations, with specific mechanisms: SLOs, error budgets, toil caps and blameless postmortems. A good one-liner is that SRE gives DevOps numbers to argue with, so reliability trade-offs become decisions instead of opinions.

What SLO should a new service have?

Start from what users already experience: measure the SLI for a few weeks, then set the SLO slightly below current performance so it is achievable, and tighten later. Pick the target with product, write the error budget policy at the same time, and review both quarterly.

How do I prepare for an SRE interview?

Practice the arithmetic until it is instant: error budgets for 99.9% and 99.95%, burn rates, and request ratios. Prepare two incident stories with your role, the mitigation and what changed afterward. Rehearse one design round aloud, starting from SLIs rather than architecture. Then read the SRE book chapters on SLOs, toil and on-call, because interviewers quote them.

The call we'd make

Lead every answer with the user and a number. Candidates who say "43.2 minutes a month, and here is what we stop doing when it is gone" get hired over candidates who know more tools. Learn the burn-rate table and the incident roles cold, and bring one honest story where you were wrong.

Sources

• Google SRE Book: Service Level Objectives
• Google SRE Book: Eliminating Toil
• Google SRE Book: Being On-Call
• Google SRE Workbook: Alerting on SLOs