Every FDE interview guide describes this round and then tells you to find a human partner to rehearse with. Here it is instead. You get an open, real-world problem with no technical framing — and, exactly like the real round, you are scored on the clarifying questions you ask before you are allowed to propose anything. Then you decompose, prioritise, and say what you would not build. Four cases; an interviewer verdict at the end. This is the round Palantir is famous for and the one that most often decides an FDE loop.
pick a case · 5 clarifying questions · decompose & prioritise · name your cuts · get scored
The real round runs about an hour. Here it runs in three phases. In phase 1 you may only ask questions — the solution button is disabled until you have asked five, because that constraint is the lesson.
0
questions
0
score
1/3
phase
What this round is actually measuring
It is not a systems-design round with the diagram removed. The question behind every decomposition round is narrower and harsher: can we drop this person at a customer, alone, with a vague problem and a hostile network, and will they come back with something sensible?
01
Do you scope before you solve?
Strong candidates spend their first five minutes on who the user is, what decision changes, and what “better” measures. Weak candidates propose a pipeline. There is no recovery from the second one, because it is a direct sample of how you would behave in week one of a deployment.
02
Do you find the real constraint?
Almost every real customer problem is gated on data access, ownership, legality, or a person who does not want the project to succeed. A plan that assumes clean, complete, accessible data is a plan that has never met an enterprise.
03
Can you prioritise, out loud, with a reason?
A flat list of six workstreams scores near zero. “I would do B first, because without it A cannot be measured, and C is cheap enough to defer” scores highly — even if the interviewer disagrees with the ordering.
04
Will you say no?
Naming what you will not build is the clearest single signal of judgement available in an interview. It is also the behaviour that saves real deployments, which is why it is scored so heavily.
05
Do you adapt when a premise changes?
Interviewers routinely remove a constraint late — “actually, you cannot have that data”. Defending the original plan after its foundation is gone is a fail. Re-planning cheerfully is a strong pass.
The minute-by-minute shape
A real sixty-minute round has a recognisable rhythm. Knowing it keeps you from spending forty minutes in one phase.
// the shape of a strong decomposition round00–05 who is the user? what decision changes? what does "better" measure?
05–12 what data exists, who owns it, what is legally usable, what is the timeline?
12–25 decompose → 3–4 independent sub-problems, ordered, with reasons25–40 depth on ONE: approach, failure modes, how you would know it worked
40–50 the cut list: what you are not building, and the week-one assumptions to test
50–60 constraint flip → re-plan out loud, cheerfully
Notice that the first twelve minutes contain no proposal at all. Candidates find this uncomfortable and rush it; interviewers are explicitly watching for whether you can tolerate that discomfort, because a customer conversation feels exactly the same.
first proposal
≥ 12 min
sub-problems
3–4
depth on
exactly 1
cut list
volunteered
The picture: three phases, one score
The simulator scores the round’s three habits in order: ask before you propose, diagnose before you build, and say what you will not do. Every negative score is the same mistake in a different form, committing to a solution before the problem is clear. The dashed box is what the simulator cannot do and a real interviewer will: change a premise and watch whether your decomposition survives it.
Worked example: three runs of the emergency-response case
The same case played three ways, scored exactly as the lab scores it. Run A scopes first. Run B picks the right three sub-problems but in the wrong order. Run C opens with techniques.
Run
Phase 1: five questions
Phase 2: three sub-problems
Phase 3: two cuts
Total
A: scope first
definition of response time +3, where the minutes go +3, who acts +3, average or percentile +2, joinable key +2 = 13
no automated decisions +4, no live experiments +4 = 8
34 / 34 = 100%, strong hire
B: right picks, wrong order
same five = 13
joinability first +3, segment second +3, decision points third +4 = 10
same two = 8
31 / 34 = 91%, strong hire
C: solution first
RL dispatch −2, A/B test live calls −2, calls per day +1, definition +3, budget −2 = −2
ETA model −2, segment the delay (second) +3, automated dispatch −2 = −1
no live experiments +4, no baseline segmentation −3 = +1
−2 / 34, shown as 0%, no hire
Run B shows that order costs points even when the picks are right: swapping the first two sub-problems loses 3, because the formula is 4 − |rank − position|, with a bonus for putting rank 1 first. Run C asked the best question in the case and still finished below zero, because three technique questions cost 6 points. One more thing to know about the counter: each case has only three +3 questions, so phase 1 tops out at 13, and the best five questions are three +3s and two +2s.
Trade-offs: what each first move costs
Phase 2 ranks the sub-problems by what they cost and what they prove. Read the columns as first move, time to a result, cost if it is the wrong move, why it is ranked there. The rankings are the lab’s own, across its four cases.
Case
Time
Space
Why
Measure the baseline
shortest
low: you still have a number
Without it nothing you do later can be shown to have helped.
Diagnose where the time or money goes
short
low
Often shows the problem is not where anyone assumed, which changes everything after it.
Check data quality and joinability
short to medium
low
Unglamorous, but it gates every analysis that follows. In the fraud case it is the whole project.
Build a prediction model
long, and it needs labels
high: it may not be the lever
Ranked 5 to 6. Attractive, but you have not yet shown prediction is the problem.
Build a real-time system
longest
highest
Real-time multiplies cost and proves nothing a batch analysis could not.
Stand up a platform or rewrite a core engine
open-ended
it eats the engagement
A separate programme dressed up as a task.
The pattern behind the lab’s rankings: cheap, fast work that reduces uncertainty comes first, and expensive work that assumes an answer comes last or gets cut. An interviewer accepts a different order if you give a reason. They do not accept a build placed before the diagnosis that would justify it.
Common mistakes
Questions that are solutions in disguise
“Can we get real-time GPS streams so we can build live dispatch?” is phrased as a question, but it picks the solution and the architecture at once. The lab scores it −2. A good question could change your plan; a disguised solution assumes the plan.
Spending a slot on sizing
“How many trips a day?” is a fine question and scores +1. With five slots, though, it pushes out a +3 question like “what decision would this change?”. Sizing and plumbing can come later, once the frame is set.
Right sub-problems, wrong order
Run B above lost 3 points with the correct three picks. In a real deployment the same mistake means cleaning data for an analysis nobody has asked for yet, or diagnosing after the build. Say why each step has to come before the next one.
Cutting discovery to look fast
“No baseline” and “no conversations with dispatchers” both score −3. They read as decisive, but they remove the part of the plan that makes the rest correct. Cut expensive builds, never the work that tells you what to build.
The taxi brief has three possible users (driver, dispatcher, city planner) and the marketplace brief has two sides. Optimising for everyone means optimising for no one. Pick one, say why, and say what the other side gives up.
Check yourself
You are given “improve 911 response times”. What is the strongest first move?
“Response time” is three different metrics with three different owners and three different fixes. Optimising the wrong segment is the classic wasted deployment. Definition first, always — and the answer often reveals that the biggest delay is somewhere nobody expected.
Twenty minutes in, the interviewer says: “Actually, you cannot have access to the dispatch logs.” What do you do?
The flip is deliberate. It is testing whether your plan was reasoned (in which case you can say precisely what breaks and rebuild) or memorised (in which case you defend it). Naming the invalidated assumption before re-planning is what earns the marks — that is exactly what you would do in week three of a real deployment when security says no.
Which ending scores highest?
Breadth is cheap and reads as avoidance; depth plus explicit cuts reads as someone who has actually delivered something. The week-one assumption list is the highest-value closing move available — it shows you know the plan is a hypothesis, which is the single most FDE thing you can demonstrate.
Common questions
What is the decomposition round in an FDE interview?
An open, non-coding problem — analysing a city’s taxi data, improving emergency response times, unifying fraud signals. You are scored primarily on the clarifying questions you ask before proposing anything, then on decomposing the problem into prioritised sub-problems, going one level deep on the first, and stating explicitly what you would not build.
How do you pass a decomposition round?
Spend the first five minutes on questions rather than architecture. Establish constraints — what data exists, who owns it, what is legally usable. Decompose into independent sub-problems and say which you would attack first and why. Go one level deep on that one. End by naming what you are explicitly not building and the assumptions you would test in week one.
Which companies use a decomposition round?
Palantir’s forward deployed software engineer loop is the best-known user and the round it is named for. The same archetype appears as case and scenario rounds at OpenAI, Anthropic and other companies hiring forward deployed and applied AI engineers, because it tests the thing all of them care about: can this person be left alone with a customer’s ambiguous problem.
What is the most common way to fail?
Proposing a solution before scoping the problem. Conventional interview preparation trains exactly that reflex, which is why strong algorithm candidates fail this round. Silence is the second most common failure — an interviewer can only score reasoning they can hear, so narrate continuously, including the dead ends.
Is this simulator the real round?
No — a real round is a live conversation with a human who probes and flips constraints. This drills the two things you can practise alone: which questions are worth asking, and the discipline of not proposing until you have asked them. Do it four times, then find a person for the conversational half.