Tell me about a time you were handed a project with no clear scope or requirements.
answer
- the ask, quoted as it arrived
- knowns list, unknowns list
- written plan, three milestones
- the scope you cut, out loud
- result number plus what outlived it
basics
~20 sTests whether you create structure instead of waiting for it. Answer with the vague ask as it arrived, how you split knowns from unknowns, a written plan with milestones and one explicit scope cut, and a measured result.
how to answer
6 beats- the ask, quoted as vaguely as it actually arrivedOpen with the literal sentence you were given and who gave it. Establish the vagueness in two or three sentences — this beat plus the next should be about fifteen to twenty percent of your airtime, not a tour of the confusion.
- what you already knew and what you had to go find outSay how you split the two, and how you bought the cheapest evidence for the unknowns — a measurement, a sample, a few conversations. Naming the evidence you gathered before proposing anything is what separates this from guessing.
- the structure you proposed and the scope you cutDescribe the artifact: a plan, milestones, an explicit out-of-scope list. Name at least one thing you cut and the reason you gave for cutting it. This beat is the centre of the answer and should carry the most weight of the roughly sixty percent you spend on action.
- how you drove it and what you changed on the wayShow the cadence — checkpoints, owners, how you reported progress — and one point where new information made you revise the plan. Revising on evidence reads as strength; never revising reads as luck.
- where it landed, with a numberGive the outcome concretely: what shipped, by when, and one measure that moved. Result and reflection together are the last twenty to twenty-five percent, so keep it tight but do not let it evaporate into we got it done.
- what you kept doing because of itClose with the habit or artifact that outlived the project, and one honest thing you would sequence differently. This is the beat that turns an anecdote into evidence of how you work.
your answer
5 story prompts- Pick a project where the ask arrived as one sentence and you had to define done yourself.
- Recall the artifact you produced — a plan, a memo, a milestone list — and what happened to it after.
- Name one thing you cut from scope and the person who pushed back on the cut.
- Have one number ready for the result, even an internal metric nobody outside your team tracked.
- Note the moment new evidence made you revise the plan, and say what the evidence was.
draft and rehearse your own answer in a learn session
go deeper
Ambiguity is where ownership becomes visible. The interviewer wants to know whether you can turn a goal into a plan without being handed one: separating what is known from what must be discovered, proposing structure others can argue with, and committing to milestones. A strong answer proves initiative and judgement about what to cut, not merely a high tolerance for chaos.
I maintain an open-source dependency scanner, and the ask I inherited was one line in a roadmap issue: make triage manageable. Nobody had defined what triage covered or when it was done. I spent the first week measuring instead of building. I exported the report queue: 63 open vulnerability reports, a median of nine days from submission to a maintainer verdict, and roughly two thirds of them duplicates of five upstream advisories. That gave me a knowns list and an unknowns list, and I posted both back in the issue so the other maintainers could correct me. Two did. Then I proposed structure. I wrote a one-page plan with three milestones — deduplicate against upstream advisories, pre-fill severity for a single package ecosystem, and a triage rota — plus an explicit out-of-scope section. The out-of-scope part is what made it work. The original idea also included a rewritten intake form and a contributor dashboard, and I cut both, in writing, with reasons. One maintainer pushed back hard on losing the dashboard; I offered to revisit it once the first milestone landed, and he took that. Six of us, none full-time, shipped the first two milestones in eleven weeks. Median triage fell from nine days to 31 hours, and duplicates dropped to about a seventh of the queue. Afterwards I kept the one-pager as a living document. We now open every larger effort with the same knowns, unknowns and out-of-scope format.
The signal sits in three places: measuring before proposing, a written artifact peers could correct, and a named cut with a named objector and a landing place for him. Losing the out-of-scope section, or ending at we shipped it with no number, would downlevel this to an ordinary project recap.
Later the project's steering group asked me to improve our security response posture before a major release train. That is a goal, not a scope, and it spanned four sub-repositories with different maintainers and no shared process. I deliberately did not write a plan in the first week. I ran a two-week discovery instead: interviewed seven maintainers, read the last 34 incoming reports end to end, and wrote up what was actually true. Three of the four repos had no private disclosure channel at all, and the verdict time across them sat at six days with a tail past a month. Then I published a scope memo. Five candidate workstreams, two funded by the time I could realistically get, the rest deferred with the reasoning attached. I cut the automated fix-PR workstream, which was the one everybody was excited about, and I said out loud in the meeting that I was cutting the popular thing because it depended on triage being fast and triage was not fast yet. That landed better than burying it in a document. The two survivors became fortnightly milestones with a named owner per repo, and I posted a four-line status every fortnight — done, next, blocked, changed — to a public thread. By the release train all four repos had a disclosure channel and the verdict time was down to 38 hours. The bigger outcome was the memo format itself; the steering group now asks for one before funding any cross-repo effort.
Four things meet the senior bar: discovery before commitment, a cut defended in the room rather than in a document, owners and a public status rhythm, and an artifact the group adopted. Drop the named owners or the fortnightly status and it reads as a mid-level plan with a bigger word count.
Own the task, not the whole plan. Show that you asked precise clarifying questions, wrote your own understanding of done in a message or ticket, and got it confirmed before building. One assumption you checked early is enough evidence.
Own a feature-sized slice end to end. Measure or investigate before proposing, produce a written plan your peers can argue with, and name at least one thing you deliberately left out and why you left it out.
The scope is a team and a quarter. Show the discovery you ran before committing, a cut you held under pressure, milestones with named owners, and the status cadence that kept people aligned while the facts kept moving.
Talk about the mechanism, not the project. Show how you make ambiguous work legible across groups — a scoping memo format, a decision record, a standing review — and how you defended an unpopular cut to whoever was funding the work.
saying these in an interview costs you the question
- Waiting for someone else to define scope before doing anything at all
- Describing the chaos at length with no structure you personally proposed
- A plan with no milestones, no owners and no explicit out-of-scope list
- Framing the ambiguity as someone else's failure rather than your problem to solve
- Ending with the project shipping but no number and no reusable artifact
- Claiming you clarified everything upfront, which means you never had ambiguity
- What did you cut, and who disagreed with cutting it?Name a real cut and a real objector; a plan nobody argued with was not ambiguous. Say what the objection was, what you offered instead (revisit after milestone one, a smaller version, a written reason), and whether the objector stayed engaged. Avoid rewriting history so that everyone agreed with you.
- How did you know your plan was right before you had any results?You did not know, and saying so is the strong move. Describe the cheapest evidence you bought first — a sample, a measurement, a week of reading the queue, a prototype — and the checkpoint at which you would have changed the plan. Interviewers reward falsifiable plans over confident ones.
- What would you do differently if you were dropped into that again?Pick one structural regret, not a character flaw. Good answers name a decision you would sequence differently or evidence you would gather sooner, then say what you now do by default because of it. Skip anything that sounds like a rehearsed weakness.
## One question, several costumes This prompt appears in almost every mid-level and senior loop, usually in the hiring-manager round, and it wears several costumes. The common variants are: - *tell me about a time you had to make a decision with incomplete information*, - *describe a project where the requirements were unclear*, - *how do you start when nobody can tell you what done looks like*, and - *tell me about the messiest project you have owned*. They are one question. Prepare **one story** and re-angle the opening sentence to whichever wording arrives. ## What the interviewer is actually sorting for Executors wait for a specification and then complain about its quality. The people this question is looking for do three things instead: 1. they convert a goal into a **written artifact**, 2. they buy **cheap evidence** before committing, 3. and they **cut**. Notice that only the third one is uncomfortable, and it is the one weak answers omit. If your story contains no sentence of the form *and I decided we would not do X*, the interviewer has not seen the signal they came for. ## Weak versus strong, on the same story - A **weak version** sounds like: the requirements were vague, so I asked a lot of questions, then we figured it out as we went and shipped it. Every clause is passive, the ambiguity is someone else's fault, and there is no artifact. - The **strong version** of the identical project sounds like: the ask was one sentence, so in week one I measured the current state instead of building; I wrote a page listing what we knew, what we had to find out, three milestones, and an explicit out-of-scope section; I cut the two most exciting items and said why in writing; we hit the first two milestones and the number moved from here to here. Same events, but now the interviewer can see decisions with your name on them. ## Evidence types that land In descending order of strength: 1. a written artifact that outlived the project (a scoping doc, a decision record, a milestone board others reused); 2. a measurement you took before proposing anything; 3. a named cut with a named objector and how you handled them; 4. a checkpoint where you changed the plan because the evidence changed; 5. a number in the result. You do not need all five. Two, told concretely, beats a survey of all five told vaguely. ## Airtime The most common structural failure is a long, loving description of how confusing everything was. **Ambiguity is the setup, not the story.** - Spend fifteen to twenty percent establishing the vagueness, - sixty percent on what you did — the measuring, the writing, the cutting, the driving — - and the remaining twenty to twenty-five percent on the result and what you would repeat. ## How the bar moves - At **mid-level** the interviewer wants to see that you can produce structure for yourself and your immediate peers. - At **senior** they want structure that other people executed against — owners, checkpoints, a status rhythm — and a cut you held when someone senior wanted it back. - At **principal** the project is almost irrelevant; what is being assessed is whether you left behind a repeatable way of scoping ambiguous work, and whether you can name the political cost of a cut without either dramatising it or pretending it was free. ## One trap Some candidates try to prove sophistication by describing an ambiguity they never resolved — an ongoing project, a plan still in flux. It reads as unfinished. Choose a story with a landing, even a modest one, and be honest about which parts of the fog you never cleared.