Site Reliability Engineer Interview Questions: 30 With Sample Answers

Site reliability engineer interview questions test whether you can keep a production service reliable using software: defining reliability with SLIs and SLOs, spending an error budget wisely, building useful monitoring, running incidents, cutting toil, and debugging Linux and distributed systems under pressure. The three questions you are most likely to get are "What is the difference between an SLI, an SLO and an SLA?", "Walk me through how you would debug this outage" and "Tell me about an incident you led." This guide gives you 30 questions grouped by round, what a strong answer shows for each, and five sample answers we wrote. Definitions come from Google's Site Reliability Engineering book at sre.google, checked as of October 2026.

How the SRE interview usually runs

Stages vary a lot by employer. Some SRE teams hire software engineers who happen to run production, and test coding heavily. Others are closer to operations and weight Linux, networking and troubleshooting. Ask the recruiter which kind of SRE role this is.

The SRE concepts every interviewer expects

Use the SRE book's own vocabulary. It is what most interviewers learned from.

• SLI, SLO, SLA. An SLI is a carefully defined quantitative measure of some aspect of the service, such as latency or error rate. An SLO is a target value or range for an SLI. An SLA is a contract with users that includes consequences for meeting or missing the SLOs it contains (SRE book, Service Level Objectives).
• Error budget. The gap between 100% and the SLO is the amount of unreliability you may spend. The book's example: with a 99.999% SLO, the budget is a 0.001% failure rate. While budget remains, releases continue; when it is spent, releases slow or stop until reliability recovers (SRE book, Embracing Risk).
• The four golden signals. Latency, traffic, errors and saturation (SRE book, Monitoring Distributed Systems).
• Toil. Work that is manual, repetitive, automatable, tactical, has no enduring value and grows linearly with the service. Google's stated goal is to keep toil below 50% of each SRE's time (SRE book, Eliminating Toil).
• Blameless postmortems. A written review of an incident's contributing causes that assumes everyone acted in good faith with what they knew, and fixes systems rather than blaming people (SRE book, Postmortem Culture).

Know the downtime math cold. Over a 30-day month (43,200 minutes), a 99.9% availability SLO allows 43.2 minutes of downtime, 99.95% allows 21.6 minutes, and 99.99% allows about 4.3 minutes.

SLO, monitoring and alerting questions

1. What is the difference between an SLI, an SLO and an SLA? A strong answer shows the measure, the target and the contract, and that SLOs should be stricter than any SLA.
2. How would you choose SLIs for a checkout API? Shows user-centric measures: share of successful requests and share served under a latency threshold, measured as close to the user as practical.
3. Why not aim for 100% availability? Shows that users can't tell the difference past a point, cost rises steeply, and a 100% target leaves no room to ship changes.
4. How does an error budget change how a team ships? Shows that budget left means faster releases, an empty budget means reliability work, and both sides agree on the policy in advance.
5. What is a burn rate, and how would you alert on it? Shows that burn rate is how fast you spend budget relative to the SLO (a rate of 1 spends it exactly over the window), and that fast burns page while slow burns open a ticket.
6. What are the four golden signals? Shows latency, traffic, errors and saturation, plus why you track the latency of failed requests separately.
7. Symptom-based versus cause-based alerts? Shows you page on what users feel (errors, latency) and use cause metrics such as CPU for dashboards and debugging.
8. How do you reduce alert fatigue? Shows deleting alerts nobody acts on, paging only on SLO impact, and routing the rest to tickets.
9. Metrics, logs and traces: when do you use each? Shows metrics for trends and alerting, logs for detail on one event, traces for where time goes across services.

Incident response and postmortem questions

10. You are paged: error rate is 20%. Walk me through it. Shows acknowledge, scope impact, check recent changes, mitigate first (rollback, drain, failover), then find the root cause.
11. What roles do you set up for a large incident? Shows an incident commander, someone on communications, and people working the problem, so no one does all three.
12. When do you roll back versus fix forward? Shows rollback as the default when a change is suspect, and fix-forward only when rollback is unsafe or slower.
13. What goes in a postmortem? Shows impact, timeline, contributing causes, what went well, and owned, dated action items.
14. What makes a postmortem blameless? Shows focusing on why the system allowed the error, not who made it, so people report problems honestly.
15. How do you make sure postmortem action items get done? Shows owners, priorities, tracking in the normal backlog, and review of overdue items.

Linux, networking and troubleshooting questions

16. A server is slow. Which commands do you run first? Shows a method: load and CPU (uptime, top), memory (free), disk I/O (iostat), then network, then the application. More in our Linux interview questions.
17. The disk is full but du shows little usage. Why? Shows that a deleted file still held open by a process keeps its space; lsof finds it.
18. What happens when you type a URL and press Enter? Shows DNS, TCP handshake, TLS, HTTP, load balancers and caching, and where each can fail.
19. How would you debug intermittent DNS failures? Shows checking resolver config, TTLs, query timeouts and the resolvers themselves, with dig run repeatedly.
20. A service has high tail latency but normal averages. What do you look at? Shows percentiles, garbage collection pauses, noisy neighbors, slow dependencies and retries.
21. What is a cascading failure, and how do you prevent one? Shows timeouts, retries with backoff and jitter, circuit breakers, load shedding and capacity headroom.

Design, automation and behavioral questions

