Tell me about a time you scrapped work you had already sunk weeks into.
answer
- what I built and the bet behind it
- the signal that killed it
- the cost, said out loud
- how I wound it down
- what shipped instead, with a number
basics
~10 sProbes sunk-cost resistance and whether your ego is attached to your own code. Name the work, the signal that killed it, the cost you stated out loud, and what shipped in its place.
how to answer
5 beats- what I built and the bet behind itRoughly the first fifth of your airtime. State what the work was for and why it was a reasonable bet at the time — a doomed-from-the-start setup makes the reversal cost nothing.
- the evidence that made it the wrong betBe specific about what arrived and when: a benchmark, a simpler proposal, a cost nobody had priced. Say how far along you were when it landed, in weeks or in scope.
- the moment I stopped defending itThe heart of the answer, and worth naming an internal move: the reply you deleted, the argument you had ready and dropped. This is what distinguishes a real sunk-cost story from a project cancellation.
- how I wound it down and what it costWith the previous beat, about sixty percent of the airtime. Say who you told, in what order, what you stated the cost to be, and what you salvaged — without arguing the work was secretly worth keeping.
- what shipped insteadClose on the alternative and its outcome with one number, and one sentence on the kill criterion or habit you carry now. Without a result, the story reads as a loss you narrated well.
your answer
4 story prompts- Pick work you personally built and personally stopped, not a project cancelled above you.
- Know the sunk cost in weeks or in scope, and be ready to say it aloud.
- Choose a case where a better alternative actually shipped, so the story has a result.
- Prefer something recent enough that the replacement is still running today.
draft and rehearse your own answer in a learn session
go deeper
This prompt separates ownership from attachment. Interviewers want evidence that you can stop defending your own design once the evidence turns, absorb the cost publicly, and redirect quickly — because sunk-cost defense is expensive and hard to see from the outside. A strong answer shows judgement about when to stop, not just willingness.
On an open-source backend project mid-migration, I spent five weeks building a translation layer that read the old configuration format at runtime and mapped it onto the new one, so operators would never have to touch their files. It was around four thousand lines with a test suite I was proud of. While it sat in review, another contributor posted a smaller idea: a one-shot rewriter that edits an operator's config files in place and shows them a diff to approve. It made my runtime layer unnecessary, and worse, my layer would need maintaining for every future config change, indefinitely. My first reply in that thread was a defense of the runtime approach. I re-read it, deleted it, and wrote instead that the rewriter was the right shape and that a permanent translation layer was a maintenance tax I had not priced. Then I closed my own pull request, and in the closing comment I said what it had cost — five weeks — so nobody would quote a cheaper number later. I spent the following week on the rewriter's edge cases, which was the part I genuinely knew well by then. It handled seventy-one of seventy-eight known config shapes automatically and the remaining seven got a documented manual path. Now, before I start anything speculative, I write down what would make me stop.
The deleted reply is the beat that carries this: it shows the sunk-cost instinct arriving and being overridden, which a summary cannot fake. Stating the five weeks publicly, then contributing to the replacement, is the middle bar. Quietly letting the pull request go stale would downlevel it.
I was one of eleven maintainers on an open-source backend project and I led its storage migration — a thirteen-week program. The in-place upgrade path was my design and I had defended it on two release calls; in-place meant operators could upgrade a running cluster without standing up a second copy of their data, which was the entire pitch for smaller operators. By week seven, nine early adopters were on it. Two of them burned a full month of error budget across one weekend, and the failure mode was the one I had argued was recoverable: a half-migrated table with no rollback that put it back. Recoverable in theory, and not by a solo operator with one on-call engineer and no second copy. I took it to the maintainers' call and said the in-place path was mine and should be dropped rather than patched. Seven of eleven agreed; the rest wanted one more attempt, and I asked them to timebox it to a week instead of overruling them. That attempt failed too, and it bought their agreement cheaply. We restructured the program around copy-and-verify with a hard rollback, which added roughly three weeks and made every upgrade slower. Across the release trains since, burn attributable to upgrades has stayed under 12% per train, and no operator has had to restore from a backup.
Two moves carry the seniority here: killing a design the speaker had publicly championed, and timeboxing the dissenters' attempt rather than overruling them. The result names a real, permanent cost — slower upgrades for everyone — instead of claiming a free win. Overruling the four would have read as authority, not judgement.
Weeks of your own task work is plenty. What matters is that you stopped when the evidence arrived rather than finishing for closure, and that you can say the cost without softening it.
Show the moment of defense you talked yourself out of — the reply you did not send, the argument you dropped. Interviewers want the mechanics of letting go of something you built, plus the better thing that shipped because you did.
The scrapped work should have had other people on it or downstream commitments against it. Explain how you wound it down: who you told first, what you salvaged, and how you kept the team from reading the reversal as blame.
At this scope you killed something you had publicly championed, and the interesting part is the mechanism: how you make stopping cheap and unembarrassing for others — kill criteria set in advance, timeboxed bets, a forum where reversing is normal rather than career-damaging.
saying these in an interview costs you the question
- Framing the abandoned work as secretly valuable so nothing was really lost
- Someone above you made the call and you merely complied
- No number on what the discarded work actually cost
- The reversal happens only when a deadline forces it, not when the evidence arrives
- Audible resentment toward whoever proposed the better alternative
- The replacement never ships, so the story has no result
- Who made the call to stop — you or someone above you?Own it if it was yours. If it was not, be honest and shift the story to your part: whether you supplied the evidence that ended it, how fast you switched, and whether you argued for it afterwards. A borrowed decision presented as yours collapses on the next probe.
- What did you salvage from the work you threw away?Give one or two concrete carry-overs — tests, edge cases you had mapped, a benchmark harness — and keep it brief. The trap is turning this into a rescue of the discarded work's reputation. Say what survived, then return to what shipped instead.
- How did the other people on it react?Name the real reaction, including any frustration, and what you did with it. Strong answers show you absorbed the awkwardness rather than distributing it: telling contributors directly, crediting their effort, and giving them the first pick of the replacement work.