TL;DR: Correct the facts calmly and early, in writing, without fighting mid-incident; let the postmortem timeline assign causality; correct the public record once, then repair the relationship privately, because you will stand on the next bridge call with these same people.
How to approach it
Split the situation into two jobs: getting attribution right through process, and keeping your own temperature down. Interviewers are screening for emotional regulation under unfairness plus whether you think in systems (contributing causes) rather than culprits. Visible anger in the telling sinks this answer faster than any fact could.
A strong answer
During the incident, do not litigate. The only acceptable sentence about fault while customers are hurting is a factual timestamp: "Timeline shows the schema change landed at 14:02 from the nightly job; mitigation is rolling it back." Arguing ownership mid-incident extends the outage and both arguers lose standing.
Afterwards, work the mechanism instead of the grudge. Bring evidence to the postmortem: the timeline, the deploy log, the chat excerpt where the change was announced. Propose contributing-causes framing: the change lacked a review gate, monitoring missed the leading indicator, rollback took forty minutes because it had never been rehearsed. A chain of causes protects everyone, including you, and produces actual preventive work. If the organisation has no blameless postmortem practice, this incident is your opening to propose one.
If blame survives into public forums, a status review or an email chain, correct it once, briefly, in the same forum, with artefacts: "Sharing the timeline. The trigger was the upstream cache flush at 13:58, before my change landed. Happy to walk through it." Calm, once, documented, then move detail offline. Repeating the correction reads as defensiveness and dilutes the first one.
Repair privately. Talk to the person who blamed you, assuming pressure rather than malice: "That call was rough. The attribution landed on me and did not match the timeline. Next time let us check the deploy log before naming owners." Most people retract in private what they said in panic, and that conversation buys you fair treatment on the next call.
Watch for pattern, not instance. One panicked misattribution is human. A culture of scapegoating is data worth raising with your manager, with examples, and weighing when you decide where to stay.
What interviewers probe next
"Would you name who actually caused it?" In the postmortem document, yes, as timeline fact. Headlines name chains and missing gates, not people. Honest errors get system fixes; negligence patterns get performance conversations, and those run through different processes.
"Your manager watched and said nothing. What now?" Ask them directly to correct it upward, once. If it does not happen, recalibrate how much benefit of the doubt that relationship gets, and keep your own record straight regardless.
"Does blameless mean nobody is accountable?" No. Accountability includes repairing the system and following through on commitments. Repeated review bypasses require evidence about expectations, incentives and circumstances, with the manager handling any performance process. A count of two is not a diagnosis of character.
Common mistakes
Fighting mid-incident for vindication while customers wait, then losing the moral high ground along with the outage.
Public sarcasm or counter-blame in channels that screenshot forever.
Swallowing it and telling the interviewer you "just moved on", which reads as inability to advocate for yourself or your team.
Retelling the story with visible residue. If you still sound burned years later, the interviewer concludes you were the difficult colleague.