The Decomposition Framework

A one-line brief with no user in it

A fictional regional appliance-repair company, about 60 technicians across three cities, sends you one line before the meeting: "Our techs keep showing up without the right part. Can you build something with AI to fix it?" The sentence names a pain and a technology, and nothing else: no user, no decision, no dataset. Decomposition rounds open with briefs like this on purpose, because the first five minutes show how you think when nobody has handed you the structure.

Two openings feel natural, and both go wrong. The first is to reach for a stack ("I'd fine-tune a model on the call recordings to predict the part"), which sounds decisive and commits you to answers you have not earned. The second is to brainstorm twenty things you could build and leave them unranked, which sounds thorough and commits you to nothing. Both skip the work the round scores, which is turning a vague pain into a sequence of decisions you can defend out loud.

This lesson uses a sequence of seven steps for that: users, workflows, data, systems, MVP, metrics, risks. To see why the order matters, watch the first opening fail on the repair brief. Every number below is made up for the example.

Why reaching for a classifier stalls

Suppose the candidate's first sentence is: "I'd transcribe the call-centre recordings and train a classifier that predicts which part the technician needs from the customer's description." It has the shape of a plan, so why does it collapse?

It rests on three assumptions nobody has checked. It assumes the description carries enough signal to predict a part, when "it's making a grinding noise" fits a dozen parts. It assumes someone acts on the prediction, without naming who or when. And it commits to the recordings before asking whether the company holds better data. An interviewer will let this run for a minute and then ask, "Who looks at the prediction, and when?" With no answer to that, everything downstream has nothing to stand on. The classifier might turn out to be a good idea eventually; at minute two nobody, including the candidate, can tell.

Walking the repair brief one step at a time

Here is the same brief walked in order, with each step named aloud as you enter it. The labels feel stiff at first, and the next section explains why they help.

Users and workflow

"I'm on users first." Two people touch this problem: the dispatcher who books the job and the technician who drives to it. Only the dispatcher can change the outcome before the truck leaves, so the dispatcher is the user for version one, and the technician comes later.

"Now the workflow as it runs today." A customer calls, and the dispatcher types a free-text description into the booking form. The job lands on a route, the technician arrives and diagnoses, and if the part is missing they order it and book a second visit. The decision that matters sits at booking: what to ask the customer, and what goes on the truck.

Data, before any model

"Next, data, before any model." I'd ask what a closed job record holds. Say the answer is the appliance model (technicians read it off the rating plate on site), a symptom code the technician picks after the fix, the parts used, and the number of visits. The booking form also has a model-number field, and it is empty on 60% of bookings because dispatchers skip it. That fact reshapes the plan: the history is rich, and the booking is poor.

Now put numbers on the pain. Last quarter there were 1,200 jobs, and 420 needed a second visit, so the first-visit fix rate (jobs closed in one visit, divided by all jobs) was 780 / 1,200 = 65%. The job records tag 260 of the 420 repeats as "part not on truck". If a second truck roll costs $110, those repeats cost 260 × $110 = $28,600 a quarter. That is the slice to attack first.

Systems and the smallest useful build

"Systems now." Bookings and parts history live in one field-service tool that exports CSV, so no new platform is needed. The step is short because the data step already answered most of its questions.

"Here's the smallest thing that proves value." For one city's dispatch desk, the dispatcher gets the model number on every booking by texting the customer a request for a photo of the rating plate. A lookup table built from past jobs then ranks, for that model and symptom, the parts used on first visits. The dispatcher sees the top three in a shared spreadsheet next to the booking, and the technician loads them. There is no classifier yet, on purpose. If the lookup is right on a large share of jobs, any later model has to beat it. If it is wrong, you have learned the history is too thin before spending a month on training.

Metrics and risks

"How we'd know it worked." The primary metric is part-not-on-truck repeat visits per 100 jobs in the pilot city, against that city's figure for the previous quarter. The company-wide baseline is 260 / 1,200, about 21.7 per 100. The guardrail is booking call length, because a photo request adds friction and dispatchers will drop it if calls drag.

"Last, risks." Customers may not send the photo. Symptom codes are entered after the fix, so the lookup will look better on history than at booking, where the dispatcher has to pick a code from the customer's words. Truck stock may not hold the suggested parts at all, which would make this an inventory problem. Each risk gets a cheap test in week one: count photo replies on day two, re-score the lookup using codes a dispatcher assigns from booking notes, and check the top-three parts against what the pilot trucks carry.

The first answer was a model. The defended answer is a change at the booking step plus a lookup table, with the model held back until there is a baseline for it to beat.

Why the order holds, and where to spend the minutes

Laid out as a reference, the seven steps look like this. The right-hand column is the part that is easiest to skip and the part the interviewer listens for.

Why users first? Users fix the decision, which fixes when the output must exist. Once the dispatcher is the actor, the output has to be ready before the truck leaves, which rules out anything built on the technician's diagnosis.

