Tell me about a time you had to deliver with unclear requirements or a deadline you did not believe in.

Two questions wearing one coat

Unclear requirements and an impossible deadline are usually asked together, and they test different things. Ambiguity is a question about whether you can act on incomplete information without either freezing or inventing a specification nobody agreed to. A bad deadline is a question about whether you negotiate. Prepare a story that carries both if you have one, but know which half you are answering at any moment, because the strong behaviour differs: ambiguity rewards documented assumptions and small reversible steps, while a bad date rewards early, evidenced escalation.

Something both halves share is that the interviewer is watching for a particular refusal. Plenty of candidates answer this question with a story about heroism — the weekend worked, the sprint compressed, the launch made at 3am. Heroism is a weak answer at senior level and an actively negative one at lead level, because it demonstrates that you will absorb an organisational problem into your own evenings instead of surfacing it. The manager listening has to plan capacity, and someone who silently absorbs is someone whose projects fail without warning.

Making the ambiguity smaller before you start

The behaviour being scored is compression of the unknown, and it has a recognisable shape. First you find out what is knowable — read the code, look at the data, watch three users, find the one person who remembers why the field exists. A large share of what presents as "nobody knows the requirement" is really "nobody has looked", and being the person who looks is a disproportionately strong signal.

Then you separate what genuinely cannot be settled from what merely has not been, and for the residue you write assumptions down and circulate them. This is the most reproducible technique in the answer. An assumption held in your head is a private bet; the same assumption in the ticket is an invitation for the one person who knows better to say so. The phrasing that works is not a question, because questions to a group get no reply. It is a statement with a deadline attached: unless someone tells me otherwise by Thursday, I am building it so partial refunds are not supported in v1 and such a request is rejected with a clear error. That format gets corrected when it is wrong and ratified by silence when it is not, and either outcome is progress.

Then you sequence by reversibility. Build what is cheap to undo first and defer the expensive decisions — data model choices, anything written to a customer, anything another team integrates against — until the ambiguity resolves or you are forced. When forced, choose the option that fails visibly over the one that fails silently.

Renegotiating a date without sounding like you are refusing

A deadline you do not believe in has to be challenged, and candidates avoid it because they have no form of words that is neither capitulation nor defiance. Three components make the difference.

Timing. The objection is worth something the week the plan is made and almost nothing the week before the date. Raising it early is the entire difference between a professional flagging a risk and someone making excuses, and interviewers listen for when far more closely than for what.

Evidence. "That is not enough time" is an opinion and will lose to the opinion of whoever wants the date. What wins is a decomposition: here are the eleven pieces, three of unknown size, one that depends on a team who have not agreed to it, and here is the same integration taking five weeks last year. Dates argued down with a breakdown tend to move; dates argued down with a feeling do not.

Options, and this is the part most often missing. Never bring only the problem. Bring the date with reduced scope, the full scope with a later date, and the full scope on the original date with a named risk you are asking someone else to accept in writing. That third option converts the conversation from you failing to deliver into them choosing, which is where the decision belongs.

Choosing what to cut

How you choose reveals seniority. The weak instinct is to drop what is easiest or least finished. The stronger one ranks by consequence of absence: what a user hits on day one, what an operator needs to run the thing at all, what a regulator requires, and what is genuinely deferrable by a fortnight. Manual processes are legitimate temporary substitutes and are undersold in interviews — shipping a feature where someone in operations does one step by hand for three weeks is often correct, and saying so shows you optimise for the outcome rather than the elegance of the system.

What you cut has to be agreed by whoever will notice, and named in the answer. "We cut the reporting screen and the PM signed off on it landing the following sprint" is a complete thought. "We descoped some things" is not.

Where these answers fall apart

The commonest is the answer with no artefact in it. Everything happened in conversations, nothing was written, and the story has no defence against "so how did you know when you were done?". The second is the heroism ending. The third is subtler and specific to senior candidates: you resolved the ambiguity by deciding the requirement yourself and never telling anyone. That is decisive, and it is also how teams ship the wrong thing confidently. The line the interviewer is drawing is between deciding provisionally in public and deciding privately.

How it sounds when it is done well

Take the moves, not the words.

"We were asked to add 'partial refunds' to the checkout, with a date six weeks out because it had been promised to a large customer. The requirement was one line in a ticket and the person who had promised it had left.

First I stopped treating it as unknowable and went and looked. A year of refund records showed that about eighty per cent of what support did manually was a single-line refund on a multi-line order, not an arbitrary amount — so line-level refunds covered most of the need and were far simpler.

Then I wrote seven assumptions into the ticket and posted them in the channel as decisions rather than questions, with a Thursday cut-off. Two came back corrected, and one mattered a great deal: finance told me a refund had to preserve the original tax breakdown, which would have been expensive to discover late.

On the date, once the tax work appeared I did not think six weeks was credible, and I said so in week one rather than week five. I took a breakdown to my manager and the account lead with three options: line-level refunds on the original date, arbitrary amounts two sprints later, or everything on the date with no reconciliation report and finance doing that by hand. They chose the first, and the customer was told what was in scope — only possible because the conversation happened in week one.

We shipped on the date, and arbitrary amounts followed about five weeks later. What I got wrong is that the tax-breakdown assumption stayed in a chat thread instead of the design doc, and a colleague later rebuilt part of it not knowing why the field was there. It is why I now put assumptions in the document rather than the channel."

Preparation

For each story, be able to name the assumption you wrote down and where you wrote it, the thing you cut and who agreed, the week you first raised the date, and one assumption that turned out to be wrong. That last one is asked more often than candidates expect, and having a real answer to it is worth more than a clean story with none.

The scored behaviour is not tolerating ambiguity, it is shrinking it in public — writing down what you are assuming and when you will proceed anyway, so that being wrong is cheap and discoverable rather than silent.