Tell me about a time the requirements changed after you had already built a big part of the work.
answer
- where the work stood when it landed
- the change, stated without blame
- salvage versus discard, out loud
- one trade asked for, not absorbed
- what shipped, plus the cheaper next pivot
basics
~20 sTests whether a change of goal produces resentment or re-planning. Name what changed and what you had already built, show how you triaged salvage versus discard, renegotiated scope openly, and shipped something smaller on purpose.
how to answer
5 beats- where the work stood when the change arrivedTwo or three sentences: the goal, your role, and how much was actually built. Keep this and the next beat to roughly a fifth of your airtime — a long defence of the original plan reads as defensiveness.
- the change itself, described without blameState what changed and why it was legitimate, even if it was inconvenient. Give the requester a real reason — a regulator, a client decision, a vendor switch, new usage data. The interviewer is listening for whether you can hold the other side as reasonable.
- what you salvaged, cut, and renegotiatedThis is the bulk of the answer, around sixty percent. Walk the triage out loud: what died, what survived, what it cost, and the trade you proposed rather than absorbed. Name who accepted the trade and how fast.
- what shipped, with a numberClose the loop in two sentences with something checkable: what went out, on which date, and one quality or usage measure. If the date moved, say so and say who agreed to move it — an outcome you hide is one the interviewer assumes was bad.
- what you changed so the next change cost lessOne sentence of reflection with a structural answer: a seam, a thinner slice, an assumption you now write down. Say whether you have used it since. Avoid promising to communicate better, which is not a change anyone can see.
your answer
5 story prompts- Pick a project where the goal changed after you had already built or shipped something real.
- Write down what you salvaged and what you discarded, with rough effort against each.
- Find one number: what shipped, what slipped, or a quality measure after the pivot.
- Choose an example where you asked for a trade, not one where you silently absorbed it.
- This can be your missed-deadline story re-angled, if the date moved because scope changed.
draft and rehearse your own answer in a learn session
go deeper
This probes adaptability and ownership under change: whether a moved goal produces resentment or re-planning. Interviewers listen for whether you treat scope as negotiable and dates as consequences, whether you can separate what is genuinely dead from what still stands, and whether anything shipped. A strong answer shows you converted a change into a costed decision someone else could make.
I was the most junior of five people at a digital agency building a booking flow for a travel client. Three weeks into a six-week build I had the saved-card screens working end to end when the client's legal reviewers came back and said cards could not be stored at all, and that a consent step had to sit ahead of payment. My first move was not to start rewriting. I spent an afternoon listing what actually died with the change — the card vault screens and their two format tests — and what survived, which was the form validation, the step navigation and all the error states. That list turned out to be the useful thing. It let my lead tell the client that about a third of my week was recoverable rather than the whole of it. Then I asked for one trade instead of quietly absorbing the work. I proposed dropping the card-scanning nicety we had planned so the consent step could take its slot, and the client agreed on the same call. The flow went out on the original day with consent in it, and session crash rate on the new step held at 0.4% over the first fortnight, under the 1% the client had written into acceptance. Since then I keep a running note of which parts of a build are throwaway if the shape changes.
The signal is the triage: this answer names what died, what survived, and turns that into information someone else could act on. Asking for one trade instead of silently absorbing the work is what lifts it above compliance. Cutting the salvage list, or stopping before the shipped result, would downlevel it.
On an agency team I led the front end for a retailer's mobile catalogue — four engineers plus me. Halfway through the engagement the client swapped the content system underneath us, so the shape of every product payload changed, and they asked for a store-availability badge nobody had scoped. I did two things before touching code. I priced it honestly: eleven days of adapter work plus the badge, against nine days left in the window. Then I brought them a menu rather than a problem — give up the animated filter drawer, which had eaten more effort than anything else, in exchange for the badge and the migration, with the drawer parked behind a toggle instead of deleted. They took that trade in about twenty minutes, mostly because the cost was on one page. The rest of my effort went into making the pivot cheap. I put an adapter between the payload and our components so the shape change touched one module rather than nine, and we moved to a release every second day so the client watched the catalogue fill in instead of trusting a date. Nine of the twelve screens landed on the agreed day and the last three a week later, agreed in advance. Session crash rate across launch week sat at 0.7%, against 2.8% on the previous build we had done for them. I have used that adapter seam on every catalogue project since.
What makes this middle-level is the pricing and the menu: a change becomes a costed trade the client can decide in one sitting, and the code is reshaped so the next shape change is contained. Losing the adapter seam, or the before-and-after quality number, would pull it back toward a task-level telling.
Own-task scope is fine. Show that you raised the impact early instead of quietly rebuilding for a week, and describe one concrete trade or salvage decision inside your own piece of the work.
Work at feature scope and show the mechanics: how you priced the change in days, what you offered to drop in exchange, and how you kept the remaining work in slices that could ship independently.
Team and delivery scope. Show that you protected a release, decided which parts of the design stayed cheap to undo, and changed the cadence or the seams so the next change touched one place instead of nine.
Org scope and a repeatable mechanism: how commitments are framed so change is expected, how scope changes get priced and decided across teams, and what evidence told you the mechanism worked.
saying these in an interview costs you the question
- Blaming the requester instead of describing your own response
- Absorbing the whole change with unpaid overtime and calling that ownership
- Relitigating why the original plan was the right one
- Vague about what was actually discarded and what survived
- The story ends at we replanned, with no shipped outcome
- Treating every requirement change as evidence of incompetence upstream
- What exactly did you have to throw away, and how did you decide?Answer with a short inventory rather than a feeling: name the pieces that died, roughly what they cost, and the rule you used to sort them. Salvage is usually tests, validation, state handling and domain knowledge, even when the surface changes. Show that you made the list before you started rewriting, because that list is what let someone else make an informed call.
- How did the person who asked for the change react to your proposal?Describe their reaction honestly, including the parts that did not go your way. The signal is whether you brought them a costed menu they could decide on, or a complaint. If they refused the trade, say what you did next: escalate, cut quality-neutral work, or accept the date change explicitly. Avoid painting them as unreasonable.
- Did the date move, and who decided that?Be direct. Either the date held because scope came out, or it moved because the change was bigger than the slack, and someone with the authority to move it agreed. What sinks answers here is an implied third option where nothing came out and nothing moved, because that quietly means quality or someone weekends paid for it.
- What would you do differently if the same change landed again?Give one specific structural answer, not a promise to communicate more. Good material: a seam you would put in earlier, a decision you would leave unmade for another week, a thinner first slice, or an assumption you would have written down and confirmed. Keep it to one item and say whether you have actually done it since.
### What the prompt is really measuring This family has one purpose: to find out what happens to you when the target moves. Almost everyone can describe a project that changed. The separation happens on three axes. First, blame — does the story spend its energy on who changed their mind, or on what you did next. Second, negotiation — did the change get priced and traded, or silently absorbed. Third, structure — did the change reveal that your work was arranged so a pivot was cheap, or so a pivot was catastrophic. ### Common wordings You will hear this as: tell me about a time requirements changed mid-project; a time the goalposts moved; a time you had to change direction after significant work; a time your project was re-scoped; how do you feel when work you have done gets thrown away. They are the same prompt and the same story answers all of them. Interviewers occasionally add a constraint — after you had already shipped, or with a fixed date — which just moves the emphasis toward the trade you negotiated. ### Weak versus strong, in one contrast The weak version: we were building X, then the client changed their mind, so we had to redo a lot of it, it was frustrating but we got there in the end. Nothing is measurable, no decision is visible, and the only characterisation is of somebody else. The strong version keeps the same facts and adds three things. A boundary — here is what was already built and here is what actually died. A decision — here is the trade I proposed and who accepted it. An outcome with a number — here is what shipped, on what date, at what quality. The best versions add a fourth: here is the seam I put in so the next change was contained, and here is the evidence that it was. ### Evidence types that land Strongest to weakest: a shipped result with a date and a quality number; a costed trade someone else agreed to in writing; a salvage inventory with effort attached; a structural change you can point at afterwards; and, weakest but still useful, a clear description of how you kept teammates unblocked while the plan was in flux. Feelings are allowed and even help, but only as one clause, and only if the resolution is behavioural. ### How the bar moves with level At the earliest level, the interviewer is checking for the absence of sulking and the presence of early signalling — did you say something on day one of the change rather than day five. In the middle, they want the negotiation mechanics: the estimate you produced, the menu you offered, the slices you kept shippable. At senior, the interesting part is what you did to the shape of the work — feature toggles, adapters, contracts, release cadence — plus the release you protected. At the top level, they want the mechanism: how your organisation prices change so that pivots arrive as decisions with costs attached, and what changed in how teams commit. ### The airtime trap The most common structural failure is spending ninety seconds on why the original plan was reasonable. That reads as defensiveness even when it is not. Compress the setup to two or three sentences, spend the bulk on what you did once the change landed, and always finish with the outcome and one sentence of reflection.