22. Design a monitoring system for 10,000 hosts. Shows collection, storage, querying, alert evaluation and how the monitoring itself stays up. See our metrics monitoring system design.
23. How would you make this service survive a zone failure? Shows spreading capacity across zones with enough headroom to lose one, plus health-checked load balancing.
24. How do you plan capacity? Shows forecasting from growth and launches, load testing to find limits, and buffer for failures.
25. How do you roll out a risky change safely? Shows canaries, feature flags, staged rollouts, automatic rollback on SLO signals.
26. Write a script that finds the top 10 IPs by request count in a log. Shows clean parsing, a counter, and handling of malformed lines.
27. Tell me about toil you automated. Shows how you measured the time it took, what you built and the time saved.
28. Tell me about an incident you led. Shows calm command, clear updates and real follow-up.
29. Tell me about a time you pushed back on a launch. Shows using SLO data and the error budget rather than opinion.
30. Tell me about a mistake you made in production. Shows ownership and the safeguard you added. Our guide on answering "tell me about a time you failed" has the structure.

Sample answers to common site reliability engineer interview questions

These are examples we wrote. Use the structure, then fill in your own systems and numbers.

"What is the difference between an SLI, an SLO and an SLA?"

Example (any level): "An SLI is the measurement, for example the share of HTTP requests that return successfully in under 300 milliseconds. An SLO is the target for that measurement, like 99.9% over 30 days. An SLA is the contract with customers that says what happens if we miss a promised level, usually credits. I'd set the internal SLO tighter than the SLA so we find out and react before we owe anyone anything."

"How does an error budget change how a team ships?"

Example (mid-level): "With a 99.9% SLO over 30 days, we can fail 0.1% of requests. If we serve a million requests in that window, that's 1,000 failed requests we can spend. While budget remains, product teams ship at their normal pace and can take reasonable risks. If a bad week burns most of it, the agreed policy kicks in: we pause risky launches and the next sprint goes to reliability fixes. The point is that it turns 'is this reliable enough?' from an argument into a number both sides agreed on earlier."

"You are paged: error rate is 20%. Walk me through it."

Example (on-call engineer): "I acknowledge the page and open an incident channel so there's one place for updates. Then I scope it: which endpoints, which regions, all users or some. Next I check what changed recently: deploys, config pushes, feature flags, dependency incidents. If something shipped in the last hour, I roll it back first, because mitigation comes before diagnosis. If nothing changed, I look at saturation on each tier and at dependencies. Once error rates are back under the SLO, I post a status update and start collecting the timeline for the postmortem."

"Tell me about toil you automated."

Example (experienced hire): "Our team rotated database certificates by hand every quarter, and it took about two engineer-days each time, with a checklist that someone always got slightly wrong. I wrote a job that requested new certificates, pushed them through our config system and verified the database accepted them before removing the old ones. The first automated run took ten minutes of supervision. More importantly, we stopped having the expired-certificate incidents we'd had twice that year."

"Tell me about a time you pushed back on a launch."

Example (STAR): "A team wanted to launch a new search backend the week our error budget for that service was nearly gone after two incidents. I showed the product lead the burn-down chart and our agreed policy. Instead of a flat no, I proposed a 5% canary with automatic rollback if errors rose. They agreed, the canary caught a timeout bug on day one, and the full launch went out a week later without using more budget."

What interviewers listen for, by skill

Questions to ask the interviewer

• "Do services here have written SLOs, and what happens when an error budget runs out?"
• "What does on-call look like: rotation size, pages per week, follow-the-sun or not?"
• "How much of the team's time goes to toil versus project work?"
• "What was the last postmortem, and which action items came out of it?"

More ideas are in our list of questions to ask the interviewer.

How to practice site reliability engineer interview questions

1. Learn the five SRE book concepts above well enough to explain each in 30 seconds without notes.
2. Practice the downtime math and one error budget example until you can do it in your head.
3. Rehearse a troubleshooting scenario out loud, naming each command and why you ran it.
4. Prepare two incident stories and one toil story with real numbers.

CoPilot Interview's Mock Interview builds questions from your résumé and the job description, reads them aloud and scores each spoken answer out of 10 with what to fix and a model answer. The free browser mock interview has DevOps and system design tracks. For overlapping topics, see DevOps interview questions, Kubernetes interview questions and cloud engineer interview questions; for design rounds, our system design interview page.

FAQ

What are the most common site reliability engineer interview questions?

The most common are the difference between an SLI, an SLO and an SLA, how error budgets work, the four golden signals, a live troubleshooting scenario, how you would debug a slow Linux server, and a story about an incident you led and its postmortem.

What is an error budget in SRE?

An error budget is the amount of unreliability a service may have under its SLO. With a 99.9% SLO, 0.1% of requests may fail in the window. While budget remains, teams keep shipping; when it runs out, they slow releases and work on reliability.

What are the four golden signals?

Google's SRE book names latency, traffic, errors and saturation as the four golden signals to monitor for a user-facing system.

Do SRE interviews include coding?

Usually yes. Many SRE loops include at least one coding round, often scripting tasks like log parsing or automation in Python or Go, and some use standard algorithm questions. The depth varies by employer, so ask the recruiter.

How is an SRE interview different from a DevOps interview?

They overlap heavily. SRE interviews lean more on SLOs, error budgets, monitoring design, incident command and production debugging, while DevOps interviews lean more on CI/CD pipelines, build systems and infrastructure tooling.

How much downtime does 99.9% availability allow?

Over a 30-day month, 99.9% availability allows 43.2 minutes of downtime. 99.95% allows 21.6 minutes and 99.99% allows about 4.3 minutes.

How can I practice SRE interview questions for free?

Explain concepts and troubleshooting steps out loud and record yourself. CoPilot Interview has a free browser mock interview with DevOps and system design tracks that scores each spoken answer.