Tell me about a time a project you'd invested months in was cancelled.
answer
- the work and how far it got
- why it was stopped, stated plainly
- your first reaction, honestly and briefly
- what you rescued from it
- how fast you re-engaged
basics
~10 sProbes resilience when the outcome was not yours to control. State the real reason for the cancellation without bitterness, show what you pulled out of the work, and how quickly you re-engaged.
how to answer
5 beats- what the work was and how far it had gotGive the goal, your role and the state at cancellation in a few sentences — near-complete reads very differently from an early prototype. Keep this to roughly a fifth of the answer; the interesting part is everything after the call.
- the moment it was stopped and the reason behind itState the reason as the decision-maker would state it: a strategy narrowing, a partner falling away, a budget shifting. If you disagreed, one clean sentence is the whole allowance. Contempt here sinks the answer faster than anything else.
- your honest reaction, in a sentence or twoSay plainly that months of work ending stung, then move on. Skipping this makes you sound rehearsed, and dwelling makes you sound fragile. What you do next is the actual content.
- what you pulled out of itThis is the bulk of the answer. Name specific things that survived — a component merged into live code, instrumentation kept, a written record of what was learned, a relationship or a skill. Concrete artefacts beat any claim about attitude.
- how you re-engaged and what you ask for nowClose with how quickly you were productive again and, if you led others, how you got them there. End on something you now do earlier — asking for kill criteria at the start, or checkpoints tied to evidence rather than dates.
your answer
4 story prompts- Pick work cancelled by a decision above you, after at least a few months of effort.
- Write one sentence on why it was stopped that the decision-maker would agree with.
- Name two concrete things that survived: code, a document, instrumentation, a skill.
- Note honestly how long it took you to fully engage with the next thing.
draft and rehearse your own answer in a learn session
go deeper
This reads resilience and maturity about decisions above your level. The interviewer wants to know whether sunk effort makes you bitter, whether you can explain a business call you did not make without editorialising, and whether you treat a shutdown as work with deliverables — salvage, documentation, redeployment — rather than as something done to you.
At a consumer coaching-app startup I spent about five months on a tablet companion build, with three other engineers. It was close: the layouts were done, and we'd got the tablet build's battery drain per session down from 3.3 percent to 1.6 percent by moving the animated session view onto a cheaper rendering path. Then the company raised less than it planned and cut the roadmap to phone-only. Tablets were around seven percent of our active users, so honestly it was the call I'd have made with the same numbers — it just wasn't the one I wanted after five months. It did sting for a few days. What I did with that was spend the last week of the sprint harvesting rather than tidying up. The low-power rendering path went into the phone app, where it took a noticeable slice off drain during long sessions. The power instrumentation we'd built for tablets became the dashboard the whole mobile team uses. And I wrote up what we'd learned about layout costs on large screens, because we clearly weren't going to remember it in a year. I was fully into the next piece of work inside a sprint. The thing I changed is that I now ask, at the start of anything long, what would have to become true for us to stop this — and I want the answer written down where the team can see it.
Strength here is the fair restatement of the business reason with the number that supports it, one honest sentence about the sting, and three specific salvaged artefacts. The closing ask for stop criteria is the growth beat. Editorialising about the funding decision would have flipped this answer from mature to bitter.
I led nine engineers for about seven months on an in-app coaching experience at a mobile health startup, built around a content partnership. The partnership fell through in renegotiation, and with it went the reason for the feature. I heard on a Thursday and told the whole group the same afternoon, before it leaked as a rumour. I did that deliberately: the worst version of this is people finding out in fragments over a fortnight. Then I treated the shutdown as a project. We spent four days on close-out. I pushed to keep two things and got both: the audio streaming path, which we merged into the main app and which cut battery drain per session on long listening from 2.8 percent to 0.9 percent, and the offline content cache, which another team was about to build from scratch. Everything else was archived with a short note on why, so nobody re-derives it. The part I cared most about was people. I had one-to-ones with all nine inside three days and had every one of them on named work before the next sprint started, because idle time after a cancellation is where good engineers start browsing. One asked to move teams and I backed her. Since then, I insist that anything depending on an external agreement has a checkpoint tied to that agreement's status, not to a delivery date.
Senior signal sits in the sequencing: communicate fast, run close-out as real work, negotiate specific salvage, then redeploy people before idle time sets in. The retained-component number gives the salvage weight, and the external-dependency checkpoint is a reusable mechanism. Dropping the people beat would downlevel this to an individual-contributor answer.
Focus on your reaction and how fast you were useful again. Show that you asked why, understood the answer well enough to repeat it, and moved onto the next thing without dragging the mood around.
Explain the business reason in your own words as if you agreed with it, then show you actively harvested the work — merged a reusable piece, wrote down what was learned — rather than letting a branch rot.
You were probably carrying other people's morale too. Cover how the team heard it, what of their work you protected, and how you got them onto meaningful work without a limbo stretch in between.
Talk about the decision process itself: kill criteria agreed in advance, the checkpoint that surfaced the call, and how the sunk investment was recycled across teams instead of written off.
saying these in an interview costs you the question
- Framing leadership as capricious, clueless or political
- A story that ends in resentment or a resignation
- Claiming nothing at all could be salvaged
- Insisting it did not bother you in the slightest
- Picking work that was cancelled after a few days
- Still arguing the project should have continued
- Do you think the decision to cancel was the right one?Answer directly. If you think it was right, say why in the decision-maker's terms — cost, evidence, opportunity. If you think it was wrong, disagree on substance in two sentences and then say what you did anyway, which shows you can commit to a call you lost. Hedging reads worse than either honest position.
- How long did it take you to get properly engaged in the next thing?Give a real duration rather than claiming instant recovery, and say what helped: a clear next assignment, closing the work out properly, or a conversation about what happens to the code. A candid week or two with a reason reads as self-aware; a flat none reads as performance.
- What did you do with the work that had already been built?Name concrete outcomes: a component merged elsewhere, benchmarks or instrumentation retained, a written record of what was learned, a branch deliberately archived with a note. The point is that you treated shutdown as work with its own deliverables rather than an event that simply happened to your branch.