The Palantir Decomposition Interview, Explained

The decomposition interview hands you a deliberately broad operational problem and asks you to turn it into something buildable. A representative prompt: a major city wants to use our platform to cut emergency dispatch times in half. Another: a national grid operator wants to predict and prevent wildfire risk across its transmission network.

There is no correct answer, and that is the point. The interviewer is watching how you convert ambiguity into a scoped, sequenced, defensible plan, because that is the first two weeks of any real deployment. Palantir originated the format and it has spread with the role, so you will meet a version of it at AI labs and applied AI companies under names like case study or applied problem solving.

It is also the round candidates prepare for least, because it does not look like something you can practise. It is, and the structure below is what separates a strong performance from a rambling one.

Step one, gather context and frame the scope. Interview the interviewer before you design anything. Who is the actual user, dispatchers or call takers? What is the number today and what would count as success, twelve minutes down to five? What data exists, who owns it, and what condition is it in? Candidates who start drawing architecture in the first two minutes have already lost the round.

Step two, propose a layered architecture rather than a monolith. A shape that generalises well is ingestion, then visibility, then optimisation. Ingestion connects the real sources, computer-aided dispatch logs, vehicle GPS, radio traffic. Visibility gives operators a live picture they do not currently have. Optimisation adds routing or allocation models on top. Naming the layers lets you talk about sequencing instead of features.

Step three, cut a thin slice and say why. Name the smallest deployment that delivers real value on its own, which is almost always visibility rather than prediction. Real-time vehicle location on one map, for one district, is worth more in week three than a dispatch optimisation model nobody trusts yet. This step is where interviewers most often decide whether you have actually shipped something before.

Step four, address the operational constraints out loud. Network outages, stale GPS, access control and who is allowed to see what, union and process implications, and what happens when a dispatcher ignores the recommendation. Raising adoption risk unprompted reads as experience, because it is the thing that actually kills deployments.

Prompt: a city wants to halve emergency dispatch times using our platform.

Framing: before designing, I want three things. Which part of the interval are we attacking, call answer to dispatch, or dispatch to on-scene? Those have completely different fixes. Who is the user I am building for, the call taker or the dispatcher? And what is the baseline, is twelve minutes an average, a median or a 90th percentile, because halving an average and halving a tail are different systems.

Data reality: I would expect computer-aided dispatch logs in a legacy relational system with inconsistent incident typing, vehicle GPS arriving on a separate feed at variable frequency, and radio or voice data that is effectively unstructured. I would assume none of it joins cleanly on the first attempt and plan for an identity resolution problem between incidents and units.

Layers: ingestion normalises incident records and unit telemetry into one timeline per incident. Visibility gives the dispatcher a live map of unit status and a clock on each open incident, which is usually the first time anyone has seen the whole picture in one place. Optimisation, later, suggests the unit to assign and flags incidents drifting past a threshold.

Thin slice: two weeks to a live unit-status map for one district, with the incident clock. No model. It is useful on day one, it forces the data problems into the open early, and it earns the credibility needed to ask for the harder integration.

Constraints: GPS goes stale and a map that silently shows a stale position is worse than no map, so staleness has to be visible in the interface. Access control matters because not every user should see every incident type. And I would want a manual override on any recommendation, both because dispatchers will not adopt a system that removes their judgment and because the first version will be wrong in ways we have not predicted.

Measurement: I would instrument dispatch interval by incident type from the first day of the visibility layer, so that when the optimisation layer ships we can attribute the change rather than claim it.

Whether you asked before you answered. The single strongest signal is a candidate who treats the prompt as incomplete and closes the gaps with specific questions rather than generic ones.

Whether your plan is sequenced. Any competent engineer can list components. Fewer can say what ships first, what it is worth on its own, and what it unlocks next.

Whether you thought about the data as it will actually be, not as it should be. Naming the join that will fail is worth more than naming the database you would choose.

Whether adoption entered your answer without prompting. Software nobody uses is the dominant failure mode in this job, and interviewers are explicitly listening for whether you know that.

Whether you can be challenged without either collapsing or digging in. Expect the interviewer to push back on a decision. The correct move is to state the trade-off you were making, ask what constraint you missed, and update if the pushback is right.

Designing before scoping. Jumping to architecture without establishing the user, the metric or the data state, and then defending a solution to a problem nobody confirmed.

Reaching for the model first. Proposing prediction or an agent as the opening move, when the customer has no reliable data pipeline and no baseline to compare against.

Listing technologies instead of making choices. Naming eight tools without saying which one you would pick here and why reads as unfamiliarity, not breadth.

Ignoring the humans. No mention of who has to change their behaviour, who might resist, or how the thing gets adopted. This is the most common gap in otherwise strong technical candidates.

Refusing to commit. Interviewers are not looking for certainty, they are looking for a defensible recommendation under uncertainty. It depends, with no follow-through on what it depends on, scores badly.

Take any operational business problem and run the four steps out loud against a timer, in about twenty-five minutes. The out-loud part is not optional, because a large share of what this round measures is whether your thinking is legible to somebody else in real time.

Good practice prompts share three traits: a real operational metric, multiple stakeholder groups who disagree, and data that lives in more than one system. Hospital bed allocation, warehouse pick routing, insurance claim triage, fraud review queue prioritisation, and field service scheduling all work.

Then apply the same structure to the last project you actually shipped, and notice where you skipped a step in real life. That reflection tends to produce better interview answers than any amount of reading about the format.