Prepare debugging incident story

A typed scaffold plus a concrete example. The structure is the load-bearing part — replace every field with your real story.

type IncidentStory = {
  pageTrigger: string;       // Exactly which alert/customer report kicked it off, with timestamp.
  initialSymptom: string;    // What the user saw, not what you saw in logs.
  myFirstHypothesis: string; // What you thought was wrong before you had data.
  evidenceThatRefuted: string; // The signal that disproved your first hypothesis.
  rootCause: string;         // The actual mechanism. One sentence.
  shortTermFix: string;      // What stopped the bleeding (revert, flag, hotfix).
  longTermFix: string;       // What keeps it from happening again (test, observability, design change).
  prevention: string;        // The systemic change so the team catches the next one cheaper.
  measurable: string;        // Time-to-detect, time-to-mitigate, customer impact, follow-up tickets.
};

const example: IncidentStory = {
  pageTrigger:
    'PagerDuty fired at 14:42 UTC: "Frontend client error rate > 4% for 5 minutes" on the trader app. Within minutes, two prop traders pinged trading-support that the order ticket was "stuck on Submitting".',
  initialSymptom:
    'Submit button stayed disabled after click; no toast, no error banner. Users clicked again and a different order eventually went through, but the panel showed two pending orders for one intent.',
  myFirstHypothesis:
    'I assumed the WebSocket order-update channel had degraded — we had a similar incident a quarter ago.',
  evidenceThatRefuted:
    'Datadog showed WS uptime 100% during the window. Sentry breadcrumbs showed the submit promise resolving normally; the UI just never transitioned out of "submitting". The bug was client-side state, not transport.',
  rootCause:
    'A new TanStack Query mutation key collided with a separate mutation that fired on focus, so both mutations shared the same in-flight state. The submit reducer interpreted the wrong mutation\'s success as its own and stayed in submitting because the matching success never arrived.',
  shortTermFix:
    'Flagged off the focus-fired mutation within 18 minutes. Customer-visible incident closed by 15:08 UTC, total impact 26 minutes for ~40 traders.',
  longTermFix:
    'Adopted a project-wide rule that mutation keys must be tuples [domain, action, entityId]. Wrote a TypeScript helper createMutationKey(domain, action, entityId) so collisions are visible in code search, and a lint rule that fails if a mutation literal is anything other than that helper output.',
  prevention:
    'Added a property test that asserts unique mutation keys at app boot in development. Added a Datadog alert on "submit-button stuck > 6 seconds" so the user-visible symptom pages directly, without waiting on the catch-all error rate alarm.',
  measurable:
    'Time to detect: 3 minutes. Time to mitigate: 18 minutes. Affected traders: ~40. Duplicate orders resulting from second-click: 3 (all reconciled by close of business). Follow-up tickets opened by support related to the same root cause: 0 in the 60 days post-fix.',
};

Convert the answer into observable behavior. In a mid-senior interview, say which behaviors are covered by unit tests, interaction tests, accessibility checks, and one browser smoke path.

// "Test" for a debugging-incident story = a peer-led pressure rehearsal.
// 1. Tell the story under a 100-second cap.
// 2. Peer interrupts at the "first hypothesis" step with: "Why that?"
//    Your answer must name the prior context, not "I had a hunch".
// 3. Peer asks at the end: "What evidence convinced you to revert vs. roll forward?"
//    Your answer must reference a specific signal, not consensus.
// 4. Peer asks: "What did this incident change about how the team works now?"
//    Your answer is the prevention beat — be concrete (rule, lint, alert).

Shows whether your communication matches the level of ownership expected from senior frontend engineers.

• Use a real project or credible constructed scenario.
• Name your ownership directly.
• Include a tradeoff, outcome, and what you would do next.

• Open with context and user or business risk.
• Describe the technical decision and your ownership.
• Close with measurable outcome, learning, and relevance to the target role.

• A polished story is useful, but over-rehearsed answers can sound detached from real engineering judgment.
• Depth matters more than listing many technologies.

• Interviewer asks for your personal contribution.
• Metric is unavailable or ambiguous.
• The story exposes a skill gap you need to frame honestly.

• Say the answer aloud in two minutes.
• Write one follow-up technical detail.
• Prepare one honest limitation and ramp-up plan.

• What would a staff engineer have done differently?
• What evidence would a hiring manager trust?