Problem Decomposition
"A hospital wants to reduce readmissions. How would you help?" There's no spec, no schema and no right answer, and that's the point. The decomposition round tests whether you can turn a vague business wish into a plan a team could start on Monday. This page gives you one method and works it through six realistic prompts, from a weak answer that jumps to a model to a strong one that lands on a first deliverable and a number.
Learning objectives
- Explain how the decomposition round differs from a system-design interview, and what it's scored on.
- Apply a seven-step method — goal, users & decisions, data, constraints, options, first slice, metric — to any vague prompt.
- Ask clarifying questions that change the plan, not ones that just fill time.
- Land every answer on a first deliverable you could ship in two to four weeks, and the number that proves it worked.
30-second recap
- The FDE method: Work backward from the client's outcome, ship the thinnest end-to-end slice, and iterate in a tight feedback loop with real users.
- The system-design interview: Requirements, estimation, API, data model, architecture, then scale — and deep-dive the bottleneck your numbers expose.
1 · How the decomposition round works essential
This is the round where strong engineers most often fail, because it rewards the opposite of what they've practised. In a system-design interview the problem is defined — "design a URL shortener" — and you're judged on the architecture. In a decomposition round the problem is deliberately vague: "a retailer says its supply chain is a mess." The interviewer plays a stakeholder who knows their business but not the technology, and who answers only what you ask. Candidates who reach straight for a model ("I'd train a forecasting model") have answered a question nobody asked, and they usually never recover.
That's exactly what forward-deployed work looks like. Clients rarely arrive with a well-formed technical problem; they arrive with a pain point, a budget and some data they half understand. The FDE's first job is to find the specific decision the client is struggling to make, check whether the data to support it exists, and propose the smallest thing that would prove value — the same work-backward-from-the-outcome discipline the FDE method teaches. The interviewer is scoring four things: how you structure the problem, whether your questions actually change the plan, how you prioritise among many possible directions, and whether you land on a concrete first deliverable.
One method handles all of it. Start with the goal in business terms (fewer readmissions, not "a model"). Find the users and the decision they make — who would act differently, and when. Map the data: what exists, where it lives, who owns it. Name the constraints: privacy, regulation, legacy systems, budget, timeline. Lay out two or three options with honest tradeoffs. Pick the first slice you'd ship in two to four weeks. Close on the metric that would prove it worked. Say the steps out loud as you go; the stakeholder can follow you, and the interviewer can score you.
- Read left to right: each box is one step you say out loud, and each step narrows the problem.
- The blue boxes are understanding — what the client wants, who acts on it, what data and constraints exist, and which directions are possible.
- The amber "First slice" and green "Metric" boxes are commitment: one small deliverable and the number that proves it. Weak answers stop before these.
- The dashed loop back to the start is honest iteration: if your metric can't be measured with the data you found, the plan isn't finished yet.
In short: don't design until you know whose decision you're improving — and don't stop until you've named a first slice and a number.
2 · "A hospital wants to reduce readmissions" essential
The trap here is the obvious model. "Predict which patients will be readmitted" is the first idea everyone has, and a prediction on its own changes nothing. A risk score only reduces readmissions if someone does something different because of it — a follow-up call, a medication review, an earlier appointment — and if there's capacity to do it. The interviewer wants to see you find that intervention and the person who owns it before you talk about models at all.
- Goal. "Fewer patients back within 30 days" — but ask which ones: all causes, or specific conditions? Stakeholder: "Heart failure and COPD are our worst, and we're penalised on those." Now the scope is two conditions.
- Users & decisions. Who could act at discharge? "A small transitional-care team calls high-risk patients within 48 hours — but they can only call about 30 a day, and today they pick by gut feel." That's the decision: which 30 patients get a call.
- Data. Discharge summaries and diagnoses in the electronic health record, prior admissions, medication lists, and whether a follow-up appointment was booked. Ask who owns the data extract and how fresh it is at the moment of discharge.
- Constraints. Patient health data: strict privacy rules, data that stays in the hospital's environment, access logging, and clinical sign-off before anything changes care. Any score must be explainable to a nurse.
- Options. (a) A simple rule-based risk score built from a few known factors — fast and explainable. (b) A trained model on historical admissions — likely more accurate, but needs validation and governance. (c) An LLM that summarises each discharge note for the call team — helps the call, not the choice of who to call.
- First slice (3–4 weeks). Option (a) or a simple model, scored nightly on that day's heart-failure and COPD discharges, producing a ranked list of 30 for the call team, with the top three reasons shown for each patient. No change to clinical workflow beyond the order of the list.
- Metric. The 30-day readmission rate for called patients compared with a comparable group from before, plus how often the team agreed the list was sensible. Agree up front how long the comparison runs.
Why this lands: you found the real decision (who gets one of 30 calls), sized the slice to the team's capacity, respected clinical and privacy constraints, and named a measurable outcome. The model became the smallest part of the answer — which is usually how it is in practice.
Go deeper: work backward from the outcome · healthcare requirements · regulated-industry constraints
3 · "Our supply chain is a mess" intermediate
"A mess" could mean ten different problems, and the interviewer gave you nothing on purpose. They're testing whether you can narrow a sprawling domain to one painful, measurable problem without guessing. Stock-outs, overstock, late suppliers, wrong forecasts, warehouse errors — each has different data, different owners and a different fix. The worst move is to pick one silently and start designing. The best is to ask questions that rank the pain by cost.
- Goal. Ask what "mess" costs: "Where do you lose the most money — empty shelves, too much stock, or something else?" "Stock-outs on our top products. Customers go elsewhere." Goal: fewer lost sales from stock-outs.
- Users & decisions. Who decides how much to order, and how? "Twelve buyers, each with their own spreadsheet, ordering weekly." The decision: the weekly order quantity per product per store.
- Data. Point-of-sale history, current stock levels, open purchase orders, supplier lead times. Ask how reliable the stock figures are — if the system says 20 units and the shelf is empty, no forecast fixes that.
- Constraints. Buyers trust their own judgment; an inventory system that can't be changed this year; weekly ordering cycles; no budget for new infrastructure.
- Options. (a) Fix the inputs — reconcile stock figures and supplier lead times, often the hidden cause. (b) A suggested order quantity per product, shown next to the buyer's own number. (c) Full automated replenishment — the end state, not the start.
- First slice (3 weeks). For the top 200 products in five pilot stores, a weekly suggested order with a short reason ("sales up 30%, lead time 9 days"), delivered in the spreadsheet format buyers already use. Buyers keep the final say.
- Metric. Stock-out rate on those 200 products in pilot stores against comparable stores, and how often buyers accepted or adjusted the suggestion — a direct measure of trust.
Why this lands: you turned "a mess" into one costed problem with an owner, checked the data's reliability before trusting it, met the buyers inside their existing tool, and chose a comparison that would convince a sceptical COO. Asking "where do you lose the most money?" is the single most useful question in this round — practise asking it naturally.
Go deeper: the thin end-to-end slice · pilot to scale · talking ROI with executives
4 · "We want to use AI on claims" advanced
This prompt starts from a solution, not a problem. "Use AI on claims" is a strategy-slide phrase, and the risk is building something impressive that doesn't move a number the business cares about. The interviewer is testing whether you can redirect a solution-first request to an outcome, pick a part of the claims process where AI fits well and safely, and handle a regulated, high-stakes environment where wrong decisions affect customers.
- Goal. Redirect: "What would success look like in a year — faster claims, lower handling cost, less fraud, happier customers?" "Our cycle time is 14 days and complaints are rising." Goal: shorter cycle time without more errors.
- Users & decisions. Walk the process: intake → triage → document collection → assessment → decision → payment. Ask where the days go. "Most time is lost chasing missing documents and re-keying data from PDFs." The decision to support isn't approval — it's "is this claim complete, and what's missing?"
- Data. Claim forms, attached documents (PDFs, photos), policy terms, and historical claims with their outcomes and handling times.
- Constraints. Insurance regulation and fairness obligations, explainability for decisions affecting customers, personal data handling, an audit trail for every automated step, and a claims system that's hard to change.
- Options. (a) Document extraction and completeness checking at intake — low risk, high time saving. (b) Triage that routes simple claims to a fast lane for human handlers. (c) Decision support for assessors — later, with heavy evaluation. Automated denial: explicitly out of scope.
- First slice (4 weeks). For one claim type (say, home water damage), extract key fields from submitted documents and flag missing items at intake, so the customer is asked once on day one instead of three times over two weeks. A handler reviews every flag.
- Metric. Days from first notice to "claim complete" for that claim type, plus extraction accuracy on a labelled sample, and the rate of handler overrides.
Why this lands: you turned a vague mandate into a measurable outcome, found where time actually goes, picked the lowest-risk, highest-value step, and deliberately kept humans on the decisions that affect customers. Saying clearly what's out of scope — automated denial — is itself a strong signal in regulated industries.
Go deeper: document extraction · guardrails in regulated industries · agents vs workflows · AI governance
5 · "The city wants fewer potholes" advanced
The fixed budget is the important word. The department can't fix every road, so this is really a prioritisation problem: which repairs, in what order, give the most benefit for the money. The interviewer is checking whether you notice that, whether you look for data the city already has before proposing sensors or cameras, and whether your plan fits how a public-sector team actually works — slow procurement, public accountability, and decisions that must be defensible.
- Goal. Clarify the target: fewer potholes, fewer complaints, or fewer damage claims against the city? "Damage claims are costing us a lot, and complaints are political." Goal: reduce claims and complaints within the existing repair budget.
- Users & decisions. Who decides the repair schedule? "Two planners, weekly, mostly first-come-first-served from the complaint queue." The decision: this week's repair list.
- Data. Complaint records with locations, repair history, damage-claim records, road type and traffic volume, and weather. Much of this already exists in separate systems.
- Constraints. Fixed budget and crew size, public accountability (the order must be explainable), public-sector procurement timelines, and location data that should be handled carefully.
- Options. (a) A priority score per reported defect combining traffic, severity, past claims nearby and repeat complaints. (b) Preventive maintenance targeting roads that repeatedly fail, before potholes form. (c) New detection hardware — a later phase if gaps in reporting turn out to matter.
- First slice (3 weeks). Join existing complaints, claims and traffic data, and give the planners a weekly ranked repair list with the reason for each ranking, for one district.
- Metric. Damage claims and repeat complaints in the pilot district against similar districts, repairs completed per crew-week, and how often planners overrode the ranking.
Why this lands: you recognised a prioritisation problem hidden in a detection request, used data the city already owns, and kept every decision explainable to the public. It also shows restraint — new hardware is a phase-three idea, not a starting point.
Go deeper: work backward from the outcome · build, buy or do nothing · roadmaps for stakeholders
6 · "Our fraud team is overwhelmed" professional
The interesting fact is hidden in "drowning in alerts". The bank already has fraud detection — it's producing too many alerts for people to review. So the problem probably isn't catching fraud; it's the ratio of false alarms to real cases, and how quickly an analyst can clear each one. The interviewer is testing whether you spot that the bottleneck is human review capacity, and whether you understand the tradeoff between missing fraud and wasting analyst time.
- Goal. Ask for the numbers: "About 4,000 alerts a day, 40 analysts, and roughly 95% turn out to be false alarms. We miss our review deadline most days." Goal: review every alert in time without missing more fraud.
- Users & decisions. Each analyst decides, per alert, "fraud, not fraud, or escalate?" Ask how long one takes. "Eight minutes on average — most of it gathering context from four systems."
- Data. Historical alerts with analyst outcomes (labelled data, which is valuable), transaction history, customer profiles, and the existing rules that raised each alert.
- Constraints. Financial regulation, model governance and validation requirements, explainability for decisions, strict data security, and auditors who must be able to reconstruct every decision.
- Options. (a) Rank alerts so analysts see the most likely fraud first. (b) Assemble each alert's context automatically, so an analyst starts with one summary instead of four systems. (c) Auto-close only the lowest-risk alerts — highest saving, highest governance burden, a later phase.
- First slice (4 weeks). Option (b) for one alert type: a single screen with the transaction, recent history and a short generated summary of why the rule fired. It changes no decisions, so governance review is lighter. Run (a) in shadow mode alongside, to measure what ranking would have done.
- Metric. Minutes per alert and the share of alerts reviewed within the deadline; for the shadow ranking, how many confirmed fraud cases it placed in the top 10%.
Why this lands: you found that the constraint was analyst time, not detection, used the bank's labelled outcomes as an asset, and sequenced work from low governance risk (context assembly) to high (auto-closing). Running ranking in shadow mode first shows you know how to prove value in a regulated setting before changing anything.
Go deeper: triage and classification · audit trails · humans in the loop · evaluation
7 · "We want predictive maintenance" tech-lead
The tech-lead version tests scoping at scale. "Across all machines in eight plants" is a programme, not a project, and the CEO wants confidence it will pay off. The interviewer is looking for someone who can resist designing the whole programme upfront, pick where to start based on value and data readiness, and describe how the first win becomes a repeatable pattern — while being honest that predictive maintenance only works where failure data exists.
- Goal. Ask what downtime costs: "Unplanned stops on our packaging lines cost the most; one line down stops shipping." Goal: fewer unplanned stops on the machines whose failure is most expensive.
- Users & decisions. Maintenance planners decide what to service, and when, today on fixed schedules or after breakdowns.
- Data. Ask plant by plant: which machines already have sensors, how long data is kept, and whether failures are logged with dates and causes. Usually one or two plants are far ahead — that's where you start. A simple decomposition tree helps here:
- Which machines? Rank by cost of downtime × number of failures per year.
- Which have data? Sensor history plus a maintenance log with failure dates.
- Which failures are predictable? Ones with warning signs (vibration, temperature, current) before they happen.
- Constraints. Operational technology networks that can't be connected freely to the internet, plant safety rules, different systems at each plant, and planners who need to trust alerts before acting.
- Options. (a) Simple threshold and trend alerts on existing sensors — quick and explainable. (b) Anomaly detection learned from normal behaviour — useful where failures are rare. (c) Supervised failure prediction — only where there's enough labelled failure history.
- First slice (4 weeks). One machine type on one packaging line at the most data-ready plant: trend alerts on existing sensors, reviewed weekly with the planners. In parallel, document how data was collected and cleaned so the second plant is faster.
- Metric. Unplanned stops and minutes of downtime on the pilot line against its own history, the share of alerts planners found useful, and — for the CEO — the cost of downtime avoided. Then a written playbook so each next line is cheaper than the last.
Why this lands: you answered a company-wide ambition with a ranked, evidence-led starting point, were honest about where machine learning fits and where it doesn't, and turned the first win into a repeatable pattern — exactly how a tech lead gets a programme funded. Presenting it as "pilot, playbook, scale" also gives the CEO the plan they asked for.
Go deeper: scaling the FDE method · pilot to scale · unit economics · total cost of ownership
🪜 Practice ladder beginner → industry
- Beginner: for §2 (readmissions), write the seven method steps as one line each from memory.
- Easy: for §3 (supply chain), write five clarifying questions, and mark which ones would change your plan depending on the answer.
- Core: pick a vague prompt of your own ("a university wants fewer dropouts") and work all seven steps in 15 minutes, out loud.
- Stretch: for §5 (fraud), write a one-paragraph note to the bank's model-risk team explaining why the first slice needs only light governance review.
- Hard: run a mock with a friend playing a stakeholder who gives short, vague answers. Practise getting to a first slice in under 20 minutes.
- Industry: take a real request from your work and write a one-page decomposition: goal, decision, data, constraints, options, first slice, metric.
✓ Checkpoint — you can move on when you can…
- Explain how the decomposition round differs from a system-design interview.
- Apply goal → users & decisions → data → constraints → options → first slice → metric without notes.
- Find the specific decision behind a vague request, and the person who makes it.
- Propose a first deliverable that fits two to four weeks, and the number that would prove it worked.
- Say clearly what's out of scope, especially in regulated domains.
Knowledge check check yourself
In a decomposition round, why is "who makes which decision, and what would they do differently?" usually the most important early question?
Show answer
What makes a good "first slice" in a decomposition answer?