Why data before systems, and before any model? You cannot pick a tool for data you have not named. Ask where it lives, who owns it, how often it updates, and what fraction is missing. One number from the data, such as the 60% empty model field, does more work than any architecture diagram.

And why say each step out loud? Written down, "I'm on data now" looks mechanical. Spoken, it gives the interviewer a map of where you are and lets them redirect you cheaply ("skip systems, go to the MVP").

The order earns its keep when the interviewer injects a constraint. Say they announce that the field-service vendor won't grant API access. That hits systems, and only systems. Users, workflow and data still hold, and the spreadsheet MVP survives untouched, so you return to systems, adjust, and carry on. Restarting from users wastes ten minutes and signals that the earlier steps were not load-bearing. Close the whole walk with two sentences: the MVP, and the metric with its baseline.

The method has a cost: it is slower in the first ten minutes than diving in, which is a real price on a timed round. On a 45-minute round, give users and workflow about eight minutes combined rather than twenty, so the structure pays for itself before the clock squeezes the MVP.

Four ways the walk goes off course

The most common failure is the one in the example: jumping to a technical solution before the users and workflow are clear. The tell is a noun like "classifier", "RAG", "dashboard" or "data lake" in the first two minutes. It costs points on end-user anchoring and on data reasoning, because the data was chosen before anyone knew who would use the output. The repair is cheap. If you hear yourself naming a technology, finish the sentence with "...but first, who would act on its output?"

The long unprioritised list fails differently. "We could do a parts forecast, a customer app, a technician copilot, route optimisation, inventory analytics..." Five ideas with no order read as no decision. The scoping line of the rubric rewards a sequence: this first, because of this number, then that. If you generate options, rank them by the money or time at stake (the $28,600 slice) and pick one.

Two quieter failures round out the set. One is walking all seven steps at equal depth; spend the time where the brief is ambiguous, which in the repair case was data. The other is never stating a baseline. "Success is fewer repeat visits" gives nobody a way to tell whether the pilot worked, while "down from 21.7 per 100 jobs" does.

A twenty-minute drill on a vet-clinic brief

Set a 20-minute timer and take a fresh fictional brief: a regional chain of 40 veterinary clinics says, "Our front desks are drowning in phone calls. We want an AI receptionist." Produce one page with seven labelled lines, one sentence per step, then a two-sentence close: the MVP, and the metric with where its baseline comes from. Underneath, write the first three questions you would put to the chain's operations lead, in order.

A good page names a specific user (front-desk staff at one clinic, or the pet owner calling) and a workflow that splits calls by type and picks one to attack first. Its data line names a source the chain plausibly has, such as phone-system logs with reason codes, or a week of manual tallies if no logs exist. Its MVP touches one call type at one clinic. If your MVP line says "AI receptionist", start again. Rehearse it aloud with the FDE AI coach in thita, or run it as an FDE mock round, and listen for whether you named each step as you entered it.

How this shows up in the interview

The decomposition round is where this gets scored. For Palantir, Aced's guide and other secondary write-ups describe a 60-minute whiteboard round with minimal code: a vague prompt worked into end user, data schema, APIs, an MVP in roughly one to two weeks, and iteration and metrics, with the interviewer injecting new constraints along the way. The rubric those sources report maps onto the table above: structured breakdown, end-user anchoring, data reasoning, scoping, success metrics. A Blind thread describes a prompt built on 8,000 London taxi rides with the goal "improve drivers' lives", asking for components, APIs and a deployable first cut in one week. Databricks reportedly runs a 60-minute decomposition round as well, per Aced, with prompts such as mapping raw client data to a pipeline and app that delivers a KPI.

Expect three probes. The interviewer withholds data until you ask for it, so "what does a closed job record hold?" is the question that surfaces the empty model field. They inject a constraint, like "no API access", to see whether you return to the right step. And they push on the MVP ("why not build the model now?"), which you answer with the baseline: the lookup is what any model has to beat. Credit goes to naming a user before a tool, putting one number from the data on the table, and closing with an MVP and a baselined metric. A sentence worth having ready: "Before I pick any tool, I want to know who acts on this and when, because that tells me what data even exists at that moment."

Check yourself

• Why is the dispatcher, and not the technician, the first user in the repair example? Answer: The dispatcher acts before the truck leaves, the only point where the missing part can still be loaded. The technician's diagnosis arrives too late for this decision.
• Mid-round the interviewer says the vendor won't give you API access. Which step do you return to, and what survives? Answer: Systems. Users, workflow and data still hold, and the MVP survives as a CSV export plus a spreadsheet lookup for one dispatch desk.
• Why build a lookup from past jobs before a classifier? Answer: It tests whether the history carries enough signal, takes days instead of weeks, and sets the baseline any later model must beat.
• With the example's numbers, what is the part-not-on-truck rate, and why state it aloud? Answer: 260 / 1,200, about 21.7 per 100 jobs. Without it there is no way to show the pilot moved anything.