Site Reliability Engineer Interview Questions (2026) and How to Answer

Behavioural questions (1–10)

How you've handled real situations. Answer each with one true story, in STAR order.

1. 1.Tell me about an incident you led as incident commander.

   What they're really asking: Can you coordinate people under pressure, not just fix things yourself?

   Answer outline (STAR)

   • SituationA major incident involving several teams.
   • TaskLead the response and keep stakeholders informed.
   • ActionAssign roles, keep a timeline, mitigate before chasing the root cause, post regular updates.
   • ResultTime to mitigate, and the postmortem actions completed.

   Full sample answer (fictional example)

   A bad certificate rotation took our payments API down for 38 minutes, with four teams involved. I was incident commander. I assigned a communications lead, an operations lead and a scribe, so I could coordinate instead of debugging. We mitigated first by reverting to the previous certificate, which restored traffic in 14 minutes, then investigated. I posted updates every ten minutes. The postmortem found the rotation had no staging step; we added one and an expiry alert. All six actions were done within a month.

2. 2.Tell me about SLOs you defined for a service.

   What they're really asking: Do you treat reliability as a product decision rather than chasing 100% uptime?

   Answer outline (STAR)

   • SituationA service with no clear reliability targets.
   • TaskAgree targets that matched what users needed.
   • ActionPick SLIs from user journeys, set SLOs with product, alert on error budget burn.
   • ResultFewer noisy alerts, and release decisions guided by the budget.

   Full sample answer (fictional example)

   Our search service had no targets, and every slow day became an argument. With the product manager I picked two indicators from the user journey: the share of searches answered under 400 milliseconds, and the share that returned without error. After reading three months of data we set SLOs at 99 and 99.9 percent over 30 days. I replaced the CPU alerts with burn-rate alerts on those SLOs. Pages fell by about two thirds, and the error budget now decides whether we ship risky changes in a given week.

3. 3.Describe a time you eliminated toil.

   What they're really asking: SRE's core principle: engineer away repetitive manual work.

   Answer outline (STAR)

   • SituationA recurring manual task eating on-call time.
   • TaskRemove it for good.
   • ActionMeasure it, then automate it or fix the underlying cause, and add guardrails.
   • ResultHours a week saved, and fewer pages.

   Full sample answer (fictional example)

   On-call spent about six hours a week restarting a queue consumer that hung under load. I measured it for a month to be sure it was worth fixing, then looked for the cause instead of automating the restart. A memory leak in one library was behind it. I upgraded the library, added a health check with an automatic restart as a safety net, and a dashboard panel for consumer lag. The six hours dropped to near zero, pages from that service fell by three quarters, and the team used the time to finish a delayed capacity project.

4. 4.Tell me about a postmortem that changed how your team works.

   What they're really asking: Do you run blameless reviews that lead to real change?

   Answer outline (STAR)

   • SituationAn incident with a process or tooling cause behind it.
   • TaskFind the systemic causes, not a person to blame.
   • ActionFacilitate the review, dig past the first cause, assign owned actions with dates.
   • ResultThe change that stuck, and the incidents it prevented.

   Full sample answer (fictional example)

   After a database failover took 25 minutes, I facilitated the postmortem. The first cause on the table was that an engineer ran a command twice. I pushed past that with the five whys: the runbook had an ambiguous step, the dry-run option was off by default, and nothing warned about a half-finished failover. We made dry run the default, rewrote the runbook and added an alert. Each action had an owner and a date, and I checked progress weekly. The failure hasn't recurred in 18 months, and teams now ask for blameless reviews after smaller events.

5. 5.Tell me about a time you pushed back on a launch for reliability reasons.

   What they're really asking: Can you hold a line with data while staying a partner to product?

   Answer outline (STAR)

   • SituationA launch with known reliability gaps.
   • TaskProtect users without blocking the business.
   • ActionShow the risk with data, propose minimum safeguards, use a launch checklist.
   • ResultThe outcome, and how the relationship held up.

6. 6.Tell me about a time you were wrong during an incident.

   What they're really asking: Do you admit a bad call quickly and correct course?

   Answer outline (STAR)

   • SituationAn incident where your first diagnosis proved incorrect.
   • TaskRecover without defending the theory.
   • ActionSay you were wrong, drop the theory, test the next one, update everyone.
   • ResultTime to resolve, and what changed in how you form theories.

7. 7.Tell me about a capacity problem you saw coming.

   What they're really asking: Are you forecasting, or reacting after the page?

   Answer outline (STAR)

   • SituationA service whose traffic or data growth pointed to a limit.
   • TaskAct before users noticed.
   • ActionChart the trend, load test to find the limit, schedule the fix.
   • ResultThe limit avoided, and the lead time you bought.

