Lesson 2 of 6 · 48 min

Decomposing vague problems

Turning an ambiguous customer problem into sequenced, shippable pieces. MECE issue trees, the data-availability bar, risk-first sequencing, the 5-step Exponent framework, and the walking-skeleton MVP that proves the data-and-integration story in two weeks.

The skill the 60-minute case actually tests

Palantir’s canonical case is one sentence and a stopwatch: “A major city wants to reduce 911 emergency response times. They have call data, traffic data, and ambulance GPS data. You have 60 minutes. Go.” The test is not whether you can architect the system — it is whether you can decompose an ambiguous problem into a sequenced, shippable plan under time pressure, scored on “logic/structure and communication.” Decomposition is a 5-step exercise, not a 6-hour one, and the order is non-negotiable.

The senior failure mode is a flat work plan — a list of tasks with no structure, no risk ordering, and no thin end-to-end slice — which guarantees a surprise mid-build. The frameworks that fix it come from consulting (MECE issue trees, hypothesis-driven decomposition) and from FDE practice (risk-first sequencing, the walking-skeleton MVP). They are not five separate toolkits; they are stages of one move: frame the problem, split it so the pieces don’t overlap and together cover it, sort what you can measure from what you can’t, sequence by risk, and ship a skeleton that proves the riskiest assumption first.

Interview angle. Anthropic explicitly fails anyone who skips discovery and starts architecting; Palantir explicitly times the scoping at 60 minutes. Read together, the message is that decomposition is scored in absolute time, not as an afterthought — “first 30% questions, last 70% design.” The strong candidate narrates the structure out loud: “here are the three workstreams, here’s why I’d sequence them this way, and here’s the thinnest thing I’d ship in week two to de-risk the whole plan.”

MECE issue trees: split without gaps or overlaps

The McKinsey/BCG inheritance is the MECE issue tree — Mutually Exclusive (nodes don’t overlap) and Collectively Exhaustive (together they cover the whole problem). You write the customer’s stated goal at the top of a one-pager, then decompose into candidate drivers beneath it, forcing each level to be MECE. For “reduce 911 response time,” a clean first split might be: time-to-dispatch (call handling), time-in-transit (routing/traffic), and unit availability (where ambulances are staged) — three non-overlapping buckets that together cover the clock from ring to arrival.

The hypothesis-driven variant (Career-in-Consulting) adds force-ranking: don’t analyze every branch equally — rank them by likely impact and data availability, and start where signal is cheapest. The FDE-specific move is to draw a vertical bar through the tree separating “things we can measure today” from “things we cannot.” Everything below the bar becomes a discovery task before it becomes a build task. This single line is what stops a team from architecting a routing model around traffic data that turns out to be 24 hours stale.

code

1ISSUE TREE + THE DATA-AVAILABILITY BAR  (911 response-time example)23  GOAL: cut median 911 response time (ring -> on-scene)4  |5  |-- time-to-dispatch ........ call-handling steps, triage delay6  |-- time-in-transit ......... route choice, traffic, signal preemption7  |-- unit availability ....... staging locations, concurrent-call load8  ----------------------------- DATA-AVAILABILITY BAR -------------------9        ABOVE: GPS traces + dispatch logs exist & fresh -> can MEASURE now10        BELOW: real-time traffic feed ownership unknown   -> DISCOVERY task1112  Rule: anything below the bar is a discovery task, NOT a build task.13        MECE = the three branches don't overlap and together cover the clock.

The 5-step FDE decomposition framework

Exponent’s guide gives the verbatim pattern senior FDEs run, and the order matters because each step de-risks the next. Memorize it as a sequence you narrate, not a checklist you hide:

011. Clarify the goal — “are we optimizing response time, cost, equity of coverage, or something else?” Pick one primary objective and say it out loud.
022. Identify success metrics — “who would consider this a success, and which metric moves?” This is the spec; without it the rest is guesswork.
033. Map the inputs — “what data is available, what shape, who owns it, what’s the freshness?” The data-availability bar lives here.
044. Split into subproblems, sequenced by RISK — “I see three workstreams: data ingestion/quality, the model itself, the operator-facing tool — I’d sequence them so the highest-risk goes first.”
055. Ship a walking-skeleton MVP — “in the first two weeks, the thinnest possible version end-to-end with mocked logic, just to prove the data-and-integration story.”

The non-obvious senior insight is in step 4: data-ingestion risk is pre-model risk. The instinct is to sequence by what’s exciting (the routing model), but the thing most likely to kill the project is usually upstream — the feed nobody owns, the schema that drifts, the records that arrive 24 hours late. So you sequence the riskiest workstream first, and in most real engagements that is data quality and integration, not the model. “I’d sequence data ingestion first because it’s the highest risk” is the line that signals you’ve shipped one of these, not just read about it.

