Tell me about a time you had to cut scope to hit a deadline.
answer
- name the fixed date and the risk
- the moment the work stopped fitting
- the true minimum, one user outcome
- cut proposed openly, never dropped silently
- shipped on time; the tail landed dated
basics
~20 sTests whether you protect a fixed date by choosing what not to build. Answer with the true minimum you found, the cut you proposed openly to the people who owned the promise, and what shipped later on a date.
how to answer
5 beats- the date, and why it could not moveTwo sentences: what was being delivered, who set the deadline, and what happened if it slipped. Keep this beat plus your role to about fifteen to twenty percent of the airtime; the interviewer needs the constraint, not the product history.
- the moment the plan stopped fittingSay when you knew and what told you — an estimate that doubled, a measurement that went the wrong way, a dependency that arrived late. A specific trigger makes the rest of the story credible and shows you were tracking rather than hoping.
- the smaller thing you proposedThis and the next beat are the bulk of the answer, roughly sixty percent together. Give the sort you actually used, must versus should versus could or your own equivalent, and the test you applied to each item. Name concrete things you kept and concrete things you dropped.
- how you got agreement and made the cut visibleSay who you took it to, how fast, and in what form. Written options beat a hallway conversation. Be explicit that the deferred work was recorded with an owner, not silently removed from the board.
- what shipped, measured, and where the rest wentClose the loop in the last twenty to twenty-five percent: you hit the date, one number showing the release was healthy, and when the deferred items landed. Finish with a single line of reflection about what you would sort differently now.
your answer
5 story prompts- Pick a release where the date was fixed by someone outside your team.
- Write down what did not ship, then find the first thing you cut.
- Name one number proving the release was healthy, not merely on time.
- Check you can say who agreed to the cut, and when.
- This can be your missed-estimate story, re-angled onto the cut you made.
draft and rehearse your own answer in a learn session
go deeper
Interviewers use this prompt to test delivery judgement and honesty under time pressure. They want to see that you can find the smallest thing that still meets the commitment, negotiate the reduction with the people who own it rather than dropping work silently, and protect a quality floor while doing it. A strong answer proves ownership of both the date and the consequences of the cut.
I was the Android lead on a field-service app for a large industrial customer. Eight of us on the team, eleven weeks to put offline mode in front of their technicians before their winter rollout. The date sat in a contract, so it was not moving. In week six I finished the sync layer and started the conflict-resolution editor — the screen where a tech merges their offline edit with a change someone else made. Two days in, it was obviously closer to three weeks than the four days it had been sized at, and the merge view was doing diff work on the main thread. Our ANR rate in the internal build had gone from 0.14% to 0.52%, past the 0.4% ceiling we ship against. So I wrote a one-page must, should and could list and walked it to our PM and the customer's operations lead that afternoon. Must: offline capture and queued sync for the two work-order forms techs actually fill in the field, out of nine. Should: the merge editor. Could: offline attachments. I proposed last-write-wins with a conflicts screen the tech reviews at end of day, and I said plainly that I could not have both the merge editor and the date. They took the trade. We shipped on the rollout date with the ANR rate at 0.17% through pilot week, and the merge editor went out two releases later, on a date I put in the ticket before we cut it.
The signal sits in the sizing and the openness: a specific week, a threshold breached, a written sort, and a proposal carried to the people who owned the customer promise the same day. It would downlevel if the cut were announced after the fact, or if the deferred screen had no date attached.
I owned the release train for an enterprise workforce app — three squads feeding one store submission every seven weeks. Our largest customer had a contractual go-live for tablet inspections, and the train heading into that window carried twenty-three tickets that three teams all called essential. The previous train had taught me what happens when nobody chooses. We let everything in, submitted nine days late, and stability degraded badly enough that we spent the following week on hotfixes. So I ran this triage differently. I put product, support and the two squad leads in one room and asked a single question per ticket: what breaks in an inspector's shift if this is not there. Nine tickets survived. I also drew a line I stated out loud — stability numbers were not scope, they were the floor, and a feature that only fit by pushing them was the thing that moved. The remainder I split rather than dropped. Six items shipped dark behind a server-side flag so we could enable them per customer after go-live. Eight moved to the next train with named owners and dates, and I sent that list to the customer's programme manager myself instead of letting them find out. We submitted on time and held the ANR rate at 0.22% across the go-live month, against 0.71% on the train before. Four flagged items were on within three weeks. The part I would repeat is the out-loud floor: once quality was outside the trade space, the argument was only about features, which is a far quicker argument to finish.
Release-level ownership plus three moves a smaller answer cannot make put this at senior: a stated quality floor, staging behind flags instead of dropping, and telling the customer directly. It would downlevel if the deferred items had no owners, or if the cut had been made without support and product in the room.
Speak about the slice of work you personally owned. Show that you raised the fit problem early to your lead rather than absorbing it, and that you can say which part of your task was genuinely required and which was polish.
Own the proposal, not just the execution. The bar is that you sized the overrun yourself, wrote down a minimum a reasonable person could argue with, and carried it to product before the date was at risk in public.
Cover the whole release, not your feature. Show that you set the quality floor out loud, ran the triage with the people who own the customer promise, staged the remainder deliberately, and left a practice behind that survived the release.
Talk about the mechanism rather than the episode. The signal is that scope cuts stopped being heroics on your watch: a standing way to sort commitments from implementations, a floor nobody re-argues, and cuts that are visible across teams by default.
saying these in an interview costs you the question
- Cutting quietly and letting product discover it at the demo
- Calling every item a must and missing the date instead
- No number for what shipped, what slipped, or the quality bar held
- Framing the cut as someone else's decision you merely executed
- Deferred work that was never scheduled and never mentioned again
- Counting tests, monitoring or accessibility as the scope you cut
- Who made the final call on what got cut?Name a person or role and be honest about your part. Owning the recommendation while someone else owned the decision is a strong answer; claiming a decision that was not yours reads as inflation. Say what evidence you gave them and how long the call took, so the interviewer hears a process rather than a plea.
- What did users lose because of that cut?Answer directly rather than insisting nothing was lost. Name the workaround people had to live with and roughly how many were affected, then say how you learned whether it hurt. Candidates who claim the cut was costless usually cut nothing that mattered, which makes the whole story smaller.
- Did the deferred work ever ship?This probes whether your cut was real staging or a quiet drop. Say when the deferred items landed, or say plainly that some never did and why the business was fine with that. Either is credible; not knowing the answer is not.
- What would you cut differently now?Pick one specific item and say what you misjudged about it, ideally something you kept that turned out not to matter. Keep it to a sentence or two and connect it to how you triage today, so reflection reads as calibration rather than apology.
## What the prompt is really testing Every team eventually meets a date it cannot move and a plan that does not fit inside it. The interviewer is checking which of the three exits you take: 1. miss the date, 2. burn the team, 3. or change the scope. Only the third is a professional answer, and it is the hardest one to describe well, because a good scope cut looks like nothing dramatic happened. Your job in the answer is to **make the invisible work visible** — the sizing, the sorting, the conversation, the staging. ## Common wordings The same family arrives as: - "tell me about a time you shipped less than you planned" - "describe a project where you had to make a tradeoff to meet a date" - "how have you handled being behind schedule" - and, in manager-adjacent loops, "tell me about a time you had to renegotiate a commitment" Answer all of them with one story, adjusting which beat you dwell on: the **sizing beat** for the schedule wording, the **conversation beat** for the renegotiation wording. ## Weak versus strong on each beat | Beat | Weak | Strong | |---|---|---| | Setup | five sentences of product history before anyone knows what the date was or who set it. | two sentences that establish the date, who owns it, and why it is hard — a customer go-live, a compliance window, an external partner. | | Middle | "we realised we could not do it all, so we prioritised." | the specific moment the work stopped fitting, the number that told you, the list you wrote, and the test you used to sort it. | | Close | "we shipped on time and everyone was happy." | what actually went out, one measurement that shows it was healthy rather than merely on time, and where the rest went with a date attached. | ## Evidence that lands - **Counts** of what shipped against what was planned are the cheapest credibility you can buy — four of eleven screens, two of nine forms. - **A quality number** matters just as much, because the standard suspicion about scope cuts is that you cut the parts that keep software from falling over. Naming a stability threshold you held is the fastest way to kill that suspicion. - Finally, **a date on the deferred work** distinguishes staging from abandonment. ## The trap to avoid Many candidates tell this story as a **heroic solo judgement call**: they saw the problem, they made the cut, they shipped. That answer fails on collaboration even when it succeeds on delivery, because in a real company scope belongs to whoever made the promise to the customer. The move interviewers are listening for is that you converted an engineering problem into a **shared decision** quickly, with enough written detail that a non-engineer could choose intelligently between options. If you cut unilaterally because there was genuinely no time to consult, say that explicitly and say what you did within the hour afterwards to make it known. ## How the bar moves - **At the earlier levels** the story can live inside one feature: you noticed, you flagged it, you proposed a smaller version. - **From senior on**, the interviewer expects release-level scope and a floor you refused to trade — plus evidence that the cut had structure, usually flags or a phased rollout, rather than a smaller pile of the same work. - **At the top of the range** they are listening for the practice you left behind, so that the next date crunch on that team did not need you in the room.