Tell me about a time you were blamed for a failure that was not yours.
answer
- the failure and what you were accused of
- own your genuine share first
- timeline and evidence, not counter-blame
- correct the record where it was written
- the systemic fix that followed
basics
~20 sTests composure and ownership when the account of events is wrong about you. Own your genuine share first, correct the timeline with evidence rather than counter-accusation, and finish on the fix that removed the ambiguity.
how to answer
6 beats- the failure and the account that pointed at youSet the scene in two or three sentences: what broke, who wrote the account, and what it said about you. Keep the setup to about a fifth of your airtime and resist the urge to pre-defend yourself here.
- the part that genuinely was yoursName your real share before you touch the correction, however small it is. This is the beat that buys everything after it, and skipping it is the single commonest way this answer fails.
- the evidence you assembledSay what you gathered and from where: timestamps, logs, change records, both sides' data. Present it as reconstruction rather than as a case for the defence, and avoid naming whoever the evidence points at.
- how and where you corrected the recordTogether with the previous beat this is the bulk of the answer, around sixty percent. Describe the specific ask you made and why it was small enough to be granted, and who you made it to.
- the fix that removed the ambiguityGive the change that means nobody has to reconstruct that timeline again: annotations, a change channel, a two-person rule. This is the beat that turns a grievance into an engineering answer.
- result and where the relationship landedClose in the final fifth with a number where you have one and with the state of the relationship. A relationship that kept working is the proof that you corrected the record without punishing anyone.
your answer
4 story prompts- Pick a failure where you can name your own genuine share, however small it was.
- Choose one where evidence survives: a timeline, a log, a change record you can cite.
- Prefer something already fully resolved, so you can tell it without heat.
- Have the systemic fix ready — this story without a fix reads as a grievance.
draft and rehearse your own answer in a learn session
go deeper
The axis is ownership and composure when the account of events is wrong about you. Interviewers watch whether you own your genuine share before defending yourself, whether you correct with evidence rather than counter-accusation, and whether the working relationship is still usable afterwards. A strong answer ends in a systemic fix, not in a verdict about who was at fault.
Three weeks into an engagement, the client's checkout edge was down for 63 minutes on a weekday evening. The incident summary that went to their director said the outage followed the consultancy's infrastructure change, and that change was mine. My first move was to own the part that really was mine. I had applied the change that afternoon and had not posted it in the shared change channel, so from where they sat I was the only visible change of the day. I said that on the follow-up call before I said anything else. Then I put a timeline in front of them instead of an argument. My apply finished at 14:52 and the first error spike was at 19:11, more than four hours later, right after a TTL change I found in their own DNS audit log. I did not name whoever made it. I also did not ask for the summary to be rewritten. I asked that the timeline be attached to it, which is a much smaller thing for a director to say yes to. He attached it. We then put change annotations on the incident dashboard so every apply from either side lands on the same graph. The next two failures of that shape were restored in 19 minutes, because nobody spent the first half hour guessing what had changed. The engineer who wrote that summary and I worked together for another year. I never made him defend it.
The genuine ownership comes first and it is specific, which is what earns the correction a hearing. The move worth stealing is asking for the timeline to be attached rather than the summary rewritten. Leading with innocence, or naming who really broke it, would sink this answer.
I was delivery lead on an account with two of my engineers embedded in a client's platform group. Their control plane lost its scheduler for most of an afternoon, and the client's operations director opened the review by saying our automation had caused it and that he wanted my people off the shared components. I took the ownership publicly and immediately. Our automation had run, and I had approved a process that let it run without a second pair of eyes, so if that process was wrong it was my call and not my engineer's. That moved the target off her and onto a decision, which is something you can actually fix. Then I asked for two days before anyone agreed a conclusion, and used them to reconstruct the afternoon from both sides' logs. The trigger was our job, which had been safe for months. What had changed was a shared component that quietly lost its quota guard in the client's own release. I presented both of those facts together and in that order, so it did not read as a defence. We restored the guard, added a two-person rule for anything touching shared components, and I started sending a weekly change digest nobody had asked for. The account's median restore time settled at 21 minutes that quarter, down from 52. My engineer stayed on the account and ran the next review herself.
Senior signal: blame aimed at a report is absorbed and converted from a person into a decision, and time is bought before the conclusion hardens. The guardrail and the digest show ownership continuing past the incident. Defending the team without owning the process would downlevel it.
Own-task scope. It is enough to show you stayed calm, established what you had actually done and when, and asked a question rather than argued. Nobody expects you to have redesigned a process at this stage.
Feature and peer scope. Show the mechanics of correcting a record: what evidence you gathered, where you took it, and how you phrased the ask so the other side could agree without having to admit they were wrong in public.
Team and production scope. You are expected to take blame aimed at your engineers onto yourself, convert it from a person into a decision or a missing guardrail, and land a prevention that outlives the incident.
Organisational scope. Talk about why the wrong account formed at all, which is usually incentives and who writes the summary, and about the mechanism that now gets bad attributions corrected without you in the room.
saying these in an interview costs you the question
- Spending the whole answer establishing that you were innocent
- Naming and convicting whoever actually caused the failure
- No acknowledgement of any part you genuinely owned
- Emotional retelling with no timeline, log or artefact as evidence
- Letting the wrong account stand and calling that professionalism
- A result that is a verdict about people rather than a change to the system
- What would you do differently?Answer with a process change you control, not a wish about someone else's behaviour. The strongest version names the thing that made the misattribution plausible in the first place: an unannounced change, an unlabelled dashboard, a missing entry in a log. Saying you would have escalated faster is weak unless you can say what escalating would have produced.
- Did you find out who actually caused it, and what did you do with that?This is a discretion test. Say that you established the mechanism, and that what you did with the name was nothing public. Show that you brought the trigger to the review as a condition of the system rather than as an accusation. If you did name someone, be honest about it and about what it cost you.
- How did your own team react while the wrong version was circulating?Interviewers are checking whether you contained it. Describe what you told your team: the facts you had, that you were handling the record, and that nobody should be relitigating it in side channels. A team that spent a week angry on your behalf is a result you owned too, so do not skip past it.
- Have you ever been blamed and then found you were partly at fault?Say yes and tell it briefly, because everyone has. This follow-up rewards candour more than the original story does. Show the moment the evidence turned against you, what you said when it did, and how quickly you said it. Insisting you have never been in that position is the answer that costs you the most.
## What is being scored The interviewer already knows you think you were innocent, because that is the premise of the question they asked. Everything you spend on proving it is airtime you are not spending on the thing being scored, which is **how you behave while the record is wrong** and other people are watching. ## Common wordings - *Tell me about a time you were unfairly criticised* - *a time you were blamed for something outside your control* - *how do you react when someone gets the story wrong about you* - and the incident-flavoured *tell me about a post-incident writeup that pointed at the wrong cause*. The incident version is more common in infrastructure and platform loops and it is the easiest to answer well, because incidents come with timelines and logs. ## The ordering that separates strong from weak Strong answers **own their genuine share** before defending anything. There is almost always a real share: a change you did not announce, an alert you had muted, a handover you rushed. Naming it first does two things: 1. It makes you credible for the correction that follows. 2. It demonstrates the exact instinct the question is probing, which is that your first move under accusation is inward rather than outward. Weak answers invert this, and once an answer opens with a defence, everything after it reads as more defence, including the parts that are simply true. ## Correct the record, do not win the argument The tactical move worth stealing is **asking for something smaller than you want**. A summary that has already gone to a director is hard to retract and easy to append. Asking for the timeline to be attached, or for a line to be added, gives the other person a way to fix the record without a public reversal, and it usually gets you a yes on the same day. Candidates who demanded a rewrite tend to report that they were right and that nothing changed. ## Evidence beats assertion, and mechanism beats evidence A timeline that shows your change landed hours before the first symptom is good. A dashboard that now annotates every change from either side, so nobody has to reconstruct that timeline again, is better, and it is the beat most candidates leave out entirely. The interviewer is trying to work out whether you would leave their organisation less ambiguous than you found it. ## How the bar moves - In the **junior band**, composure and factual accuracy are enough. - In the **middle band**, you are expected to have done the correction yourself, in writing, without help. - At **senior level** the blame is often aimed at one of your people, and the expected move is to pull the target onto a decision you made, because a decision can be changed and a person can only be punished. - At **principal level** the interesting question is why the false account was written at all, and the answer usually lives in who owns the incident narrative and what it is used for. ## Two things that sink otherwise good answers 1. **Naming the culprit**, even accurately, reads as someone who would do the same to a colleague in this company. 2. And **an answer with no result at all**, which happens a lot here, because the story feels finished the moment the speaker is exonerated. It is not finished. The interviewer wants the fix.