Tell me about a time you called off an approach your team had already spent weeks building.
answer
- the bet and how much was sunk
- cost of continuing versus stopping
- how you called it, out loud
- what was salvaged, who was protected
- the kill criterion you set now
basics
~20 sTests whether you can weigh the cost of continuing against work already sunk, and stop it cleanly. Show the evidence, the moment you made the call explicit, what you salvaged, and how you shielded the people whose work stopped.
how to answer
6 beats- the approach and how much was already investedSet up in a couple of sentences: what the team was building, whose call it originally was, and roughly how much time was already in it. Say plainly if the approach was yours to begin with — that raises the stakes and strengthens the answer rather than weakening it.
- the evidence that continuing was the worse betGive the measurement or observation that changed the arithmetic, and admit the pull you felt toward pushing through. An answer where stopping was obvious teaches nothing; the interviewer is listening for a real comparison between finishing and stopping.
- how you made the stop decision explicitThis beat and the next carry most of your airtime, roughly sixty percent together. Describe the mechanism — the assumptions you wrote down, the timebox you gave them, the meeting where you said it — and the words you used with the people who had built the thing.
- what you salvaged and who you protectedBe concrete about which pieces moved forward and which were genuinely discarded. Say what you did so the engineers' work stayed visible and their standing intact; this is the beat most candidates skip and the one that separates a manager of code from a leader of people.
- the outcome after the change of courseGive the result of the replacement approach with a number, and state the sunk cost honestly alongside it. Naming the weeks that were lost makes the recovery credible instead of triumphant.
- the trigger you now set in advanceFinish with the exit condition you now agree before work starts — a kill criterion, a review date, an adoption threshold. One sentence, stated as something you actually run, is enough to close the answer at the right altitude.
your answer
5 story prompts- Pick work you actually stopped, not work that quietly ran out of funding around you.
- Note how many engineer-weeks were already sunk when you made the call.
- Write the sentence you said to the people whose work you stopped, verbatim.
- List which pieces survived into the replacement and which were genuinely discarded.
- State the exit condition you now agree before starting work of that size.
draft and rehearse your own answer in a learn session
go deeper
This probes judgement under sunk cost and the ownership of an unpopular decision. Interviewers want to know whether you compare the cost of continuing against the cost of stopping using evidence, whether you can make the stop an explicit decision rather than letting work starve quietly, and whether you protect the standing of the people whose effort you ended.
We were rebuilding the reporting workspace inside a large enterprise portal, and the plan I had approved was to send the full dataset to the browser and do all filtering client-side so interactions would feel instant. Two engineers I mentor had built most of it. In week seven, the first honest measurement on the oldest laptops we support came back at 6.8 seconds to interactive, and on the lower-memory machines the tab was being dropped entirely. My instinct was to optimise our way out. The code was good, we were close, and I had signed off on the direction. So I wrote a one-page note listing what would have to be true for the approach to survive, gave it a three-day timebox, and we tested the two cheapest assumptions in it. Both failed. I stopped the work that Wednesday and told the group that the seven weeks were the price of my approval, not of their engineering. Then I made the salvage explicit instead of sentimental. The filter interface, the query model and the test harness all moved across to a server-paginated version; the streaming layer went in the bin. I paired with both engineers on re-landing their own pieces so their names stayed on the work, which mattered to them more than I had expected. The rebuilt workspace came in at 2.4 seconds on those same old laptops. Since then anything longer than a sprint starts with a written kill criterion — the measurement that would make us stop, agreed while nobody is attached to the code yet.
The level shows in the stop being engineered rather than declared: assumptions written down, a short timebox, then a decision on a named day, with the cost attributed to the candidate's approval and not the team's code. Pairing to re-land salvaged work is the ownership beat; without it this reads as a competent technical reversal only.
I sponsored a division-wide bet: a single shared rendering platform for fourteen customer-facing front ends, on the theory that one paved path would lift performance everywhere. Two staff engineers championed it with me, and I ran a monthly guild to coach teams through adoption. Two quarters later the numbers were quietly embarrassing. Five of the fourteen applications had adopted, the average improvement in time to interactive was around 180 milliseconds, and the guild had turned into migration support rather than teaching. The bet was not failing loudly. It was consuming attention at a rate the gains could not defend. I ended it in the same forum where I had launched it, in the first five minutes rather than after the good news, and I named the price out loud: roughly a hundred engineer-weeks across the division. I also said, in that room, that the two engineers carrying it had executed the strategy I set and that the strategy was the part that was wrong. Reputational cover is cheap for me to give and expensive for them to earn back. What replaced it was narrower and measurable: a performance budget enforced in the pipeline, plus a paved path for only the three highest-traffic applications, where the worst offender moved from 4.6 seconds to 2.9 within a quarter. The decision record stayed open with the reversal and the evidence attached. The mechanism I run now is an adoption threshold and a review date agreed before a platform bet starts, so ending one is a scheduled decision rather than a reputational event.
This works because the bet is sized in engineer-quarters, the reversal happens in public in the same forum that launched it, and the candidate transfers credit for execution while keeping the strategy error. The closing mechanism — thresholds and review dates set upfront — is what makes it org-level rather than a large team story.
You may never have stopped a team's work, and inventing that is worse than answering smaller. Use work of your own you scrapped, and show you raised the doubt with your lead before sinking more days into it.
Scope is your own feature or slice. The signal is that you tested the shaky assumption early and cheaply rather than after the build, and that you were the one who said the approach was not going to hold.
You are expected to own the call for other people's work. Show how you made stopping a decision with a date and a stated reason instead of a slow starve, what you salvaged concretely, and how you kept the engineers' contribution visible.
Talk about bets sized in engineer-quarters and about ending one where reputations are attached. The mechanism matters more than the episode: adoption thresholds, review dates and exit conditions agreed before the work starts.
saying these in an interview costs you the question
- Presenting the stop as obvious, with no honest pull toward pushing through
- Letting someone senior make the call and narrating it as your own
- No attention to the people whose weeks of work were stopped
- Stopping by drift — the work quietly starved instead of a decision being made
- Salvaging nothing and describing the whole effort as pure waste
- Turning the story into blame of whoever proposed the approach
- How did the engineers whose work you stopped react?Answer honestly, including any disappointment or pushback, and describe what you did about it rather than claiming everyone agreed immediately. The strong version has a specific act of repair — salvaged components re-landed under their names, a conversation before the announcement, credit given in a forum where it counted. Serene universal agreement sounds rehearsed.
- What would it have taken to keep going instead?Show that you priced the alternative rather than dismissed it: the remaining work, the assumptions that would have had to hold, the ceiling you would have hit anyway. This proves the decision was a comparison and not an impulse. If continuing was genuinely viable and you still stopped, say why the expected value did not justify the attention.
- How much earlier could that call have been made?Name the earlier checkpoint honestly and what stopped you from testing there — usually momentum, a hope that the next optimisation would land, or a measurement deferred until the build was complete. Then connect it to the trigger you now set in advance, so the answer ends on a process change rather than on regret.