Production incident interview questions: explain how you respond

Understand what incident questions evaluate

Incident questions appear most often for experienced and senior roles because they reveal judgement under pressure: how you prioritise mitigation over root cause, communicate during uncertainty, and treat failure afterwards. A candidate who has never seen production break is not automatically weaker, but a candidate who cannot reason about it honestly stands out for the wrong reason.

Google's SRE material describes blameless postmortems as a mechanism for learning from failure rather than assigning fault. Interviewers familiar with that culture listen for the same traits in candidates: focus on systems and contributing conditions, honest accounting of what happened, and follow-through on prevention. If you cannot discuss an incident without blaming a colleague, that is a signal interviewers notice.

Reference: Google SRE book: postmortem culture, learning from failure

Prepare one incident story you own

Choose an incident where you had a real, nameable role: you were paged, you diagnosed it, you mitigated it, or you drove the follow-up. Prepare the specifics that survive follow-up: how it was detected, what the user-visible impact was, what you did first and why, what the fix was, and what you changed so it does not recur.

Own the scale honestly. A partial outage affecting a hundred customers handled well is a better story than an exaggerated global outage you cannot detail. Interviewers probe the seams: what exactly did you do versus the team, and what would have happened without your action? Inflated claims collapse on those follow-ups.

• Detection: how you found out, and whether users reported it first
• Triage: how you assessed impact and severity
• Mitigation: what you did to stop the bleeding before fixing cause
• Follow-up: what changed in the system or process afterwards

Explain the response structure, not just the fix

The evaluated pattern is: detect, assess impact, mitigate, then fix the root cause, then prevent recurrence. Candidates who jump straight to debugging the root cause while users suffer demonstrate the wrong priority. Mitigation first, such as a rollback, a feature flag, or a failover, buys time to investigate properly.

Include communication in your answer: who you told, when, and how you kept stakeholders updated while investigating. Silence during an active incident is a recognised failure mode. Even if you were not the one broadcasting updates, showing you knew communication was part of the response distinguishes experienced candidates.

Worked example: an incident story in answer form

A strong incident answer sounds like: 'Our error rate spiked on the payments path after a deploy. I was first on call. I confirmed the impact on the dashboard, rolled back the deploy within about ten minutes, and told the support channel what we knew. Then we traced it to a migration that locked the table during backfill. My follow-up was to add a concurrent-migration check to the deploy gate.'

That answer works because it has detection, a mitigation-first move, communication, a specific root cause, and a prevention step with personal ownership. Practise your version until the order is automatic, because nerves reorder stories badly.

The deploy caused it, rolling back stopped it, and the follow-up was a check so the same class of change cannot ship again. That order matters: mitigate before you understand everything, or users pay for your debugging time.

Handle hypothetical incident questions with the same structure

Some interviewers ask hypothetically: 'The service is returning 500s, what do you do?' Answer with the same structure as a real story. Check impact and scope first, form hypotheses from evidence rather than guessing, mitigate before deep debugging, and say who you would communicate with. Candidates who dive into speculative causes without establishing impact answer worse.

Name your information sources concretely: which dashboards, which logs, which alerts. 'I would look at the error rate by endpoint and check the last deploy' is specific. 'I would check the logs' is not. The specificity is what makes the hypothetical answer credible.

Prepare the follow-ups that expose depth

Expect probes such as: what would you do differently, how did you decide severity, what did you miss, and how did the team respond afterwards. Prepare an honest answer for each. Claiming you would change nothing reads as either dishonesty or no reflection; both are costly.

Also prepare the meta-answer: how your team handles incidents generally, including on-call rotation, escalation, and postmortem practice. That shows the incident was not an isolated drama but part of an operating model you understand.

Rehearse the story until the order is automatic

Write the incident story down in the detect-mitigate-fix-prevent order, then rehearse it aloud until you can tell it without notes and it lands in a reasonable time. Then rehearse it again answering the likely follow-ups: your specific role, what you would change, and how severity was decided.

If you have never been paged, prepare the closest true story you have: a production bug you found and fixed, a monitoring gap you noticed, or a near-miss you prevented. Frame it honestly as the closest equivalent rather than dressing it as a full incident. Interviewers at junior and mid levels accept scaled evidence; inflated claims fail regardless of level.

Frequently asked questions

Practise the next answer

Use a Behavioral or Technical Deep-Dive Mock Session to rehearse one incident story: what happened, what you did in which order, and what changed afterwards. Practise the follow-ups that probe your role specifically, not the team's.

Practise for your job

Sources and scope

Employer sources describe their own processes, which may change. The exercises and illustrative examples are PrepRole editorial guidance, not employer questions or hiring criteria.

• Google SRE book: postmortem culture, learning from failure
• Atlassian: engineering interview handbook

Related guides

• Structure the story with STAR
• Rehearse the technical detail behind the incident
• Show the judgement seniority requires