8. 8.Tell me about helping a development team make its service more reliable.

   What they're really asking: Can you influence engineers who don't report to you?

   Answer outline (STAR)

   • SituationA service with frequent incidents owned by a busy team.
   • TaskImprove reliability without taking over the code.
   • ActionReview its incidents, agree two or three fixes, pair on them, add SLOs and dashboards.
   • ResultIncident count after, and how the team kept going.

9. 9.Tell me about improving the on-call experience.

   What they're really asking: Do you look after the people who run the system?

   Answer outline (STAR)

   • SituationA rotation with too many night pages and unclear handovers.
   • TaskMake on-call sustainable.
   • ActionAudit pages, fix or delete noisy alerts, write runbooks, adjust handoffs.
   • ResultPages per shift before and after, and team feedback.

10. 10.Tell me about a risky change you made with no customer impact.

    What they're really asking: Can you plan a change that can be reversed at every step?

    Answer outline (STAR)

    • SituationA database upgrade, region move or large config rollout.
    • TaskComplete it without users noticing.
    • ActionRehearse in staging, split into reversible steps, canary first, set abort criteria.
    • ResultThe result, and the rehearsal findings that mattered.

Technical and role-skill questions (11–22)

Can you do the work itself? Think out loud and name the trade-offs.

1. 11.What's the difference between an SLI, an SLO and an SLA?

   What they're really asking: The vocabulary every SRE interview checks.

   Answer outline

   • An SLI is a measurement, such as the share of requests served in under 300 ms.
   • An SLO is the internal target for it; an SLA is a contract with penalties.
   • The error budget is 100% minus the SLO, and it sets the pace of releases.

   Full sample answer (fictional example)

   I'd explain it as three layers. An SLI is a measurement of service behaviour from the user's point of view, such as the percentage of requests served successfully in under 300 milliseconds. An SLO is the target we set for that SLI, for example 99.9 percent over 30 days. An SLA is a contract with consequences, such as refunds, and I'd keep it looser than the internal SLO. The error budget is 100 percent minus the SLO: it's the unreliability we can spend, and it sets how fast we can release.

2. 12.How would you set up alerting that wakes people only when it matters?

   What they're really asking: Alert fatigue is a reliability risk in itself.

   Answer outline

   • Alert on symptoms and error budget burn rate, not on causes like CPU.
   • Use multi-window burn-rate alerts to catch both fast and slow burns.
   • Every page must be actionable and have a runbook; review the noise regularly.

   Full sample answer (fictional example)

   I'd alert on symptoms users feel, and on how fast we're spending the error budget, not on causes like CPU. A multi-window burn-rate alert catches both a fast burn, which pages immediately, and a slow burn, which opens a ticket. Every page has to be actionable and come with a runbook; if the right response is to do nothing, the alert should go. I'd review the alerts monthly, counting which fired, which led to action and which woke someone for nothing, and delete or tune the noisy ones.

3. 13.Latency has been rising slowly for a week. How do you investigate?

   What they're really asking: Can you find a slow-building problem that no single alert shows?

   Answer outline

   • Correlate it with deploys, traffic growth and dependency changes.
   • Look at saturation: memory leaks, connection pools, garbage collection, disk.
   • Use traces and profiles to see where the time goes.

   Full sample answer (fictional example)

   I'd first correlate the rise with deploys, traffic growth and dependency changes, to see whether the slope started at a particular event. Slow creeps are often saturation: a memory leak, a connection pool filling, garbage collection pauses, a growing table or a filling disk. I'd put those resource graphs next to latency. Then I'd use distributed traces to see which part of the request is getting slower, and take profiles from a live instance. If it's growth, I'd check the headroom left, because the problem may be capacity, not a bug.

4. 14.How do you plan capacity for a service?

   What they're really asking: Forecasting and headroom, a core SRE skill.

   Answer outline

   • Measure current usage of each resource against load.
   • Forecast growth, and plan for peaks and for losing a zone.
   • Load test to find the real limits, and autoscale within sensible bounds.

5. 15.How would you make a service survive the loss of an availability zone?

   What they're really asking: Do you design for failure instead of hoping it won't happen?

   Answer outline

   • Run instances in several zones behind a load balancer with health checks.
   • Replicate data across zones, and test the failover.
   • Keep enough headroom to absorb a lost zone's traffic.

6. 16.What's your approach to chaos engineering?

   What they're really asking: Do you test resilience deliberately, and safely?

   Answer outline

   • Start with a hypothesis about the system's steady state.
   • Inject small failures (killed instances, added latency) in staging, then in production with a limited blast radius.
   • Define abort conditions, and fix what you learn.

