## A Project You Decided Not to Ship Tell me about a time you completed — or nearly completed — a project, but ultimately decided **not** to release it. Walk me through what the project was, why you made the call not to ship it, how you reached and communicated that decision, and what happened as a result. ```hint Pick the right story Choose an example where *you* drove or strongly influenced the no-ship decision, not one that was simply handed down from above. Ownership of the call is what the interviewer is probing. ``` ```hint Center the reasoning, not the build The heart of a strong answer is the judgment and the trade-off — what concrete signal made "don't ship" the right call — not the technical details of what you built. Be explicit about the evidence and the threshold you applied. ``` ```hint Angle that resonates A safety / quality / responsible-release rationale lands well, but any rigorous, honest reason works (data showed no user value or net harm, risk outweighed benefit, a better path existed) as long as you can show the decision criteria. ``` ### Clarifying Questions to Ask - Does the interviewer want a customer-facing product launch, an internal tool/migration, or a research/model release — or is any of these fine? (Pick the one with the cleanest decision story.) - Are they more interested in the decision-making process, the stakeholder management, or the technical signal that triggered it? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How did the people who wanted to ship react, and how did you handle that disagreement? - In hindsight, was it the right call? What, if anything, would you do differently? - How did you decide where the "not good enough / too risky to ship" threshold was? - In general, how do you balance shipping velocity against the risk of releasing something flawed?