The walking-skeleton MVP: prove the story, not the model

A walking skeleton is the thinnest possible version that runs end-to-end — every stage connected, but the hard parts mocked. Exponent’s phrasing: ship “the thinnest possible version end-to-end with mocked routing logic, just to prove the data and integration story. Once that’s stable, I’d swap in the real model.” For the 911 case, that means: ingest one day of real GPS + dispatch data, pass it through a hardcoded routing rule, render one recommendation in a screen the dispatcher can see — in week two. It proves the pipes work and the integration is real before you spend a month on the model.

This is the direct antidote to the slide-deck POC. The DEV playbook orders the first sprint as “evaluation pipeline + walking skeleton + sequencing memo — in that order,” and is blunt that “a POC built before the eval harness is de facto scrap.” The reason: a demo with no eval and no real integration tells you nothing about whether the system works on the customer’s actual distribution; it just looks good in a meeting. The walking skeleton is the opposite — ugly, mocked, but real end-to-end on real data.

code

1WALKING SKELETON vs SLIDE-DECK POC  (what you ship in week two)23                       Slide-deck POC          Walking skeleton4  data                 synthetic / cherry-picked real, 1-day slice5  integration          faked screenshots         actually wired end-to-end6  hard part (model)    fully built, untested      MOCKED (hardcoded rule)7  eval harness         none                       thin labelled set first8  what it proves       "looks impressive"         "the pipes + data are real"9  failure it hides     integration & data gaps    (surfaces them immediately)1011  Order the first sprint: eval pipeline -> walking skeleton -> sequencing memo.12  A POC built before the eval harness is de-facto scrap.

The Future of Forward Deployed Engineering (OpenAI · Ramp · Nominal panel)SPC

Sequence by risk: prove the brick walls first

The Pragmatic Engineer framing of the FDE instinct is a “bias for moving fast, proving out any brick walls and then adjusting the scope to the most useful thing we can do, given any insurmountable constraints.” Decomposition is how you find the brick walls cheaply. You sequence the workstreams so the one most likely to be impossible — the unowned data feed, the latency budget, the compliance boundary — gets a thin probe first. If it’s a wall, you learn in week one and re-scope to the most useful achievable thing; if it’s passable, you’ve de-risked the rest.

Ramp’s builders add the productization lens that should shadow every decomposition: as you split the problem, ask of each piece “hack something together for a customer, or build something hundreds or thousands of customers will use?” Their default is the latter — “prioritize building general features, interfaces, and platforms over ad-hoc customizations, which we believe pollute the codebase.” So a good decomposition tags each subproblem as bespoke-now vs generalizable, which feeds the productization loop you’ll formalize later. Interview angle. “How do you turn a vague problem into a shippable solution?” → clarify goal and metric, map inputs and draw the data bar, split into MECE workstreams sequenced by risk, ship a mocked walking skeleton in two weeks, tag what should generalize.

Communicating the decomposition: structure is the signal

A decomposition is only as good as your ability to make it legible to the customer in two minutes. The same Pyramid-Principle discipline you’ll use for exec tradeoffs applies here: lead with the answer (“three workstreams, sequenced by risk”), then the supporting structure, never a bottom-up narration of every consideration. Anthropic’s case-round rubric grades exactly this — clarity and structure — and the difference between a strong and weak decomposition is almost never the content; it’s whether the interviewer can see the tree. Write the goal, draw three branches, mark the data bar, name the risky-first sequence, and point at the skeleton.

The 60-minute case isn’t a test of whether you can build the system — it’s a test of whether you can structure the unknown. A flat task list fails; a MECE tree sorted by data availability and risk, with a mocked walking skeleton as the first slice, passes.

articleIssue Tree — the case-interview canon (MECE, hypothesis-driven structuring)Victor Cheng · Caseinterview articleHypothesis-driven approach: the definitive guide (force-ranking drivers)Career in Consulting articleForward Deployed Engineering (the “always be scoping” / generalize-our-work playbook)Ramp Builders

Checkpoint

You have 60 minutes on the 911 case. After clarifying the goal and metric, you list three workstreams: data ingestion/quality, the routing model, and the dispatcher UI. How should you sequence them?

ARouting model first — it’s the core intellectual work and everything else supports itBDispatcher UI first — it’s what the customer sees, so it builds confidenceCData ingestion/quality first — it’s the highest-risk, pre-model workstream; prove the feed exists, is owned, and is fresh before building on it

Checkpoint

