Prompt and scope
Tell me about an incident you owned in production. Beyond the fix, explain how you confirmed impact, set severity and roles, communicated with stakeholders, validated recovery, and converted the experience into improvements.
ISO/IEC/IEEE 23612:2026 defines a generic incident-management process and supporting documentation for systems, services, software, and products across their life cycles. The question does not require memorizing clauses; it tests whether you can place your individual contribution in a collaborative, verifiable, reviewable incident loop.
What the interviewer evaluates
The interviewer wants facts behind impact and decisions, calm role and timeline management, a clear separation between restoring service and finding root cause, and follow-up actions with owners and dates. A strong answer protects people and avoids turning a retrospective into a blame narrative.
Clarifying questions before answering
- What was the time window, user impact, service objective, and business priority?
- Were you incident commander, technical lead, communications coordinator, or another role?
- What evidence, unknowns, and irreversible risks existed at the time?
- Which stakeholders needed which level of update and when?
- Who owned recovery, root-cause analysis, and prevention, and how was completion verified?
30-second answer framework
“I would answer with context, task, action, result, and retrospective. I would state the time, impact, and measurable signals, then explain my role, severity, assignments, and single source of truth. During response I would reduce user impact first and update business and support teams on a fixed cadence; after recovery I would validate monitoring, data, and user journeys. Finally I would separate triggers from systemic conditions, assign each improvement an owner, date, and verification metric, and explain how I followed through.”
Step-by-step deep answer
1. Choose a real, verifiable incident
Choose an incident you actually joined with concrete impact. Do not invent a story in which you fixed everything alone. Prepare the timeline, affected users or request ratio, detection signal, recovery time, and final result; remove customer names and credentials while keeping facts that support your decisions.
2. Explain severity and roles
Describe how impact, duration, data risk, and business priority determined severity. Name incident command, technical investigation, operations, communications, and scribe roles; if a small team combined roles, explain how decisions were still confirmed. Severity is not a label; it sets response speed, authority, and communication scope.
3. Describe evidence-driven response
Create one timeline and hypothesis list, separating known, unknown, and pending evidence. Prefer reversible actions such as rate limiting, rollback, or failover; state the expected signal and stop condition for each. Do not backfill the final root cause into the decisions made at the time; explain why that path was reasonable with the evidence then available.
impact -> severity -> roles -> reversible mitigation
-> evidence update -> recovery validation -> follow-up owner4. Design layered communication
Tell users and business owners the impact, current mitigation, and next update time without claiming an unconfirmed root cause. Give engineers logs, hypotheses, risks, and requests; give support an actionable user script. Keep a fixed cadence and report what remains under validation even when there is no new conclusion.
5. Validate recovery, not only a green dashboard
Check error rate, latency, critical business transactions, data integrity, queue backlogs, and dependency health after recovery. Have an on-call engineer and business representative confirm the user journey and retain before-and-after evidence. Continue for a complete observation window if metrics improve only briefly.
6. Turn the retrospective into system improvement
Separate trigger, amplifying conditions, detection gaps, and response gaps instead of writing only “someone made a mistake.” Every action needs an owner, due date, priority, and completion evidence, such as a new alert, rollback drill, permission check, or runbook. Revisit the actions in the next drill or similar incident to test whether risk actually fell.
High-quality sample answer
I would choose a real incident whose impact and timeline I can explain. I would state the user impact, duration, and my incident-command or technical role, then show how impact and data risk set severity, how we established one source of truth, and how we assigned investigation and communication. We first used reversible rate limiting or rollback, recorded hypotheses, evidence, and stop conditions, and updated business, support, and engineering teams on a fixed cadence. After recovery I validated critical transactions, data integrity, queues, dependencies, and the user journey with a business representative. In the retrospective I separated trigger, amplifying conditions, detection, and response gaps, and assigned owners, dates, and verification metrics. This matches the life-cycle incident-management thinking in ISO/IEC/IEEE 23612:2026 while preserving the information boundary and blameless principle at the time.
Common mistakes
- Only describing technical commands → collaboration and decisions disappear → add impact, roles, communication, and validation.
- Presenting the final root cause as known then → the story becomes inaccurate → separate contemporaneous evidence from hindsight.
- Equating recovery with a green dashboard → data or critical transactions may still fail → validate journeys, integrity, and an observation window.
- Blaming one person in the retrospective → systemic conditions remain → find detection, permission, process, and design gaps.
- Listing actions without owners or verification → the list becomes wishful → state owner, date, priority, and evidence.
Follow-up questions and responses
How do you answer if monitoring was incomplete?
State the unknowns, reconstruct impact from logs, support tickets, deployment records, and business data, and turn the observability gap into an owned action with an acceptance metric.
When should you roll back instead of continuing diagnosis?
When impact is expanding, hypothesis testing is expensive, and a safe rollback exists. Restore service first, then analyze the cause in isolation while recording rollback risk and validation.
How do you handle a business owner asking for updates every five minutes with no new result?
Agree on a fixed cadence and report impact, hypotheses being tested, completed actions, and the next checkpoint. State the current unknowns instead of inventing progress.
How do you prove retrospective actions worked?
Set metrics such as detection time, rollback duration, drill pass rate, or error budget, then compare the baseline in drills and subsequent incidents.
How do you keep a retrospective from becoming a blame meeting?
Focus on systems and decision context, use blameless language, and protect sensitive information. Handle separate compliance or performance matters through their own process rather than mixing them into the technical review.