Site Reliability Engineer Behavioral Questions (2026)

A Site Reliability Engineer behavioral interview is not a personality quiz. It is a structured probe of whether the candidate can hold a pager calmly, tell a product manager that the release is paused because the error budget is gone, and run a post-mortem the next morning without naming a single person as the cause. The technical rounds already established that the candidate can read a flame graph and design a load balancer. The behavioral loop checks whether the same engineer can keep production alive without burning out the team or burning bridges with product.

This guide covers what to prepare for SRE behavioral questions in 2026: a STAR variant tuned for incidents and budgets, fifteen prompts with response cues, three full sample answers, the failure modes that quietly sink strong technical candidates, how the bar shifts between mid and senior level, and a four-week practice routine.

STAR for SRE

Classic STAR — Situation, Task, Action, Result — was designed for general management interviews. It still works as scaffolding, but it misses what SRE interviewers actually grade: the relationship between the action taken and the reliability budget it spent or saved. The Google SRE book is explicit that error budgets are a shared contract between SRE and product, and that contract shows up in nearly every senior behavioral loop. Charity Majors has written for years that observability and operability are cultural problems first, technical problems second, and the strongest answers reflect that.

Use STAR-BF: Situation, Task, Action, Budget impact, Result, Follow-up.

• Situation (15-20 seconds): one or two sentences. Service, scope, blast radius, on-call posture. Skip the company history.
• Task (10-15 seconds): what the candidate personally owned, not what the team was vaguely doing.
• Action (45-60 seconds): the operational work. Page received, hypotheses ranked, dependency traced, rollback or mitigation chosen, comms cadence set.
• Budget impact (20-30 seconds): what this cost or saved against the SLO. “We burned roughly forty percent of the quarterly budget in ninety minutes” is a stronger sentence than any adjective.
• Result (20-30 seconds): numbers in customer terms. Requests recovered, latency restored, hours of degraded service avoided.
• Follow-up (20-30 seconds): the structural change. Runbook authored, alert pruned, dependency owner notified, game day scheduled. This is where senior loops decide whether the candidate is reactive or systemic.

Total: two and a half minutes. The Budget and Follow-up beats are what separate an SRE story from a generic engineering story.

Top 15 behavioral questions

These prompts recur across SRE loops at the FAANG tier, infrastructure-heavy startups, and SRE Weekly newsletter coverage of hiring trends. Map each to a story before the loop and tag which STAR-BF beats it stresses.

1. Tell me about the worst outage you led as incident commander.
2. Describe a time you used the error budget to stop a release. How did product react?
3. Walk me through the blameless post-mortem you are proudest of running.
4. Tell me about a time product or engineering pushed back hard on a reliability call you made.
5. Describe a toil-reduction project you scoped and delivered. How did you measure success?
6. Tell me about an alert you killed. What convinced you it was safe to delete?
7. Walk through a capacity decision where you were wrong. What signal did you miss?
8. Describe how you handled a teammate who started naming individuals during a post-mortem.
9. Tell me about a runbook you authored that another engineer used in a real incident.
10. Describe a time you had to push back on an executive who wanted a faster rollout.
11. Walk through a dependency outage outside your team. How did you escalate?
12. Tell me about a pager rotation you redesigned and why.
13. Describe an SLO you renegotiated. With whom, and on what data?
14. Tell me about a near-miss caught during a game day or chaos exercise.
15. Walk through your hardest disagreement with another SRE.

Questions 1, 2, 3, and 4 are mandatory preparation. They appear in nearly every senior SRE loop and are the most common reasons strong candidates get downlevelled.

Three sample answers

1. Sev1 outage you led.

“Last quarter our payment ingestion service started returning 5xx on roughly twelve percent of write requests just after a Friday afternoon deploy. I was the on-call IC. I declared sev1 within four minutes, paged the database lead and pulled in the deploy author for context, then opened the customer comms channel myself rather than waiting for the support manager. The hypothesis tree ranked a bad migration first, but the symptoms pointed at connection-pool starvation, and the dashboard confirmed pool saturation within ninety seconds. I rolled back the deploy at minute eleven and the error rate dropped under one percent by minute fourteen. We burned about thirty-five percent of the quarterly budget in that window. The follow-up was a pool-size guardrail in the deploy pipeline, which has prevented two similar regressions since. The deploy author wrote the post-mortem and I co-signed it — keeping the author in the loop kept the team from quietly flagging that service as dangerous to touch.”

