Working With Ambiguity / Unclear Requirements

Senior engineers don’t wait for clarity — they create it. Interviewers ask this to see if you’ll be productive without hand-holding, or get stuck waiting for a perfectly-spec’d ticket.

What they’re really asking

• Do you start moving when the path isn’t clear, or get stuck?
• How do you make decisions without all the info?
• Do you communicate up about ambiguity, or silently make assumptions and ship?
• Can you balance “ship now” with “ship right”?
• Do you check back to validate your assumptions?

The strong answer pattern

Situation: specific project where the goal was clear but the path / scope / requirements weren’t.

What was ambiguous: be specific. “Requirements weren’t clear” is too vague. “We knew we needed to migrate to event-driven, but no one had decided which broker, which events, or how to handle backfill.”

How you navigated it:

1. What you did to reduce ambiguity (asked who, read what, prototyped what).
2. What you decided unilaterally vs what you escalated.
3. How you communicated assumptions to stakeholders.
4. How you got course corrections.

Result: outcome. Did the project succeed? What did you learn about working with ambiguity?

Example template

Situation: I joined a team in Q1 2023 to lead the “personalized recommendations” feature. The brief: “users see more relevant content.” That was all. No success metric, no scope, no timeline.

What was ambiguous:

• What does “relevant” mean? Click-through rate? Time spent? Some product judgment?
• What’s the data we recommend over — articles? Videos? Both?
• What’s the budget — can we use an external API or do we build in-house?
• What’s “done” — A/B test live? Rolled out 100%? Beating baseline by some %?

What I did:

1. Wrote up a one-page “what I think we’re building” doc with my best guesses for each ambiguity, and pinged the PM + manager. Took ~2 hours.
2. Booked a 30-min sync with the PM to walk through it. Got clarity on success metric (CTR) and scope (articles only for v1) — half the ambiguities resolved.
3. Made a decision on what I’d build first: a simple collaborative-filtering baseline using existing infra. No external API needed; we could replace it later if results were promising. Documented this as a decision, not a question.
4. Set a 2-week checkpoint with the PM: “let’s review what we’ve shipped and decide what’s next.” Bought myself time to start without locking in big decisions.

What I escalated: the budget question went up to engineering manager. That needed a decision I didn’t own. Got a yes for $X/month for an external API as a fallback if collaborative filtering didn’t beat baseline.

What I decided myself: algorithm, data, schema, A/B test framework, success threshold (5% CTR improvement). Documented as assumptions in the design doc.

Result: Shipped v1 in 5 weeks. CTR improved by 8% in the A/B test. The 2-week checkpoint became a recurring cadence — we adjusted scope twice based on early signals. The PM later told me the “best guesses doc” was the single most useful artifact in the project; it forced them to clarify things they hadn’t thought about.

Lesson: Ambiguity at the start often means the stakeholder hasn’t thought it through either. A “here’s what I think you mean” doc surfaces the unanswered questions in a low-stakes way and often gets faster decisions than “let’s have a meeting to scope this.”

What this answer signals

• You made progress in 2 hours — wrote the doc. Didn’t wait a week for clarity.
• You distinguished what to escalate vs decide. Budget = escalate. Algorithm = decide.
• You documented assumptions rather than silently committing to them.
• You bought yourself a checkpoint. “Let’s review at 2 weeks” is a senior move.
• Result is specific — 5 weeks, 8% CTR, two scope adjustments. Not just “it shipped.”
• Lesson is generalizable — the “what I think you mean” doc pattern.

Anti-patterns

“I waited for clarity”

“I asked the PM to clarify the requirements before I started.” Then nothing happens until the meeting next Wednesday.

Senior engineers don’t wait. Start moving with assumptions; validate as you go.

“I just built what made sense to me”

No communication, no documented assumptions, no check-ins. Project ships looking nothing like what the stakeholder wanted; you blame “unclear requirements.”

This is the opposite failure mode. Moving without communicating is just as bad as waiting without acting.

“I escalated everything”

Every decision goes up to your manager. You become a bottleneck for them and lose the trust that comes with making good calls yourself.

Senior engineers escalate the right things (budget, scope, cross-team dependencies) and decide the rest (algorithm, architecture, what to ship first).

“I did a long discovery phase”

3 weeks of research before writing any code. By the time you start, the timeline is tight, the stakeholder’s lost patience, and your understanding might be obsolete.

Better: 1-2 hours of structured guessing, then start building.

Patterns for navigating ambiguity

Write the “what I think this is” doc

A page or two of:

• “I believe the goal is X.”
• “I believe success looks like Y.”
• “I believe the scope is A, not B.”
• “I believe we have N weeks.”
• “I’m going to assume Z unless told otherwise.”

Send it to stakeholders. They’ll correct the parts they care about. Now you have buy-in on the rest.

Time-box the discovery

“I’ll spend 2 days on prototyping; check in Friday.” Forces a decision instead of open-ended research.

Build the smallest credible thing

Pick the simplest scope that delivers the goal. Ship it. Iterate. The shipped thing surfaces requirements you couldn’t have known about up front.

Schedule check-ins explicitly

“Let’s sync at the 25%, 50%, 75% marks.” Pre-commit to course-correction opportunities.

Decide → document → ask forgiveness if needed

For decisions in your scope: make the call, document it in a design doc / PR description / Slack message, move on. Easier to ask “should we change?” than “what should we do?”

Variations

“How do you handle requirements that change mid-project?” Adjacent topic. Talk about: tight feedback loops, small batches, explicit change-request triage, recommending what to drop when scope grows.

“How do you handle work without clear acceptance criteria?” Same skills. Define your own; share for review. “I’ll consider this done when X, Y, Z.”

“How do you deal with a vague product manager?” Same skills, plus the relationship layer. Help them think — write the strawman; ask the questions that force prioritization; reflect back what you heard.

A bad answer

“I just made my best guesses and shipped it. The PM was happy with what we delivered.”

Why it fails: no process, no transparency, no demonstration of how you’d handle ambiguity in a different context. Could be luck.

A great answer is meta

The interviewer should hear not just “this happened in 2023” but “and here’s the pattern I’d apply next time.” Generalize the lesson; show you’ve internalized it.

Reflective practice

List 3-5 ambiguous projects from your career:

1. New role / new domain — what did you not know?
2. Feature with vague scope — what did you decide?
3. Decision under time pressure — what did you cut?
4. Project with conflicting stakeholders — how did you align?

For each, draft a STAR. Identify the pattern you used.

Interview angle

This question separates engineers who “execute well” from engineers who “create clarity.” Senior roles need the latter. Show that you don’t need someone else to define your work — you can define it, validate it, and adjust as new info arrives.

The phrase “I made the best call I could with what I knew, documented my assumptions, and built in a checkpoint to revisit” is the senior-level answer in three sentences.