A teammate proposes spending the first three weeks building a polished, fully-featured routing model to demo to the customer. What’s the senior counter?

AShip a walking skeleton in week two instead: real data, real integration end-to-end, model mocked — prove the data-and-integration story before investing in the modelBAgree, but add more features so the demo is even more impressiveCSkip the demo entirely and build the full production system first

Checkpoint

While decomposing, you realize one branch depends on a real-time traffic feed whose owner and freshness are unknown. Where does that branch belong in your plan?

AIt stays a build task — assume the feed exists and start integrating it nowBBelow the data-availability bar — it becomes a discovery task to resolve ownership and freshness before any build depends on itCDrop the branch — if the data is uncertain, the whole workstream isn’t worth pursuing

Checkpoint

An interviewer gives you a one-line vague problem and 45 minutes. Your answer is graded on “logic/structure and communication.” What most distinguishes a strong response?

ANaming as many possible solution technologies as you can to show breadthBA precise final architecture diagram delivered in the first ten minutesCA MECE breakdown you narrate out loud — goal and metric, non-overlapping workstreams sequenced by risk, a data-availability bar, and a mocked walking-skeleton first slice

Checkpoint

As you split a customer problem into subproblems, you notice one piece would clearly recur across many future customers while another is truly one-off. What’s the senior habit?

ABuild both as bespoke customizations — generalization is the product team’s job, not yoursBTag each subproblem as bespoke-now vs generalizable, defaulting toward general interfaces, so the recurring piece feeds the productization loopCIgnore the distinction during decomposition — worry about reuse only after the engagement ends

Interview prep

Decomposition is the most heavily-weighted FDE case skill — Palantir times it at 60 minutes, Anthropic runs a dedicated decomposition round, and the startup question bank opens with “walk me through how you turn a vague problem into a shippable solution.” You’re graded on logic, structure, and communication, not on reaching a final architecture. The winning shape is always the same: clarify, frame MECE, sort by data availability, sequence by risk, ship a mocked walking skeleton, and narrate the structure so the interviewer can see the tree.

01“Turn this vague problem into a plan” → clarify goal/metric → MECE workstreams → data-availability bar → sequence by risk → mocked walking-skeleton MVP in two weeks.
02“How do you split the work?” → MECE (no overlaps, covers the whole goal), then force-rank branches by impact and data availability — analyze the cheap-signal ones first.
03“What do you build first?” → the thinnest end-to-end slice on real data with the hard part mocked — to prove the data-and-integration story before the model.
04“Why that sequence?” → highest-risk-first; data-ingestion risk is pre-model risk, so the unowned/stale feed gets probed before the model is built.
05“When do you ship a quick PoC vs a production build?” → walking skeleton to learn fast, then invest once the riskiest assumption holds; never a polished PoC before the eval harness.
06“What if a brick wall is real?” → re-scope to “the most useful thing we can do given the constraint” (Pragmatic Engineer) — prove the wall cheaply, then adjust.
07“How do you avoid a mid-build surprise?” → the data-availability bar turns unknowns into discovery tasks before any build depends on them.
08“How does this feed product?” → tag each subproblem bespoke-now vs generalizable so recurring pieces become product changes, not one-offs.

Going deeper, the probes that test depth: “what if the data is more than 24 hours stale?” (update your assumptions live and move the affected branch below the data bar — re-sequence, don’t hand-wave); “then what — what would you ship in 48 hours?” (always have the next concrete slice ready: the mocked skeleton, or the single happy-path query); and “you’re running out of time, what do you cut?” (cut scope to the highest-risk, highest-value workstream and say so — the FDE adjusts scope to the most useful achievable thing). Move from diagnosis to a concrete next step in one breath; that fluency is the senior tell.

Given a one-line vague problem and a stopwatch, could you produce a MECE, risk-sequenced decomposition with a data-availability bar and a mocked walking-skeleton first slice — and narrate it clearly?

New to itGetting thereConfident

Takeaways

Decomposition is a 5-step sequence: clarify goal → success metric → map inputs → split MECE by risk → walking-skeleton MVP.
MECE issue tree = non-overlapping branches that together cover the goal; force-rank by impact and data availability.
Draw a data-availability bar; anything you can’t measure today becomes a discovery task, not a build task.
Sequence by risk — data-ingestion risk is pre-model risk, so the unowned/stale feed gets probed first.
Ship a walking skeleton in two weeks: real data, real integration, model mocked — a PoC before the eval harness is scrap.
Tag each subproblem bespoke-now vs generalizable so recurring work feeds the productization loop.

Next: defining success — turning “it works” into a customer-verifiable metric and a credible first-90-days plan.

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with Enzo Sign up free