Tell me about a time you caused or contributed to a production incident. How did you respond?

How to answer this behavioral interview question: a complete STAR example, the mistakes interviewers watch for, and the follow-ups you should expect.

A strong STAR example answer

In my second year as a backend engineer, I shipped a database migration that took down our checkout service for 47 minutes during peak traffic. The migration added a NOT NULL column without a default, and it locked the orders table while backfilling 30 million rows. I had tested it against a staging snapshot that was several months old and far smaller than production.

The on-call alert fired within minutes of deployment. I immediately owned it in the incident channel, and rather than attempting a risky rollback mid-migration, the team and I decided to let the migration finish while I prepared a fallback. I stayed on the bridge, posted status updates every ten minutes, and coordinated with support on customer messaging. Revenue impact was estimated at roughly $60,000 in abandoned checkouts.

Afterward, I wrote the postmortem myself, with no finger-pointing — the contributing factors were my stale staging data, a missing lock-timeout safeguard, and a review process that treated migrations as routine. I drove three fixes: a CI check that flags blocking migrations, staging refresh automation, and mandatory lock timeouts. Eighteen months later, none of those classes of incident has recurred, and the migration checklist I wrote is now standard across four teams.

How to structure your own answer

• Situation: Set up the system, the change you shipped, and the blast radius.
• Task: State your role in both causing and resolving the incident.
• Action: Walk through detection, mitigation, communication, and the postmortem.
• Result: Quantify the impact and name the durable safeguards that resulted.

Common mistakes to avoid

• Claiming you have never caused an incident, which reads as inexperience or evasion.
• Describing the heroics of the fix while glossing over your role in causing it.
• Skipping the postmortem and the preventive changes, which are what interviewers probe for.
• Minimizing the customer or revenue impact instead of stating it plainly.

Follow-up questions to prepare for

Interviewers use follow-ups to verify your story is real. If you use this question in a real interview, expect probes like:

• Walk me through the moment you realized it was your change — what did you do first?
• How did you decide between rolling back and letting the migration finish?
• How did this change the way you review other engineers’ risky changes?

Related behavioral questions

Keep drilling with these, or browse the complete question bank.