TL;DR: Pick a project where the goal itself was undefined, then make week one a reconnaissance ritual: interview the people in the pain, profile the real data, and write the one-page memo that becomes the spec you weren't given. Land it with a metric and a real scar.
How to approach it
This is the FDE staple because the job is ambiguity: you land at a customer with a vague mandate ("make AI work for claims") and no spec. The interviewer is scoring two things: did you own something undefined (not "my manager handed me a ticket with fuzzy wording"), and do you have a repeatable method for converting fog into a plan. Pick a story where the goal itself was unclear, not just the implementation.
Structure it: (1) why it was ambiguous (no spec, conflicting stakeholders, unknown data), (2) what you did first, (3) how you created the definition of done, (4) outcome with a number, (5) what you'd do differently.
A strong answer
The week-one answer is the differentiator. A strong candidate describes a concrete reconnaissance ritual, in first person:
"In week one I didn't write code. I did three things. First, I interviewed the five people closest to the pain, not the sponsor's deck, the analysts actually doing the work, and asked each 'what does a good week look like, and what ruins it?' Second, I got read access to the real data and spent two days profiling it, because data reality kills more plans than bad architecture. Third, I wrote a one-page memo: here's the problem as I understand it, here's the smallest thing we could ship in two weeks that someone would use, here's what I'm explicitly not doing. I sent it to the sponsor and asked them to mark it up. That memo became the spec, I wrote the spec I wasn't given."
Then land the outcome: "We shipped the narrow version in three weeks; it cut report prep from two days to two hours, which earned us the political capital to do the bigger build."
The closing self-critique should be real: "I waited too long to surface a stakeholder conflict between ops and compliance, I'd now force that conversation in week one, not week four."
Week one is where this answer is won or lost, and the follow-up is almost always "what did you do in the first week":
| Day | What you did | What it proves |
|---|---|---|
| 1-2 | Talked to the people doing the work today, not the sponsor | You find the workflow, not the wish |
| 2-3 | Got access to the real data, not the sample they prepared | Sample data is always cleaner than reality |
| 3-4 | Wrote down what you would NOT do | Scope is defined by exclusions |
| 5 | Shipped something thin that ran end to end | You crossed every boundary before committing |
Candidates who describe week one as reading documentation and setting up their environment have described onboarding, not ownership.
Transitioning candidates often believe they have no ambiguity story because they have never been handed a customer. Look again: ambiguity is about the goal being undefined, and undefined goals are everywhere. A software engineer told "make the dashboard faster" with no definition of fast, no named dashboard, and three teams who each mean a different one, owns an ambiguous project the moment they go find out which complaint generated the request. A data analyst asked "why is churn up?" when churn is not even instrumented owns one. A support engineer told to "do something about ticket volume" owns one. The test is not the setting; it is whether you had to write the definition of done, and whether you can show the artifact you wrote. What disqualifies a story is the opposite shape: a well-specified ticket that happened to be technically brutal. Difficulty is a different question, and interviewers notice the substitution immediately.
What interviewers probe next
- "How did you know your narrow scope was the right one?", talk about value × feasibility, and validating with the people who'd use it.
- "What if the sponsor disagreed with your memo?", that's the point of the memo: cheap to correct on paper, expensive to correct in code.
- "Who else worked on it?", keep first-person ownership but credit others specifically; vague "we" throughout reads as inflated scope.
- Palantir-style: they'll perturb the story ("what if the data hadn't existed?") to see if your method survives contact. The winning response re-runs the method under the new condition instead of defending the old plan: "the two days of profiling would have surfaced that by day three, and the memo becomes a different memo, smallest data acquisition that unblocks the goal, what we can ship meanwhile from what does exist, and a revised timeline to the sponsor before they hear it from someone else." A rehearsed narrative breaks under perturbation; a real method just takes new inputs, and showing that is the entire point of the follow-up.
Common mistakes
- Choosing a story that was merely hard, not ambiguous, technical difficulty is a different question.
- A week one of "I started building." Jumping to solutions is the #1 decomposition failure mode and they're testing for it here too.
- No artifact. Strong answers produce something checkable: a memo, an eval set, a prioritized backlog.
- Ending without a metric or without what you learned. "It went well" is not an ending; "two days to two hours, and here's my scar" is.