How to Answer "Tell Me About a Time You Broke Production"

Why interviewers ask this

This is not a trap. Interviewers ask it because candidates who have never broken production have never operated at real scale. They are looking for four things: do you own failures or deflect blame; can you articulate what went wrong clearly and without waffle; did you fix the root cause rather than just the symptom; and do you have a structured way of thinking about incidents. A candidate who says "I've never broken production" and stops there has failed the question.

The structure that works

Standard STAR (Situation, Task, Action, Result) is designed for general behavioural questions. For incident questions a tighter structure works better. Call it SBARE: Situation (what system, what was the blast radius), Background (why the change happened and what you expected), Actions (exact diagnostic steps, in order), Resolution (the specific fix, not just "I rolled it back"), and Evolution (what changed permanently so it cannot happen again). A strong answer takes 3-4 minutes delivered cleanly.

• -Situation: the system, the scale, who was affected, how you found out
• -Background: what you changed and why - context prevents the incident from sounding careless
• -Actions: the diagnostic steps you actually ran, in sequence, including wrong hypotheses
• -Resolution: the specific fix - not "I rolled back" but what exactly you reverted and why that worked
• -Evolution: the permanent change - alert, runbook update, test, process change

What to include

Specificity is what separates a good incident answer from a generic one. Interviewers remember the candidate who said "I checked the Datadog APM trace and saw the p99 latency spike to 8 seconds on the user-service payment endpoint" over the one who said "I looked at the logs and saw errors."

• -Numbers: how many customers were affected, how long the outage lasted, what the error rate peaked at
• -Your diagnostic process in sequence - what you looked at first, what ruled it out, what led you to the root cause
• -One thing you thought was wrong first, and why that turned out to be incorrect - shows intellectual honesty
• -The exact fix - the config value you changed, the feature flag you disabled, the commit you reverted
• -The permanent follow-up - the alert you added, the runbook you wrote, the test that would have caught it

What to avoid

These mistakes actively damage your answer. Interviewers notice each of them.

• -Blaming a teammate, a code reviewer, or a third-party vendor - ownership is the entire point of the question
• -Saying "we" throughout but taking individual credit for the fix - interviewers notice the inconsistency
• -Not knowing the root cause - "something happened and the pods crashed" is not an incident answer
• -Minimising the impact - saying "it only affected a few users" when it was a full outage breaks trust immediately
• -Having no permanent follow-up change - if nothing changed after the incident, you did not learn from it
• -Spending more than 30 seconds on setup before getting to the incident itself

If you have never broken production

Do not say "I have never broken production" and stop there. Either you have not operated at meaningful scale, you have been lucky, or you are not remembering accurately. Use one of these three alternatives instead: a near-miss you caught and fixed before it hit production, an incident you were part of investigating but did not cause, or an on-call shift where you diagnosed and resolved someone else's outage. Apply the same SBARE structure to any of these. The question is about your operational thinking, not your guilt.

A worked example

Here is what a strong, concise incident answer sounds like. It takes about three minutes to deliver and hits every element of SBARE.