Vague requirements are the norm, not the exception. The interviewer wants to see you drive clarity rather than either (a) freezing until someone hands you a perfect spec or (b) guessing and building the wrong thing.

The approach

1. Find the problem behind the request. "Add a dashboard" isn't a requirement — "managers can't tell which projects are at risk" is. Ask "what problem does this solve?" and "who's the user?"
2. Ask sharp clarifying questions. Not "what do you want?" but specific ones: "What's the #1 thing this view must answer? What's the expected data volume? Is real-time needed or is a refresh fine?"
3. Restate and confirm. "Here's what I understood — you need X so that Y. Right?" This catches misalignment in minutes instead of weeks.
4. Make assumptions explicit. Where you can't get an answer, write the assumption down and proceed — "I'm assuming desktop-first; flag me if mobile is priority."
5. De-risk with something concrete. A wireframe, a clickable prototype, or a thin vertical slice. People are vague in the abstract but precise when reacting to something real.
6. Ship iteratively. Small increments let reality correct the spec fast.

STAR example

Situation: A PM asked for "better analytics on the project page." No mockups, no metrics defined. Task: Turn a vague ask into something shippable and actually useful. Action: I asked who'd use it and what decision it should support — turned out team leads wanted to spot stalled projects. I restated that as a concrete goal, listed 3 candidate metrics, and built a rough wireframe. Reviewing the wireframe, the PM immediately cut two metrics and added one I hadn't considered. I shipped a v1 of just that behind a flag. Result: v1 landed in a week and was close enough that v2 only needed minor tweaks. The wireframe conversation saved us from building the analytics-heavy version nobody wanted.

What interviewers want to hear

• You don't start coding on a vague spec.
• You dig for the underlying problem and the user.
• You make assumptions visible rather than hiding guesses.
• You use artifacts (wireframes, prototypes, slices) to extract precise feedback.
• You're comfortable being the one who creates clarity.

Senior framing

Juniors wait for requirements; seniors manufacture them. The senior signal is treating ambiguity as a normal input you process — ask, restate, assume explicitly, prototype, iterate — and knowing that a cheap concrete artifact extracts better requirements than any amount of up-front questioning.