SeniorTroubleshooting

The same incident has now happened three times despite two postmortems. What is wrong?

What they are really testing: Whether you can diagnose a process failure rather than a technical one. Recurrence after postmortems means the postmortem process itself is broken, and they want to see you say so.

A real interview question

The same incident has now happened three times despite two postmortems. What is wrong?

What most people say

drag me

The postmortems must have missed the real root cause, so I would do a deeper technical investigation this time.

It assumes a technical failure when the evidence points at a process one. Doing a third deeper investigation without asking why the first two produced no change is likely to produce a third document nobody acts on.

The follow-ups they ask next

  • How do you make action items actually get done?

    Put them in the normal backlog with an owner and a due date, review them in the same forum as other work, and make repeat incidents visible on a dashboard so unfinished actions have a cost.

  • What separates a good action item from a bad one?

    A good one changes what is possible: automation, a guardrail, a removed permission, a test. A bad one asks humans to behave differently, which fails under pressure and does not survive staff turnover.

What the interviewer is listening for

  • Names it as a process failure
  • Checks whether actions were completed first
  • Distinguishes system changes from behavioural requests

What sinks the answer

  • Launches a deeper technical investigation
  • Blames individuals for repeating it
  • No plan to track action items

If you genuinely do not know

Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.

Three times after 2 postmortems is [a process failure, not a technical one]. I [read the previous postmortems and check whether actions were actually completed], since [unowned untracked actions are the usual cause]. If they were, [were they the right kind: a guardrail changes what is possible, "be more careful" does not]. Fix is [owners, dates, tracking, and escalation on repeats].

Keep going with troubleshooting

All 87 devops engineer questions

Knowing the answer is not the same as recalling it under pressure

Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.

Start free