In this article
Before you start
This page is one answer in the behavioral interview guide; the general method for any story question is in how to answer interview questions.
Why interviewers ask this
Candidates report this question in several wordings: a project with unclear or shifting requirements, a pivot you did not control, taking something from ambiguous to shipped, and what you kept, cut or renegotiated when requirements changed late. Interviewers use it because real work rarely arrives fully specified, so the story shows how you behave without a script.
A weak answer says "I stay flexible and communicate a lot" and names no decision. A strong answer shows a specific unclear goal, the questions you asked, the assumptions you wrote down, and a trade-off you made with other people. A Staff-level answer adds what you changed afterwards so the next change cost less. Treat that as advice on what a strong answer shows, not as a published scoring rule: no public source describes how any company scores it.
Ambiguity and changing requirements from first principles
- Ambiguity
- Ambiguity is a situation in which the goal, scope or constraints of a task are unclear enough that two reasonable people would build different things, so the work cannot be done well without questions or stated assumptions.
- Changing requirement
- A changing requirement is a statement of what the work must do that is added, removed or altered after work began, so the plan that fitted the old statement may no longer fit the new one.
- Scope trade-off
- A scope trade-off is an agreed decision to keep, cut, reduce or delay parts of the work, or to move a date, when new demands exceed the capacity left.
In plain words
Imagine a friend asks you to cook something light for dinner. You do not know allergies, time or taste. You could guess, or you could ask two questions and then cook. Then, halfway through, the friend adds a guest. You now decide what to drop. The analogy breaks in one place: at work, other people share the decision and the cost.
In one precise sentence: handling ambiguity is reducing what is unknown through questions, written assumptions and early delivery, and handling change is deciding openly what the new demand displaces.
The idea is not new. The authors of the Agile Manifesto wrote the principle "Welcome changing requirements, even late in development", and the same principles, republished by the Agile Alliance, pair it with delivering working software frequently, from a couple of weeks to a couple of months. Change is expected, so the skill being tested is managing its cost.
Step 1: Separate what you know from what you do not
Sort what is known from what is unknown. Write two lists before you build anything: facts you were given, and questions nobody has answered. This sorts the problem into parts you can start on and parts that need a person. Input: a vague brief. Output: a short list of open questions, ranked by how much each would change what you build.
Many candidates skip this and either wait for clarity or guess. Neither is a plan. Waiting delays everything, and guessing risks building the wrong thing. The ranking matters because an unanswered question that would change the whole design deserves a conversation today, while a small detail can wait. You now have a map of the fog, which the next step starts to clear.
Step 2: Ask, then state your assumptions in writing
Ask the people who own the goal your top questions, and ask for the reason behind the request, not only the request. When no one can answer, write each gap as an assumption ("I assume the first users are internal") and send it to the owner for a quick yes or no. Input: your open questions. Output: answers, or written assumptions someone has seen. While you wait, start the work that does not depend on the open questions, so productivity does not stall.
This protects you. If an assumption proves wrong, the record shows it was visible and cheap to correct. Teams using Scrum, a framework that organizes work in short cycles, build this into their process: the Scrum Guide describes the product backlog as "an emergent, ordered list of what is needed to improve the product", refined as the team learns. A product backlog is the single list of work a Scrum team draws from, and refinement makes its vague items smaller and more precise over time.
Step 3: Decide what to keep, cut or renegotiate
When a requirement changes, size it first, compare it with the capacity you have left, and only then choose. The three moves are: cut something of lower value, reduce the scope of items, or move the date (or add people, though adding people late usually costs onboarding time first). Input: the new item and the capacity gap. Output: a choice agreed with the owner and communicated to everyone it affects.
The Scrum Guide says the Developers size the work, and the Product Owner, the person responsible for the value of the work, "may influence the Developers by helping them understand and select trade-offs", so the choice is shared. Naming who you made the trade-off with is exactly what an interviewer wants to hear. This is the step the follow-up question targets.
Step 4: Ship something small and check early
Deliver the smallest piece that tests your riskiest assumption, then adjust. Input: the decision and the assumptions behind it. Output: working evidence, such as a demo, a prototype or a first release, that either confirms the assumption or exposes the error while it is still cheap.
The Manifesto's authors put this first: their highest priority is "to satisfy the customer through early and continuous delivery of valuable software". A small working release is also the cheapest way to find out whether an assumption was wrong. Close the loop by telling stakeholders what changed and why. You now have the full method: map, ask, trade, ship. Candidates who describe all four, with one real decision inside them, give a complete answer.
Step-by-step description
- Two lists: facts and open questions.
- Written assumptions someone has seen.
- Size the change, then choose.
- Test the riskiest assumption early.
- Sort what is known from what is unknown.
- Ask questions, then state assumptions in writing.
- Decide what to keep, cut or renegotiate.
- Ship something small and check early.
A worked scenario: the week-four change
The numbers here are invented to show the arithmetic; they are illustrative, not data from any real team.1 A team of two people has six weeks. Working days are 6 weeks × 5 days × 2 people, which is 60 person-days, and after 20% for meetings and fixes, 48 are usable.1 Five tasks, A to E, total 40 person-days, so the plan holds 8 days of slack.1
By the end of week three, 24 usable days are spent. Tasks A and B (22 days) are done and C has 2 days of progress, so 16 days of work remain against 24 days of capacity.1 In week four a new requirement, F, arrives and needs 14 days. The remaining work becomes 30 days against 24, a gap of 6.1
| Option | Days freed | Value lost (illustrative points) | Closes the gap? |
|---|---|---|---|
| Cut task D | 6 | 4 | Yes |
| Cut the rest of task C | 6 | 5 | Yes |
| Cut task E | 4 | 2 | No |
| Move the date | 6 (3.75 working days at 1.6 usable person-days a day) | 0 | Yes |
The lowest-value cut that closes the gap is task D.1 In an interview you would not recite a table; you would say: "It did not fit, so I showed the gap and offered options." That sentence is the evidence of judgment.
Text description of the diagram
- Remaining work before the change is 16 person-days.
- Remaining capacity is 24 person-days.
- After the 14-day change the remaining work is 30 person-days, a gap of 6.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
Tell me about a project where the requirements were unclear or kept changing. How did you adapt?
The brief was one line: improve onboarding. I wrote down what I knew and what I did not, then asked the owner who the user was, what success meant and when it was due. Where nobody knew, I wrote my assumptions down and sent them for a yes or no. I built the smallest slice that tested the riskiest one. Midway, a new requirement arrived. I sized it, showed it did not fit, and offered three options: cut a lower-value item, move the date, or shrink two items. We cut one, I told affected teams that day, and we shipped the core on time. Afterwards I added a weekly requirements check so changes surface earlier.
What makes it Staff-level: it names a decision, shows the cost of the change before accepting it, involves the owner in the trade-off, and ends with a change to how the team works. Say it in about a minute: situation in one sentence, the questions and assumptions, the trade-off, the result, the lesson.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Handling the unknown | "I waited for clarity" or "I guessed" | Asks targeted questions; writes assumptions down | Ranks unknowns by impact and tests the riskiest first |
| Handling change | "I just worked harder" | Sizes the change; compares with capacity | Shows the gap and offers options with costs |
| Trade-offs | No cut named | Names what was cut and why | Agrees the cut with the owner; tells affected people |
| Communication | "I kept everyone updated" | Gives a specific update and its audience | Sets a recurring check that surfaces change earlier |
| Result and learning | Vague outcome | Concrete outcome and one lesson | Outcome plus a durable process change |
Three variants of this question
Tell me about a time you had to pivot unexpectedly.
Use the same four steps, but spend the most time on Step 3: what changed outside your control, what you decided to stop, and how you kept the team moving. Acknowledge the setback in one sentence, then move to your action.
Tell me about a time you took something from ambiguous to shipped.
Emphasize Steps 1, 2 and 4: how you mapped the unknowns, the assumptions you tested, and the smallest release that proved the direction. End with what shipped and what you learned.
Tell me about a time requirements changed late; how did you decide what to keep, cut or renegotiate?
Lead with the capacity gap and the options you offered, then the choice and who agreed to it. This is the follow-up in the lead, so have the cut and its reason ready.
Common mistakes
- "I just stayed flexible and adapted." (wrong) It names no decision. (right) "I sized the change, showed it did not fit, and we agreed to cut one item."
- "I waited until the requirements were final." (wrong) Waiting shows no initiative. (right) "I wrote my assumptions down and started the part that did not depend on them."
- "I said yes to every change." (wrong) Accepting without a cost hides the trade-off. (right) "I accepted it and showed what it displaced."
- "The requirements changed because the planning was bad." (wrong) The Agile principle treats late change as something to use, so blame sounds defensive. (right) "The need changed, so I reordered the work and told the team why."
- "Everyone was happy." (wrong) It has no evidence. (right) "The core shipped on time and the cut item moved to the next cycle."
Follow-up questions
How do you answer the 'How do you handle ambiguity?' interview question?
Give the four-step approach in one sentence: map the unknowns, ask and write assumptions, agree the trade-off, and ship small. Then anchor it in one real example, naming the decision you made, and end with what you changed afterwards so the next change cost less. If the prompt itself is vague, spend one sentence saying what you would clarify first. The decision making questions page covers the sibling skill of choosing under uncertainty.
How do you handle disagreements and ambiguity together?
Ambiguity often produces disagreement, because people fill the gaps with different assumptions. Make the competing assumptions explicit, agree a quick test or a decision owner, and then commit. The interpersonal communication page covers how to describe that working style.
What if the new requirement is bigger than the whole remaining plan?
Say so early and show the numbers: the remaining capacity, the size of the change, and the options (cut, delay, or restart the plan). A change that cannot fit is a decision for the owner, not something to absorb quietly.
What do you do when nobody can answer your questions?
Write the assumption, name who could correct it, and build the smallest piece that tests it. If you need support from people outside your team, the story in influencing without authority shows how to get it.
How do you stop requirements from changing so much next time?
You cannot stop them, and the Agile principles treat changing requirements as something to welcome, not prevent; you can make change cheaper through short delivery cycles, early demos and a regular check on priorities. In the interview, ask about this too: see questions to ask the interviewer.
Which company values does this map to?
Some companies publish principles that touch ambiguity, such as ownership and bias for action in the Amazon Leadership Principles. Candidates report the question across many companies, and common interview questions shows where it sits among the others.
- Handle ambiguity with questions, written assumptions and a small early release.
- Handle change by sizing it, comparing it with capacity, then choosing what to keep, cut or renegotiate.
- Name the decision and the people who agreed to it; "I stayed flexible" proves nothing.
- Agile treats late change as expected, so show how you managed its cost.
- End with one lasting change in how you work.
Sources
- Principles behind the Agile Manifesto — agilemanifesto.org (the Manifesto's authors), 11 Feb 2001
- The 2020 Scrum Guide — scrumguides.org (Schwaber and Sutherland), 18 Nov 2020
- 12 Principles behind the Agile Manifesto — Agile Alliance, accessed 2026-10-26, 26 Oct 2026
