Ambiguity Questions

Show that you make progress when the goal or the facts are unclear: find who knows, state your assumptions, take a small first step and adjust.

How It Works

Ambiguity questions ask what you do when nobody can tell you exactly what to build. "Tell me about a time the requirements were unclear" isn't asking whether you've ever been confused. It's asking what you did next. Some people freeze or wait to be told. Some guess and charge ahead. The interviewer is looking for the harder thing in between: you reduced the uncertainty enough to act, then kept adjusting as you learned more.

Interviewers care because most engineering work arrives half-specified. A ticket says "make the export faster" without saying for whom or by how much. The people they want to hire turn that kind of request into a plan without needing someone to write the plan for them.

Find the people and the data. Who asked, who's affected, and what the logs or numbers say. Asking good questions counts as action.
Make your assumptions explicit. Write down what you're assuming and share it, so others can correct it while that's still cheap.
Pick a reversible first step. A prototype, a spike, a feature flag or a small slice that teaches you something without locking you in.
Check in. Show what you learned to the people who care, and confirm the direction before you scale it up.
Adjust. Say what changed when new information arrived. That moment proves the process was real.

Pick a story where the uncertainty was real and you were the one who reduced it. The best ones include a point where you learned something that changed the plan. If every guess turned out right, the story sounds lucky. If a check-in changed your course, it sounds like judgment. Skip stories where the confusion came from your own lack of preparation, because those are failure stories.

Expectations scale with level. A mid-level engineer is expected to take a vague ticket, find out what it actually needs and deliver it without being chased. A senior engineer does the same for a project several people work on. At staff level, the unclear thing is often the problem itself: which of three possible projects the team should take on, or whether a problem is worth solving at all. Choose a story that fits the level you're interviewing for.

Tell it with STAR, and let the action include the questions you asked and the assumptions you checked. Expect follow-ups like "what would you have done if that assumption was wrong?"

What Interviewers Listen For

Whether you moved forward without waiting for someone to hand you a full spec.
Who you went to and what you looked at to reduce the uncertainty.
Assumptions you named out loud, and how you checked them.
A first step that was small or easy to undo, rather than a big bet.
What you changed when you learned something new.

How It's Asked

The same question comes in many wordings. Any of these wants the same kind of story.

Tell me about a time the requirements were unclear.
Describe a project where you had no clear direction.
Tell me about a time you had to make a decision without all the information.
Tell me about a project where the goal changed partway through.
How do you get started when you're handed a vague problem?
Tell me about a time you had to figure something out with very little guidance.
Describe a time you had to act before you had the full picture.

Sample Answers

The Question

Tell me about a time you had to work with unclear requirements.

Try drafting your own answer first, then compare. Both answers are invented.

Show Sample Answers

A Common Answer

Honestly, that happens all the time. At my last job product would hand us tickets that were super vague, like "improve the dashboard." So usually I'd take my best guess at what they meant and build it, and if they didn't like it we'd iterate.

One time I built a whole new filtering system for the reports page and it turned out they wanted something different, so we had to redo a lot of it. But I think that's just how it is at a startup. You have to be comfortable with ambiguity and move fast.

A Strong Answer

I was a backend engineer at a healthcare SaaS company that sells scheduling software to clinics. Our support lead filed a ticket that just said "the patient export is too slow, customers are complaining," and my manager gave it to me. There was no target, no list of affected customers, and the export had three code paths depending on the file format. My job was to work out what "fast enough" meant before I spent weeks speeding up the wrong thing.

I started with data instead of guesses. Two weeks of export logs showed most exports finished in seconds. The slow ones were nearly all CSV exports from clinics with more than 20,000 patients. Those took four to six minutes, and about a third of them hit our five-minute timeout. Then I read the actual complaints: eleven tickets in the past month, from six large clinics. Most weren't about speed at all. They were about the export failing and the user having to start over.

That changed the problem. I wrote a one-page note for my manager and the support lead that spelled out my assumptions: the goal is no failed exports for large clinics, not a faster average, and a background export that emails a link is acceptable. I asked them to correct anything wrong. The support lead pushed back on the email part. Some clinics export right before an audit and need the file in the same session. So I moved large CSV exports to a background job behind a feature flag, with an in-app progress bar and a download button, and turned it on for two of the six clinics. After five days with no failures, I turned it on for everyone. Then I added an index the large-clinic query was missing, which cut those exports to about 90 seconds.

In the next month we had no timed-out exports, and export tickets went from eleven to one, which was a feature request. Looking back, the hour I spent reading tickets mattered more than the code. The logs told me what was slow. Only the tickets told me what was actually hurting people, so now I read the complaints first.

Why It Works

The strong answer turns a vague request into a specific goal using the logs and the people closest to the problem. The weak answer guesses, then calls the rework "just how it is."
The candidate writes the assumptions down and invites correction, and the support lead's pushback visibly changes the design. That adjustment is what the question is about.
The first step is small and reversible: a feature flag, two clinics, five days of watching. The weak answer's first step was a whole filtering system.
The result is measured (timeouts to zero, eleven tickets to one), and the reflection is a specific habit rather than "I learned to embrace ambiguity."

Common Pitfalls

Telling a story where you waited. "I asked my manager and they told me what to do" shows you can follow directions, not that you can handle ambiguity.
Guessing, charging ahead, then calling the rework agility. Moving fast is fine. Moving fast without checking anything is the risk the interviewer is screening for.
Choosing a story where the ambiguity was your own doing, like a spec you didn't read. That's a failure story, and it will be heard as one.
Leaving out the moment you changed course. If every assumption was right, the story sounds lucky or tidied up.
Answering in general ("I'm very comfortable with ambiguity") instead of with one specific time.