The short answer: SRE interviews test whether you can keep services reliable at scale while letting teams ship quickly. Expect the core concepts from Google’s SRE book (SLIs, SLOs and SLAs, error budgets, toil, blameless postmortems), monitoring and alerting, incident response, reliability and capacity design, hands-on Linux and networking troubleshooting, coding or scripting, and scenarios like “Latency doubled after a deploy” or “A disk is filling up on a database server.”
Core SRE concepts
“What are SLIs, SLOs and SLAs?”
Google’s SRE book defines an SLI (service level indicator) as “a carefully defined quantitative measure of some aspect of the level of service,” such as request latency, error rate or throughput. An SLO (service level objective) is “a target value or range of values for a service level that is measured by an SLI,” for example 99.9% of requests succeeding over 30 days. An SLA is an agreement with users that includes consequences, usually financial, if the SLO isn’t met. SLOs should be stricter than SLAs.
“What is an error budget?”
The amount of unreliability an SLO allows: with a 99.9% availability SLO, 0.1% of requests may fail. The SRE book describes it as a clear, objective metric for how unreliable the service is allowed to be in a period, which “removes the politics” from negotiations between SRE and product teams. While budget remains, teams ship; when it’s spent, they focus on reliability.
“Why not aim for 100% reliability?”
The SRE book notes that past a certain point, increasing reliability is worse for a service and its users: it slows feature delivery and raises costs dramatically, while users can’t tell the difference beyond the reliability of their own networks and devices.
“What is toil?”
The SRE book defines toil as work tied to running a production service that tends to be “manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” Google’s SRE organization aims to keep toil below 50% of each SRE’s time, with the rest spent on engineering that reduces future toil or improves the service.
“What is a blameless postmortem?”
A written review of an incident that, in the SRE book’s words, focuses “on identifying the contributing causes of the incident without indicting any individual or team.” It covers impact, timeline, root and contributing causes, what went well, and action items with owners. Blamelessness makes people willing to report problems.
Monitoring and alerting questions
- “What should you monitor?” User-facing symptoms first, such as the four golden signals: latency, traffic, errors and saturation. Add resource metrics for diagnosis.
- “What makes a good alert?” It’s actionable, urgent, and tied to user impact (for example, SLO burn rate), not to every CPU spike. Too many alerts lead to alert fatigue.
- “Metrics, logs and traces?” Metrics for trends and alerting, logs for detailed events, traces for following a request across services.
Incident response questions
“Walk me through how you handle an incident.”
Acknowledge and assess impact, declare an incident and assign roles (incident commander, communications, operations), mitigate first (roll back, fail over, shed load) before finding the root cause, communicate status regularly, then write a blameless postmortem with action items.
“How do you reduce mean time to recovery?”
Fast detection (good alerts), runbooks, easy rollbacks and feature flags, practiced incident roles, and observability that points to the cause quickly.
Reliability and capacity design questions
- “How do you make a service highly available?” Redundancy across failure domains (zones, regions), health checks and automatic failover, graceful degradation, and no single points of failure.
- “How do you plan capacity?” Forecast demand from trends and launches, load test to find limits, keep headroom, and autoscale where possible.
- “How do you deploy safely?” Progressive rollouts (canary, then gradual), automated checks against SLOs, and automatic rollback.
- “What is chaos engineering?” Deliberately injecting failures in a controlled way to verify that systems and people respond as expected.
Troubleshooting questions
- “A Linux server is slow. What do you check?” CPU (
top), memory and swapping (free,vmstat), disk I/O (iostat), disk space (df), network (ss, connection counts), and recent changes, working from symptoms to cause. - “What happens when you type a URL and press Enter?” DNS resolution, TCP connection, TLS handshake, HTTP request, load balancer, application, database, and the response back, with where each step can fail.
- “A service can’t reach another service.” Check DNS, network policies and firewalls, the target’s health and listening port, TLS certificates, and recent configuration changes.
Scenario questions
- “Latency doubled right after a deploy.” Mitigate first: roll back or turn off the feature flag. Then compare the versions, check dependencies, and add a latency check to the canary stage.
- “A disk is 95% full on a database server.” Stop the bleeding (clear old logs, expand the volume), find what’s growing, set alerts at earlier thresholds, and fix the underlying cause.
- “Your error budget is nearly spent mid-month.” Slow or freeze risky launches, prioritize reliability work for the causes that consumed the budget, and review the SLO with stakeholders.
- “On-call is exhausting the team.” Measure pages per shift, remove noisy alerts, fix the top recurring causes, automate toil, and make sure on-call load is shared fairly.
Behavioral questions
- “Tell me about the worst incident you handled.”
- “Tell me about a time you automated away toil.”
- “Tell me about a time you pushed back on a launch for reliability reasons.”
Related guides: DevOps engineer interview questions, Kubernetes interview questions, Splunk interview questions and penetration tester and ethical hacker interview questions.
Frequently asked questions
What questions are asked in an SRE interview?
What is the difference between an SLI, an SLO and an SLA?
What is an error budget?
What is toil in SRE?
How do you handle an incident as an SRE?
Sources
- Google, Site Reliability Engineering: Service Level Objectives, Embracing Risk, Eliminating Toil and Postmortem Culture. Read on 2 October 2026.
