The incident narrative: what interviewers are actually scoring
Prepare a real incident with the impact, your decisions, the evidence available at the time and the follow-up. Include a discarded hypothesis if there was one; do not invent a mistake to fit a story structure.
TL;DR: State the impact, explain how you chose a safe mitigation, and describe the evidence behind your diagnosis. Give measured numbers where available and finish with a specific follow-up. Use your own experience; a polished story is not evidence that an event happened.
What this question can reveal
For roles with production responsibility, an incident story shows how you assess impact, work with others and make decisions under uncertainty. Interviewers may be managers or peers from another team; explain the system and your contribution without assuming they shared the incident.
The five beats
Setup, in two sentences. What the system does, what broke, who was affected. "Checkout latency went from 200ms to eight seconds for about 40 percent of traffic on a Friday evening" is complete. Organisational history is not setup.
Mitigation before diagnosis. Say what you did to reduce impact while you still did not know the cause: rolled back, failed over, shed load, flipped a flag. This beat is weighted heavily because it separates protecting users from satisfying curiosity. If you did root-cause first while customers were down, say so and say what you would change. That is stronger than a tidy story.
The wrong turn. Name a hypothesis you pursued and dropped, and the observation that killed it. For example: "The timing suggested the release. Rolling back did not restore latency, so we checked whether the rollback had completed and whether the release had left persistent effects." A failed rollback does not rule out the release. Explain what the next observation established. If your first hypothesis was correct, describe how you tested it instead.
Cause and fix, briefly. Enough to be checkable. Depth comes if they ask.
What changed. Not "we added monitoring", which is what everyone says. Something verifiable: an alert on the signal that would have caught it twenty minutes earlier, a limit that now fails closed, a runbook step deleted because it was wrong. If nothing changed, say that and why, because an honest no beats an invented action item.
Numbers
Duration, blast radius as a percentage of traffic or users, and time to mitigate. One sentence, and it changes how the whole story lands. You do not need revenue impact, and inventing one is worse than not having it. If confidentiality prevents specifics, give the shape and say why.
Preparing a set rather than a story
Prepare six, and know which map to which prompt: an outage you owned, a disagreement you lost, a mistake you made, a migration you drove, a risk you escalated, a time you were the most junior person in the room. One story can serve two prompts. Stretching one across three rounds is visible, because interviewers compare notes.
For Amazon specifically, map deliberately: ownership includes coordinating the response and escalating when needed; dive deep can be the evidence that changed your diagnosis; bias for action can be a safe mitigation chosen under uncertainty.
Fault, and how to answer it
If asked whose fault it was, name a systemic cause rather than a person. If one individual could take production down with one command and no guard, the missing guard is the defect. Describe actions and contributing conditions accurately without assigning motives or hiding your own part. The interviewer's assessment depends on the role and rubric; there is no universal disqualifying phrase.
Self-check
Take an incident you actually handled. Which observation supported your diagnosis? What uncertainty remained when you acted? What specific follow-up happened, and how did you check that it helped? A wrong turn is optional; accurate attribution of your own contribution is not.