Tell me about a time you were handed a requirement too vague to build from.
answer
- name the ask and what was missing
- the questions that changed the scope
- assumptions written down and confirmed
- a cheap check before full build
- agreed done, then the result
basics
~20 sProbes whether you turn a vague ask into a buildable scope instead of guessing or stalling. Answer with the questions you asked, the assumptions you wrote down, and the definition of done you agreed before writing code.
how to answer
6 beats- the ask, in the words you were givenOpen by quoting the request as literally as you can, then say in one sentence what was missing from it. Keep this and the next beat to roughly fifteen to twenty percent of your airtime; the setup is not the story.
- what you were on the hook forState your own role and what you would be judged on, so the interviewer knows whose decision each later action was. Be honest about scope: one ticket is a legitimate answer at any level.
- the questions you asked and who you askedGive one or two actual questions and say what the answers changed about the design. Mention that you batched them into a short conversation rather than sending them one at a time over a week.
- the assumptions you wrote down and sharedName the artefact: a ticket comment, a one-page note, a message the requester replied to. The signal is that your interpretation left your head in a form someone could correct, and ideally that someone did correct a line of it.
- the cheap check before the full buildDescribe the spike, throwaway prototype, or data pull you used to test the riskiest assumption, how long you gave it, and what it told you. This beat plus the previous one should carry the bulk of your airtime, around sixty percent.
- agreed done, the result, and what stuckSay what done meant in the sentence you both accepted, then land one concrete outcome with a number if you have one. Close with the practice you kept, in a single line, using the last quarter of your airtime.
your answer
5 story prompts- Pick a one-line ask you personally received, ideally within the last eighteen months.
- Write the three questions whose answers changed the scope most, and who answered each.
- Find the artefact you produced before coding: a ticket comment, a note, a prototype.
- Name one number from the outcome and check you could defend it under a follow-up.
- This can be the same project as your changing-requirements story, re-angled to its first week.
draft and rehearse your own answer in a learn session
go deeper
Ambiguity is the normal state of engineering work, so this prompt probes communication and ownership under uncertainty rather than technical depth. A strong answer proves you converted a vague ask into a written, agreed scope through targeted questions and cheap validation, and that you did it without stalling, guessing for weeks, or treating the requester as an obstacle.
I had been on the team about four months when we started moving an internal reporting service off the shared enterprise database onto its own cluster. My ticket said, in full: make reports read from the new cluster. There were nine report types, and I had no idea whether all of them were in scope, whether day-old data was acceptable, or what happened to the nightly export that two other teams pulled from. So before writing anything I spent a morning listing what I did not know. That came to eleven questions, which I cut down to the five that would actually change the design, and I took those to the analyst who owned the reports and to my tech lead in one fifteen-minute call rather than drip-feeding them across a week. Two of the answers reshaped everything: only two of the nine reports needed live data, and the nightly export was being retired regardless. I wrote the answers back into the ticket as a short assumptions list — which reports were moving, what staleness was acceptable, and what I was explicitly not touching — and asked the analyst to confirm it in a reply. He corrected one line, which told me the exercise had been worth doing. The build was then about a week instead of the month I had originally sketched, and when that migration wave finished, peak connection-pool saturation on the shared pool had gone from 93 percent to 58 percent. Nobody had to redo my part. I have written an assumptions comment on every thin ticket since.
The signal sits in the middle beats: eleven questions narrowed to five, batched into one short conversation, then written back where the requester could correct them. The scope is honestly junior, one ticket and one requester, and that is fine. Guessing at the nine reports, or listing the questions without saying what the answers changed, would flatten it.
Later in the same migration programme I owned the batch side: eleven overnight jobs that had to be pointed at the new cluster before the change freeze. What I got from the platform lead was one line — move the batch jobs over — and a date. A clarifying thread would have run for days, so instead I timeboxed two days to a throwaway prototype. I pointed three representative jobs at a copy of the new cluster and watched what broke, which told me far more than a meeting would have. Three of the eleven held transactions open long enough to starve the pool under the new sizing, and two of them fed a report that, when I checked the access logs, nobody had opened in seven months. I turned that into a one-page note with three sections: the assumptions I was working from, what I proposed to cut, and a done-means section listing the exact checks we would run on cutover night. Twenty minutes with the platform lead and the finance analyst got the two dead jobs retired rather than migrated, which was a chunk of work I would otherwise have done for nobody. Cutover ran without a rollback. Wait time at p99 on the batch pool fell from 2.3 seconds to roughly 190 milliseconds, and saturation stayed under 44 percent across the weekend. The done-means section is the piece I kept: I write it now before I give an estimate, not after.
Middle-scope markers here are the prototype used as the clarifying instrument instead of a meeting chain, scope actively cut with evidence, and a written done-means the requester agreed to before the build. Dropping the prototype, or ending at cutover went fine with no measurement, would pull this down a rung.
Scope is your own ticket, and that is fine. Show that you asked before guessing, batched your questions instead of drip-feeding them, and wrote the answers back somewhere durable so the requester could correct you.
Work at feature scope and show you unblocked yourself: a timeboxed spike or throwaway prototype used as the clarifying instrument, plus a written assumptions note a peer could review. Naming what you cut from scope is a strong signal here.
You are expected to clarify on behalf of others, not just yourself. Show the scope written once for a whole workstream, a trade-off you closed rather than escalated, and what you deliberately left out so the team did not build it.
Talk about the intake itself. A repeatable mechanism, such as a required problem statement before anyone is staffed, is what makes vague asks stop arriving as tickets across several teams, and it should outlive the project you describe.
saying these in an interview costs you the question
- Blaming the requester for being unclear instead of owning the clarification
- Guessing at the intent and building for weeks with no check-in
- Listing the questions you asked but never saying what the answers changed
- Escalating to a manager as the first move rather than after a real attempt
- No agreed definition of done, so the story ends with no result at all
- How long did you spend clarifying before you started building?Name a bound and the reasoning behind it. Interviewers are checking that clarification was timeboxed rather than open-ended, so say what you gave it, what you would have done if the answers had not arrived in that window, and why the size fit the cost of building the wrong thing.
- What did you do when the requester could not answer either?This is the real test of the prompt. Describe how you proposed an answer rather than waiting for one: a written assumption with a default you would build to unless corrected, a small prototype that made the choice concrete, or a decision you flagged as reversible so it could be revisited cheaply.
- What would you do differently if you got that same ask again?Pick one specific change, not a general resolution to communicate better. The strongest version names an artefact or a moment you would add earlier, and admits what it would have cost you at the time to do it.
## Common variants This prompt shows up in almost every loop, usually worded as a story request but sometimes as a process question. Common variants include: - tell me about a time you had to work with unclear requirements; - describe a project where you did not know what success looked like at the start; - how do you handle a ticket that just says make it faster; - walk me through how you turn a one-line request into something buildable. All of them are scored on the same axis, so prepare one story and re-angle it rather than preparing four. ## Freeze, guess, or convert What the interviewer is actually testing is whether ambiguity makes you **freeze**, **guess**, or **convert**. - **Freezing** looks like waiting for someone else to write the spec. - **Guessing** looks like weeks of work justified afterwards by the wording of the ticket. - **Converting** looks like a short, deliberate sequence: 1. find out what is genuinely unknown, 2. ask the small number of questions that change the design, 3. write the answers down where the requester can correct them, 4. validate the risky assumption cheaply, 5. and agree what done means before committing real time. ## Four kinds of evidence Four kinds of evidence separate strong answers from plausible ones. 1. **First, the questions themselves**: a strong answer quotes one or two and says what the answers changed, rather than claiming a clarifying conversation happened. 2. **Second, an artefact**: a ticket comment, a one-page note, a message in a channel. Anything durable proves the assumptions left your head. 3. **Third, a cheap check**: a spike, a throwaway prototype, a query run against real data, a sketch shown to the requester. The point is that the check was disposable and fast, not that it was clever. 4. **Fourth, an agreement on done**: the sentence you and the requester both accepted before you built. ## Airtime The airtime failure is the most common structural problem. Candidates spend ninety seconds explaining the organisational context and ten seconds on the outcome. - Keep setup to fifteen or twenty percent. - Put the bulk on what you did. - Reserve a quarter for the result and one line of reflection. ## Tone matters more here than on most prompts There is a version of this story that is really a complaint about a requester who could not express themselves, and interviewers hear it instantly. The requester is almost never the antagonist: they are describing a problem in the language available to them, and your job is **translation**. Keep them a collaborator in the narrative, and give them credit for the answer that unlocked the design. ## How the bar shifts by level The bar shifts by level in scope rather than in structure. - **Early on**, clarifying your own ticket well is a complete answer. - **In the middle**, you are expected to reduce the ambiguity for a feature and to have used a prototype or a spike so that you did not need a chain of meetings. - **Senior answers** clarify for other people and name what was cut, because a scope that only grows is a scope nobody negotiated. - **At the top**, the interesting material is the intake mechanism, not the ticket. ## The fallback If you genuinely have no story yet, the fallback is to describe the last vague ask you received and how you would handle it now, then say plainly that this is your current practice rather than a past result. That is weaker than a real episode, but it is far better than inflating a small one into a crisis.