Site Reliability Engineer interview question
How do you triage a service incident as an SRE?
Quantify affected users and SLO impact, assign incident command, inspect golden signals and recent changes, form and test one hypothesis at a time, mitigate safely before root cause, and communicate on a cadence.
Direct answer
What a strong answer covers
How it works
An SRE opening an incident first quantifies it in SLO terms: how many users, which journeys, and how fast the error budget is burning, because that decides severity and escalation. An incident commander is named and keeps a single timeline; a communications lead updates stakeholders on a fixed cadence. Investigation starts from the golden signals of the affected service and its dependencies and from the change log, and it proceeds one hypothesis at a time with a test for each so responders do not make five changes at once. Mitigation that restores users, such as rollback, traffic shifting, or shedding load, comes before root cause. Everything is recorded for the postmortem.
Example
Search latency doubled and the SLO burn rate hit 14x at 14:03. The commander set severity from the burn rate, the dashboard showed the search cluster’s CPU saturated, and the change log showed a new ranking feature enabled at 13:55. Hypothesis one, the feature, was tested by disabling its flag for 10 percent of traffic; latency recovered for that slice, the flag was turned off globally at 14:11, and the team investigated the feature’s cost afterwards.
Common mistakes
- Escalating by gut feeling instead of measured user impact.
- Chasing the root cause while the error budget keeps burning.
- Multiple responders changing things simultaneously with no record of who did what.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.