Keeping a postmortem blameless after an admission

WHAT THIS TESTS: Whether you genuinely understand blameless postmortems or just recite the slogan. The interviewer is probing how you behave at the exact moment blame is tempting, because that moment defines whether your culture is real.

A GOOD ANSWER COVERS: Start by acknowledging the engineer's transparency, because admitting your change triggered an outage takes courage and you want to reinforce that behavior, not punish it. Then immediately redirect the conversation from the person to the system. The right questions are: what made it possible for this change to reach production and cause harm? Why did code review, automated tests, canary analysis, or monitoring not catch it before or during rollout? What feedback was missing that would have made the danger obvious? The premise is that competent people make reasonable decisions given the information and tools available, so a single person triggering a major outage points to missing guardrails, not a bad actor. Action items target those systemic gaps.

COMMON WRONG ANSWERS: Recording human error as the root cause, which ends the analysis prematurely. Praising honesty in words while the meeting tone or follow-up still singles out the engineer, which is worse than overt blame because it teaches people that admitting mistakes is unsafe.

LIKELY FOLLOW-UPS: What if leadership demands accountability and wants a name? How do you handle repeated mistakes by the same person without becoming punitive? How do you measure whether your postmortem culture is actually blameless?

ONE CONCRETE EXAMPLE: The engineer pushed a config change that took down a region. Instead of stopping at that, the postmortem asks why a single config change could affect a whole region with no canary, no validation, and no staged rollout, producing action items to add config canarying and progressive deployment that protect every future change.