7. 17.Write a script that finds the most common errors in a huge log file.

   What they're really asking: Practical coding: processing large data efficiently.

   Answer outline

   • Stream the file line by line instead of loading it into memory.
   • Normalise messages (strip IDs and timestamps) and count them in a hash map.
   • Return the top N with a heap, and skip malformed lines safely.

8. 18.A Linux server's load is high. How do you work out why?

   What they're really asking: A systematic method for a classic operations problem.

   Answer outline

   • Use the USE method: for each resource, check utilisation, saturation and errors.
   • Tools: top for CPU and memory, iostat for disk, ss and sar for the network.
   • Separate CPU-bound from I/O-bound waits, then find the responsible process.

9. 19.What is a retry storm, and how do you prevent one?

   What they're really asking: Do you know how well-meant retries turn a blip into an outage?

   Answer outline

   • When a dependency slows, clients retry together and multiply the load.
   • Use exponential backoff with jitter, retry limits and a retry budget.
   • Add load shedding and circuit breakers so the service protects itself.

10. 20.How do you judge a canary release?

    What they're really asking: Do you make rollout decisions from evidence, not feelings?

    Answer outline

    • Send a small slice of traffic to the new version and compare it with the old.
    • Compare error rate, latency and saturation over enough time and traffic to mean something.
    • Automate promotion and rollback, with thresholds set before the release.

11. 21.How do you set an SLO for a service that depends on several others?

    What they're really asking: Can you reason about reliability across a chain?

    Answer outline

    • Availability multiplies: you can't beat your hard dependencies taken together.
    • Decouple with caches, fallbacks and queues, so soft dependencies don't count against you.
    • Set the SLO from what users need, then check whether the dependencies can support it.

12. 22.How do you test that a database failover works?

    What they're really asking: Do you trust recovery plans only after exercising them?

    Answer outline

    • Practise failover in staging, and in production as a planned, limited-risk exercise.
    • Measure actual recovery time and data loss against your RTO and RPO.
    • Check that clients reconnect cleanly, and fix what the drill reveals.

Take-home or live exercise: tips

SRE interviews often include a troubleshooting scenario with logs or graphs, a scripting task in Python or Go, and a reliability design discussion.

• Think aloud with hypotheses: say what you expect to see, check it, and drop theories quickly when they fail.
• For scripting, handle large inputs and bad data, and mention how you'd test it and run it in production.
• In a design exercise, name the SLO first, then show where it could fail and how you'd detect that.

Skills employers test for

Technical rounds follow the job ad. These skills are named most often in the 440 newest site reliability engineer job ads we analysed (out of 1,048 live postings), shown as the share of ads that mention each. Expect questions on the top few.

1. 1Incident management74%
2. 2Kubernetes71%
3. 3Observability71%
4. 4Python64%
5. 5CI/CD61%
6. 6AWS60%
7. 7Terraform58%
8. 8Infrastructure as Code57%

Full list: Site Reliability Engineer resume keywords.

From live job ads · computed November 2, 2026 · refreshed daily

Situational questions (23–30)

Scenarios that test judgement: say what you'd do first, and why.

1. 23.You're paged at 3am because error rates are spiking. Walk me through the first 15 minutes.

   What they're really asking: Do you restore service first, and keep people informed while you do?

   Answer outline

   • Acknowledge, then check the dashboards and what changed recently.
   • Mitigate first: roll back, fail over or shed load.
   • Declare an incident if users are affected, and pull in help early.

   Full sample answer (fictional example)

   I'd acknowledge the page so teammates know it's handled, then open the main dashboard: which services, which errors and since when. I'd check what changed recently: deploys, flags and infrastructure. The first aim is to mitigate, not diagnose: roll back the last deploy, fail over, or shed load. If users are affected, I'd declare an incident and pull in help early rather than struggle alone, then post a first update within 15 minutes. Root cause comes after service is restored, in the review.

2. 24.The error budget is spent, but product wants to ship a big feature. What do you do?

   What they're really asking: Applying an error budget policy with judgement.

   Answer outline

   • Point to the agreed policy: reliability work comes first until the budget recovers.
   • Discuss what's burning the budget, and whether a lower-risk release path exists.
   • Escalate if you must, with data, not as a veto.

   Full sample answer (fictional example)

   I'd point to the error budget policy we agreed in advance, because it turns this from my opinion into a shared rule: when the budget is spent, reliability work comes first. Then I'd look at what's burning the budget and whether there's a lower-risk path for the feature, such as a flag, a canary or a smaller first release. If product still needs the launch, I'd escalate to the directors who own the policy, with data, as a request for a decision, not as a veto.

