TL;DR: Describe a real incident through the decisions you personally made, the evidence available then and the effect on users. Separate restoring service from understanding the cause, and say which follow-up work was actually completed.
How to approach it
Choose an incident where you can explain your contribution in detail, even if you were not the incident commander. Establish the service, user impact and your responsibility briefly, then spend most of the answer on decisions. Check the timeline before rehearsing; distinguish recorded measurements from estimates and leave out confidential customer details.
A strong answer
Start with the user operation that failed. “The booking API accepted requests but some bookings could not be retrieved” gives the listener a clearer problem than “we had a database issue.” Describe what you knew at the first alert. If you only learned the affected percentage later, do not narrate as though you had it while making the initial decision.
Explain your actual authority. You might have collected evidence, proposed a rollback that a lead approved, or coordinated updates while another engineer repaired the database. Use “I” for your actions and “we” for joint decisions. Naming the specialist who helped makes the account more precise; it does not diminish your ownership.
Walk through the mitigation and why you chose it over an alternative. A rollback is defensible when the change is plausibly related and the old version remains compatible with current state. If compatibility is unknown, a traffic reduction or disabling a failing optional path may be safer. Describe the uncertainty you accepted and the check you used to decide whether the action worked.
The following is a fictional practice case, not an experience to claim as your own. A deployment increases each application replica's database pool from 20 to 50 connections. Ten replicas can now request 500 connections instead of 200. The database has an application allowance of 400, and rollout overlap adds further demand. The on-call engineer notices connection-acquisition timeouts and compares the configuration revisions before proposing a return to the old pool size.
That explanation still leaves useful questions. Did the connection metric include other services? Were the configured pools actually full? Could the deployment safely return to the earlier configuration, and would existing connections drain? A credible story says which evidence was collected and which hypothesis remained unproven. Arithmetic identifies a plausible capacity mismatch; it does not prove the incident's cause by itself.
Describe recovery using the user operation and the resource symptom. In this case, a falling connection count is encouraging, but bookings must also succeed and remain retrievable. Note whether retry traffic or a backlog kept impact going after the immediate repair. The time of the configuration change and the time users recovered may differ.
Finish with the follow-through. An owner might add a release check that calculates connection demand across old and new replicas, then test it against the rejected configuration. If the team only proposed that check, say it remained open. A completed action has evidence: a reviewed change, a rehearsal result or a runbook used successfully afterwards. Avoid predicting that it “prevented all future incidents.”
Prepare your own evidence card. Write these notes from a real incident before practising aloud:
| Detail | What to record |
|---|---|
| Impact | Affected user operation, scope and measurement source |
| Your role | What you could decide and what required approval |
| Decision | Evidence available then, alternative and accepted risk |
| Recovery | How you established users could complete the operation |
| Follow-through | Completed change, owner and verification; open items separately |
If you have never owned a production outage, say so. Use an incident you supported, a failed delivery or a clearly identified rehearsal, and keep the scope accurate. The useful material is your reasoning and follow-through, not an inflated job title.
What interviewers probe next
“What would you do differently?” Name a decision and the evidence you would gather sooner. For the practice case, that could be comparing configuration and connection demand before restarting replicas, since restarts can add connection churn.
“How do you know your action restored service?” Explain the before-and-after user outcome, observation interval and any concurrent changes. If several mitigations happened together, acknowledge that you cannot attribute the recovery to one with certainty.
“How did you communicate?” Give the audience, update cadence and information shared: confirmed impact, current mitigation, unresolved questions and the next update time. Avoid promising a recovery time you could not support.
“What did you personally change afterwards?” Point to your completed work and how it was checked. Distinguish your proposal from another engineer's implementation.
Common mistakes
Rehearsing an invented outage until it sounds fluent. Follow-ups about logs, permissions and timing expose gaps that an honest smaller example would not have.
Presenting a restart as both diagnosis and proof. Recovery after a restart does not establish whether the cause was a leak, a stuck connection or a transient dependency failure.
Giving precise impact numbers without knowing their denominator. Failed requests, affected users and lost bookings are different measures; use the one your evidence supports.
Removing every personal decision from a blameless account. You can explain your own mistaken assumption while also identifying the system conditions that allowed it to cause damage.