Tell me about a project you worked on that failed, and why it failed.
answer
- project goal and your seat in it
- your own slice, owned plainly
- causes as decisions, not personalities
- how it ended, with one number
- what got salvaged and reused
basics
~20 sTests whether you attribute causes fairly instead of blaming people. Pick a project that genuinely died, explain the failure as a chain of decisions, own your slice of it, and say what the team kept.
how to answer
5 beats- the project, its goal, and your seat in itTwenty to thirty seconds: what it was meant to achieve, who was involved, and exactly what you owned. Situation and task together should be no more than a fifth of the answer, and the interviewer only needs enough context to follow the causes.
- what you personally built or droveMake your own work concrete before the story turns bad, so the failure has something to attach to. Say I, not we, for the parts that were yours. This is what lets you own a slice later without sounding either boastful or self-flagellating.
- how it went wrong, as a chain of decisionsThis is the bulk of the answer, around sixty percent. Give two or three causes and describe each as a decision made with the information available, including one that was yours. Never name a person as the cause; name the choice, the missing evidence, and the moment it could have been caught.
- how it ended and what it costState the ending in one clean sentence with a number in it: the metric that moved the wrong way, users affected, or effort spent. Do not soften a cancellation into a pause. A crisp cost sentence is what makes the whole story credible.
- what was salvaged and what you changedClose on value that survived — code, tests, a decision record, a measurement other teams still use — and one habit you now hold because of this. Result and reflection together are the last quarter of the answer, and the habit should be stated in the present tense.
your answer
5 story prompts- Pick a project that actually died or shipped and flopped, not one that merely ran late.
- Choose one where you can name your own contribution without it being the headline cause.
- Have one number ready for how badly it went: users, weeks, spend, or a metric.
- List what the company kept afterwards — code, tests, a decision record, a hire.
- This can be your missed-deadline story re-angled, if the work truly ended in failure.
draft and rehearse your own answer in a learn session
go deeper
This probes cause attribution and ownership under a bad outcome. Anyone can sit on a project that dies; the signal is whether you separate decisions from personalities, name your own contribution without inflating or hiding it, and show that months of effort still left something behind. It also reads resilience — whether the failure made you sharper or resentful.
I was one of twelve engineers at a fitness-tracking startup, and my first real project was route tracking for runners. I owned the background location sampler on Android. We planned it for one release window and it slid by two sprints. There wasn't a single bad call behind that. We had committed to a sampling interval before anyone measured it on cheaper handsets, and my sampler kept the GPS radio awake between reads, because I copied the pattern from our existing tracker without checking what it cost. On the devices most of our users had, battery drain per session went from 1.4 percent to 3.8 percent. Our beta group was 640 people, and roughly a third switched the feature off within twelve days. Leadership shelved it. My part was specific. I saw the drain in my own testing about eleven days before we admitted the slip, and I filed it as a bug instead of raising it in standup as a risk to the release date. That delay cost us the window where we could still have changed the sampling design. What I salvaged was the little harness I'd built to compare drain across handsets. Two other feature teams picked it up, and it's still how we gate power changes. Since then, when I see a number moving the wrong way on something we've already committed to, I say it out loud the same day rather than filing it and waiting for someone to notice.
Right shape for early career: one clearly owned task, a cause chain that includes the candidate's own delay without making it the headline, a hard number for the ending, and a salvaged artefact. Stating the new habit in the present tense is what turns it from an apology into growth. Vaguer causes or no number would downlevel it.
I was the engineer responsible for offline sync in our workout app at a small health startup — three of us on the client side plus two backend people. A user could record a session with no signal, and it would reconcile later. It failed, and the fair account has three causes rather than one. First, we designed the conflict model around an assumption nobody tested: that two devices editing the same session would be rare. In the beta it happened for nine of the forty most active accounts. Second, our retry loop held a wake lock while waiting on the network, so battery drain per session climbed from 2.2 percent to 5.1 percent on mid-range hardware. Third, and this is mine, I kept extending the schedule a week at a time instead of putting one honest re-plan in front of people. We spent eleven weeks on something that would have been stopped at week five if I'd been clear. We cancelled it. Two things survived: the reconciliation test suite became the base of the sync tests we still run, and I wrote a two-page decision record on why device-level merge was the wrong shape, which stopped the same proposal coming back the following quarter. The habit I took from it is that I write down the assumption a project dies on before we start, and put a date on when we'll test it.
Feature-level ownership carries this: three causes with the coordination failure owned plainly, evidence from beta usage rather than opinion, and salvage in two forms — reusable tests and a decision record that changed later choices. The stated pre-mortem habit is the growth beat. Blaming the untested assumption on someone else would downlevel it immediately.
Nobody expects you to have chosen the project or set the plan. Show your own task honestly: what you built, what you noticed, when you said it, and the one thing you now raise earlier.
Answer at feature scope. Name the assumption your piece rested on, how you worked with the people either side of you, and how the bad news travelled. Your slice should sit among several causes, not stand alone.
You are expected to have seen it coming and acted on it: the evidence you gathered, when and how you escalated, and the re-plan or kill you proposed. Add the guardrail that outlived the project.
Answer at portfolio scope: why the bet was taken at all, what the organisation learned about choosing bets, and the mechanism you left behind so the next doomed effort is stopped in weeks rather than quarters.
saying these in an interview costs you the question
- Blaming leadership or another team for every cause
- Telling a failure story where you had no part at all
- No number or evidence for how badly it went
- Ending at the collapse with nothing salvaged or learned
- Relitigating that you were right the whole time
- Picking a failure so small it costs you nothing to admit
- What was the earliest point at which someone could have called it?Name a specific moment and the signal that was already visible then. Be honest about who could have acted, including you, without turning it into an accusation. The interviewer is testing whether you can reason backwards through a timeline rather than treating the failure as weather that simply happened to you.
- What would you do differently if you ran that project again?Give one or two changes at the decision level, not a wish for more time or better luck. Good answers name a checkpoint, an experiment run earlier, or a conversation held sooner. Then say whether you have actually done it since — a change you can point to in later work is far stronger than an intention.
- How did the rest of the team take it when the project was stopped?Show awareness of other people without speaking for them. Describe the mood plainly, what you did with your own share of the disappointment, and anything you did to keep the group functional. Avoid painting yourself as the sole adult in the room; a short, honest observation reads better than a rescue narrative.
## What the interviewer is scoring This prompt arrives in several wordings that all want the same thing: - "tell me about a project that failed" - "a project that did not go well" - "a piece of work you would call a failure" - and the team-flavoured "tell me about a team failure you were part of". The last one is not softer — it is bait for candidates who use "we" to hide behind. Whatever the wording, the interviewer is scoring three things: your **attribution**, your **honesty about your own part**, and what **value you extracted** from a dead effort. ## Attribution is the real axis Projects fail through chains, not villains. A strong answer sounds like a short causal account: 1. an assumption nobody tested, 2. a commitment made before the assumption was tested, 3. a signal that appeared but was filed rather than escalated, 4. and a decision to stop that came later than it should have. A weak answer sounds like a cast list — the other team was slow, priorities kept moving, the plan was unrealistic from the start. Everything on that list may be true, and it still fails the question, because it shows a person who narrates rather than reasons. The practical fix is to describe every cause as a decision someone made with the information they had, and then say what information was missing and why. ## Story selection matters more here than in most behavioural prompts Three traps. 1. **First**, do not bring a story where the failure was your single bad change or your outage — that is a different question and the interviewer will feel the mismatch. 2. **Second**, do not bring a project that merely ran late and then shipped; late is not failed, and the answer reads as evasion. 3. **Third**, do not bring a project you joined for two weeks at the end, because you will have nothing to own. The ideal story is one where you had a real seat, the outcome was clearly bad, and you can name a specific contribution of your own that is genuine without being the headline cause. ## Evidence types that land - **Numbers first**: users who churned or turned the feature off, the metric that moved the wrong way, weeks or months spent, the size of the group involved. - **Then artefacts**: a test harness, a decision record, a measurement dashboard, a spike result that saved the next team from the same path. - **Then behaviour change**: something you now do differently that you can date to this project. One of each is plenty; a list of four numbers with no reflection is as unbalanced as reflection with no numbers. ## The airtime failure is structural Most people spend ninety seconds explaining what the product was and ten seconds on the ending. Keep setup to a fifth of the answer, spend the bulk on how it went wrong and what you did inside it, and reserve the last quarter for outcome, salvage and change. If you cannot state the ending in one sentence with a number in it, the story is not ready. ## How the bar moves - **Early in a career** the answer is about noticing and speaking; a junior who saw the drift and said nothing for a fortnight, and now says such things the same day, is telling a good story. - **In the middle** the answer is about coordination and honest re-planning. - **At senior** the interviewer wants evidence you tried to change the outcome — escalation with data, a proposed kill, a checkpoint you added afterwards. - **Above that**, the interesting content is how bets get chosen and stopped at all, and the answer stops being about one project. ## Closing honestly Finally: do not perform equanimity. A project dying after months is genuinely deflating, and one honest sentence about that reads as human. What must not follow it is bitterness. The line the interviewer is listening for is the one where the failure changed something you do, stated in the present tense.