3. 25.A team wants to launch a service with no monitoring. How do you handle it?

   What they're really asking: Can you hold a reliability bar without becoming the team that says no?

   Answer outline

   • Use a production readiness review with minimum requirements.
   • Offer templates and dashboards so the bar is easy to meet.
   • Agree a short, dated exception rather than an open-ended one.

4. 26.The same incident has happened three times this quarter. What do you do?

   What they're really asking: Breaking a cycle of repeat failures.

   Answer outline

   • Review the three postmortems together and look for the shared cause.
   • Check whether the earlier action items were ever finished.
   • Make the fix planned project work, not on-call side work.

   Full sample answer (fictional example)

   I'd pull the three postmortems together and look for the shared cause, because repeated incidents usually mean the real cause was never addressed. I'd check whether the earlier action items were finished; often they sit at the bottom of a backlog. Then I'd propose a fix as planned project work with an owner and a date, not side work for on-call. I'd also ask whether detection or the runbook failed, since a faster response can shrink the impact while the root fix is being built.

5. 27.A dependency owned by another team keeps breaking your SLO. What do you do?

   What they're really asking: Can you handle reliability across team lines with data and tact?

   Answer outline

   • Gather evidence: dates, impact and the share of your error budget it consumed.
   • Share it with the owning team and ask about their own SLO and plans.
   • Protect yourself with timeouts, caching or a fallback, and escalate if needed.

6. 28.You're incident commander and two senior engineers disagree on the fix. What do you do?

   What they're really asking: Can you decide quickly without crushing disagreement?

   Answer outline

   • Ask each for the evidence and the risk of their option, a minute apiece.
   • Prefer the reversible action, and set a time limit to see if it works.
   • Decide, say so clearly, and note the dissent for the review.

7. 29.On-call is burning out the team with night pages. What do you change?

   What they're really asking: Do you treat on-call load as a reliability problem?

   Answer outline

   • Audit a month of pages, ranking alerts by how often they fire and how actionable they are.
   • Delete or downgrade the noisy ones, and automate fixes you repeat.
   • Agree a paging target, and protect the team's time to work on it.

8. 30.A manager asks for five nines of availability for a new service. How do you respond?

   What they're really asking: Can you turn a slogan into a cost and a trade-off?

   Answer outline

   • Explain five nines in minutes of downtime a year, and what it costs.
   • Ask what users need and what a failure costs the business.
   • Propose a realistic SLO, with a plan to tighten it as the service matures.

Red flags to avoid in your answers

Each one is quick to fix before the day.

1. Claiming you aim for one hundred percent uptime.

   Talk about targets matched to user needs, and what each extra nine costs.

2. Treating a postmortem as finding who made the mistake.

   Describe the system conditions that allowed it, and the actions that closed them.

3. Offering heroics as the success story: 'I stayed up all night'.

   Show the process that would have made the heroics unnecessary.

4. Talking about dashboards with no alerts, or alerts with no runbooks.

   Link every alert to user impact and to the first steps to take.

How to prepare for a site reliability engineer interview in 7 days

An hour or two a day is enough; the order matters more than the length.

1. 1

   Day 1: Know the service

   Note the stack and scale in the ad, and list the failure modes each part could have.

2. 2

   Day 2: SLO vocabulary

   Explain SLI, SLO, error budget and burn rate aloud, with a worked example of a 30-day budget.

3. 3

   Day 3: Linux and network

   Rehearse diagnosing high load, a full disk and slow DNS with real commands.

4. 4

   Day 4: Scripting drill

   Write a log-parsing script in Python or Go against a large file in 30 minutes, then test edge cases.

5. 5

   Day 5: Incident walkthroughs

   Prepare two incidents in detail: timeline, your role, decisions and the actions that closed.

6. 6

   Day 6: Design for failure

   Design a service across three zones with SLOs, failover and headroom, and say what breaks first.

7. 7

   Day 7: Mock page

   Have a friend give you a 3am scenario with graphs, then prepare three on-call questions and rest.

Questions to ask the interviewer

Pick two or three; the answers tell you whether you want the job.

1. Which SLOs does this team own, and how are error budgets used?
2. How many pages does on-call get in a week, and what's the target?
3. How is time split between project work and operational work?
4. How are postmortem actions tracked and prioritised?
5. Can SRE slow down releases when an error budget is spent?

Preparation tips

• Prepare two incident stories in detail: timeline, your role, the decisions and the follow-ups.
• Revise Linux internals (processes, memory, file descriptors) and networking (DNS, TCP, load balancing).
• Practise scripting against the clock in Python or Go: parsing logs and calling APIs.
• Read the chapters on SLOs and alerting in Google's SRE books; many interviews borrow from them.

Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.