Tell me about killing a project you championed.
- 1 min — what you championed and why
- 2 min — the evidence and the pre-agreed criteria
- 1 min — the dissenting sponsor and how you persuaded them
- 1 min — what was salvaged, where people went, the regret
This tests whether you can separate your ego from the evidence, set kill criteria in advance, and make the stop useful — salvaging assets and lessons rather than quietly letting it drift.
AI projects that should be killed are common: an multi-agent system that a simple workflow beats, a fine-tune that a better prompt matches, a feature with no retained usage.
Staff answers show the kill criteria existed before the result, the decision freed real capacity, and the stop was communicated so other teams didn't repeat the attempt.
What the answer sounds like at each level
Stopped their own approach after a better alternative showed up in review.
Stopped a team project against sponsor resistance using pre-agreed criteria, and salvaged the useful parts.
Stopped an initiative they had sold to leadership, redeployed people to higher-value work, and changed how the org sets kill criteria.
Follow-ups the interviewer will push
1How did you tell the team?
Before the sponsor meeting, in person, with the data, and with what each person's work fed into next. The policy-lookup tool shipped, so their work reached users.
2What would have made you continue?
A clear trend toward the criteria — say +2 points a month on resolution — or a class of complex claims where the agent was clearly better and big enough to matter. Neither existed.
Red flags interviewers listen for
- The project was killed by someone else and the candidate just went along.
- Blames the technology or the team; no ownership of the original pitch.
- No criteria — 'it just didn't feel right'.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Evidence | Same eval set, cost and latency, real users timing both. |
| Ego | Credits the junior engineer's baseline; owns the original pitch. |
| Outcome | Capacity redeployed and a measurable result from the simpler option. |
Stopping our multi-agent claims assistant
Illustrative exampleI had pitched and led a multi-agent assistant for insurance claims adjusters: a planner, a policy-lookup agent, and a drafting agent. After four months with a team of five, it resolved 62% of cases on our 400-case eval set at ~$1.10 per case and 40 s median latency.
We'd agreed up front that it had to beat the existing rules-plus-template flow by 10 points on resolution or halve adjuster handling time. I had to decide whether to keep going.
A junior engineer on the team built a single-call prompt chain baseline over a weekend; I insisted we evaluate it on the same 400 cases rather than dismiss it. It scored 59% at $0.08 per case and 6 s. The claims operations director — our sponsor — pushed to keep the agent because it demoed better. I showed him the side-by-side on 20 real cases with adjusters timing both; the 3-point gap didn't change handling time. I recommended stopping, wrote the decision doc, and moved the policy-lookup tool into the simpler chain.
We shipped the chain in three weeks; it cut median handling time from 14 to 9 minutes across ~80 adjusters. Two engineers moved to a fraud-signals project that shipped that quarter. My regret: the kill criteria were in a slide, not in the eval harness, so it took a weekend experiment to force the comparison we should have run in month one.