Tell me about a time you dealt with ambiguity: how to answer

Most answers to this question start the same way. The requirements were unclear, so you set up meetings with the stakeholders, got clarity, and then built the thing.

Interviewers hear that answer a lot, and it tells them very little. An interviewer who asks this often calls “I talked to stakeholders to get clarity” a cookie-cutter answer. The meetings aren't the problem. What's missing is what you did while things were still unclear.

A strong answer names three things: the question you couldn't answer at the start, the assumption you made so you could move, and how you tested it. This guide shows how to find those in your own story.

What counts as ambiguity at work

Many candidates aren't sure what the word means here, and some distrust it. In job ads, “comfort with ambiguity” can read as a warning that the scope of the job will keep changing, as one r/recruitinghell thread puts it bluntly.

In an interview it means acting without the information you'd like, and without anyone setting out the steps. An engineering interviewer tests it with an ill-defined problem, watching whether candidates find the need, plan and design a way through. Google's 2019 How We Hire video named it a hiring trait, though its current hiring pages don't use the phrase.

Everyday situations count: a ticket with no acceptance criteria, “find out why sign-ups dropped”, a brief that says “make onboarding better”, a decision due before the data arrives. If you're early in your career, a group project with a vague brief or a new job with no handover can work.

If nothing comes to mind, ask yourself when you last started something before you were sure it was right. Most people have several: the first draft sent with open questions, the estimate given before the details were known. Those are ambiguity stories, even if nobody called them that.

The expected scale grows with seniority. A reply in the same thread notes that the more senior you are, the more ambiguity you're expected to handle.

Match the story to the level you're applying for. Whatever its size, it tends to go wrong in the same place.

Why asking for clarity isn't the whole answer

Asking questions is a good first step. The trouble starts when the story stops there, as if the ambiguity disappeared once someone replied.

Often it doesn't. The same project management interviewer explains that asking around can make things more ambiguous. A reply in that thread suggests the opposite habit: draft a plan from your assumptions, then share it so people can correct it.

That's the behavior interviewers want to hear about. You made a reasonable guess, said it out loud and checked it quickly. A product interviewer listens for risk reduced through prototypes, small releases with clear goals, and learning fast.

Sometimes the person who asked can't answer either. Then go to the people closest to the work. An analyst on r/BusinessIntelligence suggests talking to the requester's own staff, building a rough prototype in whatever tool is quickest, and letting the feedback shape the next version. Each step is a test of a guess.

Clarifying questions still count when they're specific, especially for analysts. Asking which metric, over what period and how it's defined isn't stalling, as an analyst on r/analytics points out. The difference is that you name those questions in your answer, which is where the structure starts.

How to tell it

Interviewers use these questions to see how you make decisions in general. A manager on r/managers asks about deciding without enough information because it shows a candidate's whole process. So the answer should make your reasoning easy to follow.

It follows the STAR order, with the unknown at the start and the test in the middle.

The question you couldn't answer. “It was unclear” isn't enough. Say exactly what: who the report was for, whether the system would hold the load, which customers the feature was meant to serve. If the decision couldn't wait, say why.

What you assumed so you could start. Say why it was a reasonable guess, and whether it was easy to undo. Amazon's leadership principles note that many decisions are reversible and don't need extensive study. Saying your choice could be reversed shows you weighed the risk.

How you tested it, and what you found. A prototype, a draft sent to the requester, a small release, a quick query. Include what you got wrong. A former Amazon product leader asks what you learned regardless of whether the call was right.

One follow-up worth practicing out loud is “What did you have to assume in order to get started?” Kora asks follow-ups like that: you pick your role, answer behavioral questions out loud, get a follow-up when your answer leaves out an important detail, and get feedback after each answer.

Go back to the answer from the start of this page. “The requirements were unclear” becomes “nobody could tell me whether the export was for finance or for customers, so I assumed finance, built one sample, and sent it to both on day two.”

The meetings are still there, but now they test something. The examples below show the same shift in six roles.

Example answers

Hypothetical product cases and past-behavior questions

Searching for ambiguity interview questions brings up two different formats. A widely upvoted post, from a hiring manager on r/ProductManagement, is about hypothetical product cases: a made-up scenario, such as your CEO deciding to take on a competitor, with almost nothing else to go on.

In that format, the advice is to slow down, ask questions before proposing anything, and work toward a small first version. It's a product-sense exercise, scored on how you reason in the room, and this guide doesn't cover it.

Questions that start with “Tell me about a time” are past-behavior questions and need a real story. Those stories tend to go wrong in a few predictable ways.

What makes the answer go wrong

Most weak answers skip the time when things were still unclear. These are the common versions:

• Clarity as the whole story. You asked, someone answered, and the work began. Nothing shows what you did before the answer arrived.
• Waiting for a full plan. The same project management interviewer says a candidate who needs everything planned and organized is likely to feel overwhelmed when the answers only add to the ambiguity.
• Working it out alone. A product manager who interviews engineers wants someone who will work out an unclear initiative together with product, not someone who expects product to settle everything first.
• A path that's too tidy. A neat line from vague brief to perfect result sounds rehearsed. A reply on r/UXDesign says the messy middle is what makes a story interesting.

Other ways it gets asked

The same story usually fits several wordings, with a change in what you lead with.

“Tell me about a decision you made without all the information you wanted.” Lead with what was missing and why the decision couldn't wait. The product manager and consultant examples above answer this one.

“Tell me about a time the requirements changed after you'd started” or “…adapting to a major change.” The change becomes the question you couldn't answer. Say what happened to work already done, what you kept and threw away, and who agreed to the new scope.

“How comfortable are you with ambiguity?” or “How do you handle ambiguity?” Answer in a sentence, then give the story: “Fairly comfortable, as long as I can test my guesses early. On my last project…”

“How do you deal with changing priorities?” If the work stayed clear but there was more of it, or its order kept shifting, that's a prioritization question. There the answer turns on what you dropped and who you told, not on what you assumed.