When a release date can't move and the work won't fit, how do you decide what to cut?
answer
- start from the promise, not the backlog
- one test: what breaks without it
- quality floor is never a should
- stage the rest behind a flag
- publish the cut with owners and dates
basics
~20 sTests whether you have a repeatable triage instead of instinct. Answer with the one outcome you protect, the test that sorts must from nice-to-have, the quality floor you never trade, and how deferred work stays visible with dates.
how to answer
5 beats- start from the commitment, not the ticket listOpen by saying you first pin down what the release actually promises someone and to whom. Interviewers hear this as the difference between prioritising a backlog and protecting an outcome.
- the test that sorts must from the restGive the exact question you ask of each item, in your own words — something like what breaks in this person's day without it. Being able to state one test is what separates a method from a vocabulary of buckets.
- the floor you never put in the tradeName what is not scope: stability thresholds, security, anything irreversible. Say it in the register you would use with a product partner, because the point is that you make this explicit before the argument starts, not during it.
- how the remainder is staged and made visibleCover both halves: what ships dark behind a flag or lands in a later release, and how the people expecting it find out from you rather than by noticing. Owners and dates are the concrete detail here.
- one short example of the method deciding somethingClose with thirty seconds of evidence: a release where you applied this, what got kept and what did not, and what it cost or saved. Without this beat the answer stays theoretical and interviewers discount it.
your answer
5 story prompts- Write your sorting test as one sentence you could say out loud.
- Name the two things you would refuse to trade, and why.
- Find one release where your method changed what shipped.
- Note who you involve in the call besides engineering.
- Check you can say where deferred items went and when.
draft and rehearse your own answer in a learn session
go deeper
This prompt probes prioritisation judgement and decision-making rather than a single episode. The interviewer wants to hear a method you can actually apply under pressure: how you identify the real commitment, how you sort work against it, what you refuse to trade, and how the reduction is communicated. A strong answer shows the method changing a real decision, not just naming a framework.
I start from the promise rather than the backlog. There is usually one sentence somewhere — a customer commitment, a launch note — that says what this release is for, and I make sure I can state it before I look at tickets. Then I sort with a single test: what breaks in the user's day if this is not in the build. If their day breaks, it is a must. If it only makes their day nicer, it is a should. Anything below that gets cut on sight rather than debated, because debating the bottom of the list is where teams lose the week they needed. Two things never enter that sort. Quality is not a should — on our app that means the stability thresholds we ship against, and if a feature only fits by pushing the ANR rate past our ceiling, the feature is what moves. And nothing gets dropped silently: whatever comes out goes into the release notes with an owner and a target build. The last piece is staging. Most of what I cut is not gone, it is dark. The code ships behind a flag and we turn it on once the release settles. On a notifications rework I kept two of six notification types for the first build on exactly that test. Support asked for a third the week after, and because it was already written and flagged off, enabling it was a config change rather than a release.
This works because the method is stated as one usable test rather than a list of buckets, and because the closing example shows the test actually deciding something. It would downlevel if the quality floor were left implicit or if the deferred types had no route back into a build.
At my level the cut is not a list exercise, it is a conversation I have to run before the list exists. The first move is separating the commitment from the implementation. Someone has promised something to a customer or the field, so I go find the exact wording and get it restated as an outcome, because technicians can sign in with their own identity provider and the whole single-sign-on epic are very different scopes, and only one of them is negotiable. Then I make cost visible per item instead of arguing priority in the abstract. I ask each owner for two things: engineering days, and what it costs us to not have this on the date. Critical is not an accepted answer. In practice about a third of a release evaporates in that meeting without me having to cut anything myself. Two categories stay out of the trade entirely. The stability numbers we ship against, because a release that meets the date and spikes the ANR rate has not met anything. And anything irreversible — data migrations, anything touching billing — since those are the items you cannot stage safely. For staging we run flags per tenant, so a cut can be partial: live for the two customers who asked for it, off everywhere else until it is proven. On an identity migration that let us ship without automated claim mapping. We mapped the four largest tenants by hand, about three afternoons of one engineer's time, and built the self-serve version a train later.
The senior signal is that the method operates on commitments and other people's estimates rather than on a personal backlog, plus a named irreversibility rule and per-tenant staging. It would downlevel if the example were a feature-sized cut, or if the floor were asserted without saying what it costs to hold.
You are not expected to own a release triage yet. Show that you can split your own task into the part that satisfies the requirement and the part that is polish, and that you ask which of the two matters when time gets short rather than guessing.
Give a method you can apply to a feature and show it working once. The bar is a concrete sorting test in your own words plus evidence you raise the fit problem while there is still time to choose, not on the day the date arrives.
Talk at release scope and be explicit about what is outside the trade space. Interviewers listen for staging mechanics — flags, phased enablement — and for how the deferred list gets communicated outward rather than living in your head.
Describe the standing mechanism rather than your personal habit. The signal is a way of separating customer commitments from implementations that other teams can run without you, plus a floor that people stop re-litigating each planning cycle.
saying these in an interview costs you the question
- Naming a framework with no test for applying it to a real item
- Treating tests, monitoring or accessibility as cuttable scope
- Deciding alone, with neither product nor support in the room
- No example where the method actually changed a decision
- Deferring work into a backlog that nobody ever revisits
- Describing prioritisation in the abstract, with no date pressure in it
- What do you do when product says everything is a must?Do not answer with willpower. Describe how you make the cost visible — forcing a per-item statement of what breaks without it, or laying out two dated plans and asking which one they want to defend. Say that the decision is theirs to make, but with your numbers in front of them, and mention what you do when they still refuse to choose.
- Who else is in the room when you make that call?Name roles, not just product. Support or field teams usually know which items customers actually feel, and the people who will be on call for the release should have a voice in what stability the cut assumes. A method that only involves engineers reads as narrow at senior level.
- How do you keep the deferred work from disappearing?Give a specific mechanism rather than good intentions: an owner and a target release on each deferred item, the list going out to whoever was promised the feature, and a review at the next planning point. If some deferred items are genuinely never coming back, say you mark them as such deliberately instead of leaving them to rot.