The decomposition round is the signature FDE round, widely considered the most important technical round. You're handed a vague, often non-software problem and asked to structure it end to end, usually with little or no code. It is graded on your process: how you handle ambiguity, how you break the problem into parts, and whether you think out loud. On this round the interviewer can only grade what you say, so keep thinking out loud. Going quiet to think reads as having nothing to show.
This is a performance skill, so it rewards reps. Below is a repeatable frame, then drills to run it on. Do them out loud, on a timer.
The mistake nearly everyone makes is skipping straight to move 5. Resist it. The interviewer is buying moves 1 through 4.
Drill 1 — a worked example
Prompt (illustrative, in the style this round is known for): "How would you design a technology to help an elderly person who lives alone stay on top of their daily medications?"
Before reading on: run the five moves out loud before you read the grade. Spend your first two minutes not proposing a product.
Bad / Good / Great — the opening two minutes
Bad — "I'd build an app that sends reminder notifications." You jumped to move 5 and picked a form factor in the first sentence. You've told the interviewer you solve the problem you were handed rather than the one underneath it, and you've thrown away every later decision's yardstick.
Good — you ask clarifying questions, then propose. "Are we assuming they have a smartphone? How many medications, and are any of them high-risk? Is the concern forgetting a dose, or taking a wrong or double dose?" This is real progress: you're gathering constraints before designing. But if the questions are a checklist you run before returning to your app idea, you're still designing a product, not decomposing a problem.
Great — you name the outcome and the hard part before any product. "The outcome isn't 'an app.' It's that this person takes the right medications at the right times without help and keeps their independence. Let me break that into the sub-problems: knowing what to take and when, actually remembering in the moment, and the safety failure: a missed critical dose or an accidental double-dose. The genuinely hard one is that safety failure, because the cost of a miss is a medical emergency rather than a clumsy interface. So I'd design around detecting and preventing that first, and let the refill reminders be the easy part." Now every later choice has a yardstick, and you've shown you spend your thinking on what's dangerous, not what's obvious.
The probe to expect
Interviewer: "You've spent three minutes and haven't proposed a solution. Can you give me something concrete?"
This probe is a test, not impatience. They want to see you commit after structuring instead of flailing. The recovery line:
You: "Yes. Here's the concrete first version: a dispenser that releases each dose on schedule, confirms it was actually taken, and escalates to a family member when a critical dose is missed or a double-dose is attempted, plus a simple refill alert. I led with structure because the safety sub-problem drives the whole design, and I wanted to commit to solving that well rather than to a nice reminder that misses a dangerous double-dose. Here's how I'd know it's working..."
You gave them a concrete answer and the reason you structured first.
Drill 2 — the FDE flavor
Prompt: "A regional hospital network wants to reduce the time nurses spend on documentation. They're thinking an AI scribe. How would you approach it?"
Before reading on: the prompt hands you a proposed solution ("an AI scribe") wrapped around a symptom ("time on documentation"). Run the frame. What's the outcome, and what's the hard part?
Bad / Good / Great — finding the real problem
Bad — design the scribe. "I'd use speech-to-text on the nurse-patient conversation, summarize into the chart fields, and let the nurse edit." Competent engineering aimed at the stated request. But you never asked what the hospital is measured on, so you can't tell whether faster documentation even helps them.
Good — scope the scribe carefully. You ask about EHR integration, accents, PHI handling, accuracy needs. Good instincts, real constraints, especially the compliance and integration questions. But you're still refining the scribe, not asking whether a scribe is the move.
Great — climb to the outcome, then find the hard part. "What's the hospital actually measured on here? Is it nurse burnout and retention, or billing accuracy, or throughput? Those are three different systems. If it's burnout, the win is fewer hours after shift, and the hard part is that a scribe the nurse has to correct line-by-line adds work instead of removing it. So the whole thing lives or dies on how trustworthy the output is at the moment of care. I'd design to measure correction rate first, because a scribe that gets edited every time is worse than no scribe." You reframed a feature request into a measurable outcome and named the failure that sinks most versions of this build.
The probe to expect
Interviewer: "The customer was clear they want a scribe. Aren't you overcomplicating it?"
You: "They might be exactly right, but a week confirming the scribe reduces after-shift hours is cheaper than three months building one that gets corrected so often it doesn't. If the data says the scribe wins, I build the scribe. I'm not saying no; I'm saying let's point it at the number they care about first."
Drill 3 — the non-obvious constraint
Prompt: "An industrial-equipment manufacturer wants an AI assistant that answers plant technicians' questions about machine-safety procedures, to cut the time they spend searching manuals."
Before reading on: who actually has the pain, and are they the same people who'd use a Q&A tool? Run move 1 hard before you design.
Bad / Good / Great — locating the pain
Bad — build the Q&A bot. Retrieval over the safety manuals, a chat box, done. It'll demo well. Whether it moves any number the company cares about is unknown, because you never asked.
Good — ask about the questions. "What do technicians ask most? How often do the procedures change?" You're curious about the work, which is right. But you're inside their framing, so you'll learn about questions without learning whether answering them is what matters.
Great — separate who asks from who errs. "The outcome is presumably fewer safety incidents, not 'faster manual searches.' Those come apart: the technician who stops to check the manual is careful already; the incidents trace to the veteran who's sure and never checks. A tool that waits to be asked gets used by exactly the wrong people. So the real problem might be that confidence and correctness have drifted apart, and the design has to meet the work where it happens, inside the job plan or the sign-off step, instead of waiting for a question. I'd confirm that by asking where the incidents actually come from before I build a chatbot." You found the constraint the prompt hid: the person the tool most needs to reach is the one who'd never open it.
The probe to expect
Interviewer: "That's a much bigger build than they asked for. How do you justify it?"
You: "I don't build the bigger thing on a hunch; I'd validate the incident-source claim in discovery first. But if it holds, the cheap version doesn't move their number, and it's better they hear that in week one than after we ship. If the incidents really do come from people searching manuals, the simple Q&A tool is the right call and I'll build it."
How to practice this
Run each drill on a five-minute timer, out loud, recording yourself. Grade against the frame: did you name the outcome before a feature, did you find and defend the hard part, and did you keep talking? The three drills above are worked examples, though. Once you have read their answers, they can only confirm that you recognize the moves. The Rep Kit below is where the unrehearsed reps come from. The underlying customer-craft move is taught in Discovery; this page is where you drill the interview-clock version of it.
Rep Kit
A drill whose grade is printed underneath it stops testing you after one reading. The kit below fixes that: twenty prompts with no answers anywhere on this site, and a protocol that turns an AI chat into the interviewer. Every rep is the same shape: one prompt, five minutes, out loud, then grade yourself against the frame at the top of this page.
The prompt bank
- A state court system wants a chatbot to answer filing questions from people representing themselves, because the clerks are overwhelmed.
- A dairy cooperative wants a mobile app that teaches its member farms best practices, because milk quality varies too much between farms.
- A city water utility wants smart meters on every home, because too many residents dispute their bills.
- A hospital group wants a scheduling algorithm, because operating rooms sit empty while surgeons say they can never get time in them.
- A school district wants a detector for AI-written essays, because teachers say they can no longer grade honestly.
- A grocery chain wants electronic shelf labels, because shelf prices keep disagreeing with register prices.
- A regional airline wants a rebooking app, because passengers mob the gate desk whenever a flight cancels.
- A prison system wants tablets so inmates can file grievances electronically, because paper grievances keep getting lost.
- A national park agency wants a trailhead reservation system, because the popular trails are being trampled.
- A furniture manufacturer wants cameras on the production line, because too many pieces arrive damaged and nobody can say where the damage happens.
- A public library system wants self-checkout kiosks, because it believes lines are discouraging visits.
- A midsize bank wants an internal knowledge chatbot, because new tellers take months to stop leaning on their supervisors.
- A fisheries regulator wants electronic catch logging, because paper logbooks arrive weeks late and full of errors.
- An electric utility wants drones to inspect its power lines, because wildfire liability keeps climbing.
- A food-bank network wants demand forecasting, because some pantries run out while others throw food away.
- A construction firm wants wearable sensors on its crews, because injury claims keep raising its insurance premiums.
- A university wants a dashboard that flags students likely to drop out, because retention has fallen.
- A veterinary chain wants an AI triage line, because every after-hours call lands on one exhausted on-call vet.
- A municipal transit agency wants a new journey-planning app, because ridership never recovered after remote work took hold.
- A rural vaccination program wants a cold-chain monitoring dashboard, because doses keep spoiling somewhere between depot and clinic.
There are no graded answers for these, here or anywhere else on the site. That is what makes them usable as tests. Grade each rep yourself, out loud, on a five-minute timer, against the frame: user and outcome named first, assumptions stated, the problem broken into parts, the hard part found and defended, a concrete proposal with its failure mode attached.
The AI interviewer
To rehearse against live resistance, paste the block below into any capable AI chat, unmodified, and follow it with a few prompts from the bank, or let it invent its own. Where the chat supports voice mode, use it; every one of these rounds is spoken.
You are the interviewer for a Forward Deployed Engineer decomposition round.
Persona: a senior engineer who has run this round many times. Neutral, brisk,
unimpressed by polish.
Rules:
1. Present exactly ONE prompt at a time. Wait for the list I paste after
this and pick from it (if none arrives, offer to invent one). Invented
prompts use the same register: a vague, often non-software problem,
framed as a solution ("we want an app / a dashboard / a chatbot"), handed
over by a stakeholder who is not the person in pain. Never repeat a prompt.
2. After presenting the prompt, say nothing more. I will answer out loud and give you the transcript —
voice mode or a recording's transcript, not a from-memory summary, which
hides exactly what you are grading. Typing in real time is fine; flag only
compressed retellings ("I covered assumptions and the hard part") and
grade those as thin evidence.
3. Interrupt like a real interviewer:
- If I propose a product in my first minute, ask once: "Who is this
for, and what are they measured on?" — then let me run.
- If I structure for a long time with nothing concrete, reply with only:
"You've been structuring a while. Can you give me something concrete?"
- When I name the hard part, probe it: why is it hard, what would I do
about it first, how would I know I was wrong?
- If I go vague or quiet, say: "Keep talking. I can only grade what you say."
4. Hold me to about five minutes per prompt — in text, treat roughly
seven hundred words of transcript as five minutes. If I run long, call
time and grade what I have.
5. When I say "grade me", mark each of five moves PASS or FAIL, citing a
specific moment from my answer for each: (a) did I name the user and the outcome before any
feature; (b) did I state assumptions and scope out loud and check them with you; (c) did I break the problem itself into three to five sub-problems —
parts of the problem, never phases of a build; (d) did I find and defend the genuinely hard part — the sub-problem
where a miss sinks the outcome, never generic plumbing; (e) did I propose something concrete and say how I would know it was
wrong — before you had to ask. Grade hard: a typical first rep fails at least two of these — if none failed, re-examine before praising, and never soften a grade because I argue with it.
6. End with exactly one thing to fix on the next rep. Then offer the next
prompt.Next: Client-Simulation Drills. The signal graded in every round: scope the ask, push back with a reason, and translate into the customer's terms.NextClient-Simulation Drills