TL;DR: "Whose fault" is bait. Give an honest causal chain that names others' contributions without heat, take unprompted ownership of your specific share, and attach a behavior change that later paid off. No villain, no self-flagellation.
How to approach it
The "whose fault" phrasing is deliberately crude, it's bait. Blame the customer and you've failed ("the customer was dumb" is a reported instant-reject). But the opposite overcorrection also fails: claiming 100% personal fault for a multi-party failure reads as either dishonest or theatrical. The graded skill is honest attribution: a clear-eyed causal account where you name the system of causes, take unprompted first-person ownership of your specific share, and show what you changed. Pick a real failure, cancelled, unused, or missed its goal, not a "failure" that secretly succeeded.
A strong answer
"We spent four months building a demand-forecasting tool that the customer's planners never adopted. It quietly died two months after launch.
Whose fault? Let me give you the honest causal chain rather than a single villain. The customer's sponsor oversold internal readiness, the planners were never consulted and saw the tool as a threat. My company staffed it thin on change management. But my share, and this is the part I own, is that I had the evidence early and didn't act on it. In week three, two planners told me directly they'd keep using their spreadsheets. I logged it, mentioned it in a status meeting, and kept building, because building was the part I was comfortable with. The honest version is: I treated adoption risk as someone else's workstream. A signal that strong deserved me stopping the build and forcing a working session with the planners, even though that conversation was awkward and 'not my job.'
What changed in how I work: I now treat 'will anyone use this' as an engineering requirement with the same standing as latency. On every deployment since, I've insisted on a named end-user champion before writing serious code, and twice that rule surfaced an adoption problem early enough to fix. One of those projects is now the customer's reference deployment, which is what the failure bought."
"Whose fault was it" is a trap with two wrong answers and a narrow correct one:
| Answer | How it reads |
|---|---|
| "Mine, entirely" | Unreflective, or performing humility. Nobody fails a project alone |
| "The customer's data was bad" | Deflection, however true it was |
| "The reorg killed it" | You are describing weather, not a decision |
| "Here is the part that was mine, precisely, and here is the context" | The only version that survives the follow-up |
The precision is what does the work. "We under-scoped" is context; "I accepted a scope without seeing the data, because I did not want to slow the deal" is a decision, and it is the one they can respect.
Choosing which failure to bring is half the preparation, and there are four selection criteria worth applying before you rehearse a word. Multi-party: a failure you caused entirely alone cannot demonstrate attribution, and one caused entirely by others cannot demonstrate ownership; you need the tangle. Real cost: something was cancelled, unused, or written off, and you can name the size without flinching. A behavioral share: your contribution must be a decision you made, not a circumstance you endured, because "I was too junior to push back" is a fact about the org and "I raised it once and let it drop" is a fact about you, and only the second can anchor a lesson. And old enough to have paid off: the behavior change needs at least one later story where it worked, or it is a resolution, not a change. The "what would have to be true" probe then has a ready answer built from the same material: for the forecasting story, "a named planner as champion before code, the sponsor's readiness claim tested against one observable behavior (do planners attend the working sessions?), and adoption tracked as a weekly metric from week one." Notice that every item is checkable in the first month; a transferable model is one you could hand to a stranger as a checklist, and that is exactly what the probe is testing you can produce.
What interviewers probe next
- "What was the customer's share, really?" They're testing whether your generosity was honesty or performance. It's fine to say the sponsor oversold readiness, calmly, factually, without heat. Measured attribution of others' contributions is expected; bitterness is not.
- "Why didn't you escalate harder in week three?" Don't dodge: "I conflated raising it once with managing it" is an honest, senior answer.
- "How did you handle the wind-down with the customer?" Show you closed it like a professional: an honest retro with the sponsor, salvaging what was reusable, no ghosting.
- "What would have to be true for that project to have worked?" Tests whether you extracted a transferable model, not just a scar.
Common mistakes
- Any flavor of "the customer didn't get it." Even subtly, eye-rolls about their politics count.
- The fake failure ("we failed... to anticipate how successful we'd be"). Insulting to the interviewer.
- Vague collective fault ("we all could have done better") with no first-person sentence in it. They're listening for "I."
- A lesson with no behavior change attached. "I learned communication is important", versus a named rule you now enforce and a time it paid off.