2. Error-budget call that broke release.

“Our recommendations service had burned sixty-eight percent of its monthly budget by day eighteen. Product wanted to ship a ranking change tied to a marketing date. I called the release blocked in a thirty-minute meeting with the product lead and the engineering manager. I did not frame it as my decision — I walked through the burn-rate chart, the projected exhaustion date if the change shipped flat, and the historical regression rate for ranking changes on that service. We agreed to a phased rollout behind a shadow flag, with a hard cutoff if budget burn crossed two percent per day. The change shipped six days later. The relationship survived because I came with data and a path, not just a no.”

3. Blameless post-mortem you ran.

“After a partial DNS outage we had eight engineers in the post-mortem, including the on-call who had missed the first page. I opened by reading the blameless preamble aloud — yes, every time — and asked the on-call to walk the timeline first, including the missed page. We landed on three contributing factors: a noisy alert that had been ignored for weeks, a runbook that pointed at a deprecated dashboard, and a missing escalation policy after the secondary did not ack. None of those were the on-call’s fault, and naming them as system issues let the on-call describe what actually happened without defensiveness. Three action items shipped within a sprint. The same on-call ran our next game day.”

Pitfalls

The failure modes that quietly disqualify strong SRE candidates are rarely technical.

• Hero framing. Phrasing every story around what the candidate personally fixed. SRE culture explicitly rejects the hero — interviewers listen for the runbook, the alert, the teammate, the structural follow-up.
• Using the error budget as a slogan. Saying “we honour the budget” without a story where the budget actually stopped a release reads as theory. Have at least one story where you said no, and one where the budget gave you permission to say yes to a risky change.
• Naming individuals in the post-mortem story. Even casually. “The deploy author made a mistake” tanks the answer. Reframe as “the deploy pipeline let an untested config reach prod.”
• Skipping the follow-up beat. Ending an incident story at “we mitigated” without naming the structural change signals reactive operations.
• Inflated numbers. “We had five nines” without explaining the measurement window or which SLI was tracked invites a follow-up that exposes the gap.
• Trash-talking previous teams. A complaint about “the dev team would not write runbooks” reads as someone who could not influence without authority. Reframe as the runbook template you authored and the adoption curve.

Mid vs Sr SRE expectations

The behavioral bar shifts noticeably between levels and the interviewers know which beats to listen for.

Mid (L3-L4 equivalent). Stories should show calm under pressure, clean STAR-BF structure, a working understanding of SLOs and budgets, and at least one toil-reduction project the candidate scoped end to end. Incident command is welcome but not required — being a strong secondary who escalated cleanly is enough. Follow-up beats should name a runbook authored, an alert tuned, or a dependency owner pulled in.

Senior (L5-L6 equivalent). Stories must show that the candidate has shaped the system around the incident. Expect probes on how SLOs were negotiated with product, how on-call rotations were rebalanced, how chaos engineering or game days were introduced, and how the candidate coached more junior SREs through their first incident command. The error-budget conversation needs to include a moment where the candidate said yes to risk because the data supported it, not just a string of no’s. Senior interviewers also look for the candidate to talk about the political work — defending reliability against quarterly pressure, building trust with product leads, and choosing when to escalate versus when to absorb.

At both levels, ownership of the follow-up matters more than the size of the original outage. A clean sev3 with three landed action items beats a heroic sev1 with no structural change.

Practice routine

Four weeks, roughly four hours a week, ends with a candidate who can answer any of the fifteen prompts in two to three minutes without rehearsing.

• Week 1: inventory. List every incident, post-mortem, toil project, and difficult conversation from the last two years. Tag each with the prompt numbers it could answer. Aim for eight stories with clear STAR-BF beats.
• Week 2: drafting. Write each story in STAR-BF form. Read aloud and trim to two and a half minutes. Replace adjectives with numbers wherever the metric can be defended.
• Week 3: live reps. Record video answers to five prompts per session. Watch with a timer and a notepad — mark hero framing, missing follow-ups, and any number you could not source. Swap with a peer for one mock per week.
• Week 4: pressure testing. Run two full mock loops with someone who interviews SREs professionally. Ask for probes on every metric and every follow-up. Tighten the weakest two stories and retire the weakest one entirely rather than dragging it into the real loop.

By the end of week four the candidate should be able to take any of the fifteen prompts cold, pick a story in under ten seconds, and land the Budget and Follow-up beats without thinking about the structure.