Product work rarely arrives fully specified. A ticket says “add an approval step” or “make onboarding better,” and the details are left for someone to discover. When an interviewer asks about a time you worked with unclear requirements, they aren’t hoping to hear that everything was eventually written down perfectly. They want to see what you do in the gap: freeze and wait, guess silently and hope, or reduce the uncertainty in a sensible order while still making progress.
Three different kinds of ambiguity
It helps to separate the kinds of unknown, because each needs a different response, and saying which one you faced makes your answer sharper.
What to build. The goal itself is fuzzy: “make onboarding better,” “reduce support load.” The useful move is to find evidence about the problem: user interviews, support tickets, analytics, the person who raised the request.
How to build it. The goal is clear but the approach isn’t, usually for technical reasons: will this library handle the volume, can the legacy API do partial updates? The useful move is a spike or prototype with a time limit.
Who decides. The goal and approach depend on choices that different stakeholders see differently, and nobody owns the decision. The useful move is to find or establish one decider. Atlassian’s DACI framework is a common way to make that explicit: a Driver who gathers the information, one Approver who makes the call, Contributors who advise, and people who are kept Informed.
Many real situations mix all three, but there’s usually one that’s blocking.
Ranking unknowns by the cost of being wrong
Once you’ve listed the open questions, you can’t resolve them all at once. A simple way to order them is to ask two things about each assumption: how expensive is it if we’re wrong, and how cheap is it to check? Settle the expensive-and-cheap ones first. Proceed on the ones that are easy to change later, and write them down so they’re visible.
That ordering is worth describing in an interview, because it shows you made a judgment rather than either asking every question at once or none at all.
Worked example: an approval step nobody had defined
Here’s an illustrative scenario for an internal tool. Use it as a pattern; your own story will have its own details.
The ticket says: “Add an approval step for purchase requests over $5,000.” Nothing else. Reading it closely, you find at least five unknowns: who approves (line manager, finance, or both), whether approvals run in sequence or in parallel, what happens on rejection, what happens when an approver is on leave, and whether the threshold ever changes.
You rank them:
| Assumption | Cost if wrong | Cost to check |
|---|---|---|
| Who approves, and in what order | High: it shapes the data model | Low: one conversation |
| What happens on rejection | Medium | Low |
| Delegation when an approver is away | Medium | Medium: needs policy input |
| Threshold is fixed at $5,000 | Low if it’s configurable | Free: make it configurable |
A common weak answer (illustrative):
The requirements were really vague, so I just used my judgment, built what made sense to me, and adjusted it when people gave feedback after launch.
That’s guessing, then letting users find the mistakes. It may even have worked, but the interviewer can’t see any reasoning.
Stronger version (illustrative; use your own unknowns and decisions):
The ticket was one line: add approval for purchases over $5,000. I listed the open questions and ranked them by how much rework a wrong guess would cause. The approver model came out on top, because it decided the data model, so I tackled that first.
I sketched two flows on one page, manager-then-finance in sequence and both in parallel, and took them to a thirty-minute session with the finance lead and two engineering managers. It turned out they disagreed: the managers assumed they’d approve alone. Rather than referee, I asked who owned purchasing policy. It was the finance director, so I sent her the two flows with each group’s reasoning, and she chose sequential approval within a day.
While that was settling, I built the parts every option needed: the threshold as a config value, the audit log and the request form changes. Delegation went to a second phase with a documented manual workaround, which the finance director agreed to. We shipped in three weeks. The one change request after launch was a rejection-reason field, and the approval model didn’t need rework.
The candidate named the kind of ambiguity (who decides), ranked the unknowns, found the decider instead of picking a winner, kept working on safe parts, and made one deferral explicit.
Moving forward without guessing
Interviewers like to hear that the open questions didn’t stop you. There’s almost always work that’s safe whatever the answer: scaffolding, the pieces every option shares, test data, configuration. Doing that work while decisions are pending is good judgment, not impatience.
Two habits make this safe. Write down the assumptions you’re proceeding on, in the ticket or a short doc, so nobody is surprised later. And put a date on each open decision: “I need to know the approver model by Thursday to keep the three-week estimate.” A date turns a vague dependency into something a stakeholder can act on.
Mistakes interviewers notice
- Waiting passively for someone to clarify, then blaming the delay on unclear requirements.
- Guessing silently and presenting a finished feature built on assumptions nobody saw.
- Firing off forty questions at once instead of the three that matter.
- Calling a meeting for every unknown, including ones you could have settled with a config flag.
- Claiming to “thrive in ambiguity” without a story. The phrase has lost all meaning; the story is the evidence.
Follow-up questions to expect
“What if the finance director hadn’t answered?” A strong answer sets a default with a deadline: “I’d have told her I’d build sequential approval by Friday unless she preferred otherwise, since it’s the easiest to change later.”
“How did you decide what to build first?” Point back to the ranking.
“Which of your assumptions turned out wrong?” Have an honest one ready. In the example, perhaps nobody expected rejections to need a reason, which is why that became the first change request.
Interview practice: a one-line brief
Your manager says: “Can you improve the reliability of the notification service?” and nothing more. Describe your first week. (In a real interview, answer with a past example if you have a close one; this exercise builds the reasoning.)
Answer and reasoning
Start by working out which kind of ambiguity this is. The “what” is unclear: reliability could mean notifications that never arrive, arrive late, or arrive twice, and each points to different work.
So the first step is evidence. Look at the service’s error rates, queue delays and duplicate sends over the last month, and read recent support tickets that mention notifications. Then go back to the manager with a short summary: “Most complaints are about delays during the morning peak; dropped messages are rare. I’d like to target 95% of notifications delivered within thirty seconds. Does that match what you had in mind?” That turns a vague request into a measurable goal with an owner who has agreed to it.
While waiting for agreement, do the safe work: add the missing dashboards and alerts, since every option needs them. Then propose one small, testable change, such as scaling the worker pool at peak, and measure before committing to anything larger. A strong answer shows this order: clarify the goal with data, agree on a target, do the safe work in parallel and make the first change measurable.
Further reading on requirements and decisions
- Behavioral and HR interview questions
- Behavioral and HR multiple-choice questions
- Behavioral: Managing Scope Creep, for when the requirements keep growing after you start
- Behavioral: Working with a Difficult Stakeholder
- Atlassian Team Playbook: the DACI decision-making framework