Practising the decomposition round: turning a client's vague goal into a system in 45 minutes

You are given a large, vague problem drawn from real life, with no scope set in advance. That is how an interview-preparation guide on aced.io (previously published on Exponent) describes the decomposition round. The prompt is deliberately short on information, has no single right answer, and you usually have only 45-60 minutes.

For a Forward Deployed Engineer, this is not a puzzle that exists only in interview rooms. Cursor’s FDE job ad asks candidates to lead discovery with the client’s engineers to find the real bottleneck and set clear success metrics. UKG describes the FDE’s job as turning ambiguous customer needs into hypotheses, prototypes and technical designs.

Practising this round therefore means practising the job itself. This guide shows how to run a 45-minute session on your own, walks through a sample prompt and tells you what to check after each step.

What do you need before you start the clock?

Nothing to install. You need a 45-minute countdown timer, a blank sheet of paper or text file, and a way to record your voice (a phone is enough). A friend playing the client is even better: they only need to answer questions, not understand the technology.

Recording is mandatory for a specific reason. The aced.io guide stresses that interviewers read silence while you think as being stuck. You have to think out loud, and the only way to know whether you did is to listen back.

The sample prompt used throughout, entirely hypothetical: an insurance company says “we want to use AI to process claims faster”. The sentence has all three traits of a decomposition prompt: it is large, vague and unscoped.

Use the diagram at the top of the article to pace yourself. The minute splits in it are a practice suggestion, not a rule of any particular interview.

Steps 1-2: why ask before you draw?

The most common mistake in this round, according to aced.io, is jumping straight to a solution. With the insurance prompt, the wrong reflex is to say at once “I’ll use an LLM to read the claims”. You do not yet know where claims slow down.

Step 1 is asking questions that expose the real problem, exactly as UKG’s job ad describes: ask to see the problem, not just to hear the features the client wants. Ask: how long does a claim take now from submission to decision? Where in the process does that time go? Who is waiting, the end customer or the claims assessor?

Suppose the “client” answers that most of the time goes on staff reading attached documents by hand. That is the real bottleneck, and it is far narrower than “use AI for claims”.

Step 2 settles how success is measured and what the constraints are. A sensible metric is the time from submission to decision. Constraints might be: a human still makes the final approval, and medical or financial data must not leave the client’s systems.

Check after step 2: can you write one sentence of the form “success means metric X falls while constraint Y still holds”? If not, do not move on to step 3.

Steps 3-4: decompose along the data flow, not the technology

Step 3 is mapping the inputs. For the sample prompt, list them out loud: the form the customer fills in, photos of receipts, PDF documents, policy history, the payout rules. For each one, ask where it lives and what format it is in.

This map determines how you split the problem in the next step. Step 4 is where you break it into sub-problems.

One split that is easy to present follows the path of a single claim: intake and classification, extracting information from documents, checking against policy rules, queuing for a human reviewer, and measuring time at each stage.

Splitting along the data flow beats splitting by technology (“the LLM part, the database part”). Each block has a clear input and output, so you can say which block addresses the bottleneck found in step 1, here the extraction block.

Check after step 4: does each sub-problem have a one-sentence description of its input and output? Is there any block that does not connect to the metric from step 2? A block that does not connect is a candidate to cut from scope.

Steps 5-6: get it running end to end, then go deep

Step 5 sketches the whole end-to-end path first, roughly, and only then picks one block to explore in depth. This is also the rhythm Cursor expects of its FDEs: ship a first version fast, within days, then harden it into something reliable over weeks.

In the sample prompt, the block worth going deep on is extraction, because it is both the bottleneck and the riskiest part. Say out loud: which documents are easy to extract, which are blurry or handwritten, and where does a claim go when extraction is wrong? The natural answer is back to the human review queue, which fits the constraint from step 2.

Step 6 sets out the trade-offs and iterates. For example: more automation is faster but raises the risk of wrong approvals; keeping a human for the final approval is safer but moves the metric less. UKG describes exactly this loop on client sites: prototype quickly, then test assumptions with the customer.

Check after step 6: have you stated at least one assumption the client needs to confirm, and what you would do next with one more week?

Four mistakes you will hear when you play back the recording

The first is proposing a solution before minute seven. If the recording contains “I’ll use…” before you have asked where the bottleneck is, that is the mistake aced.io calls the most common.

The second is long silences. The interviewer will take them as being stuck, even when your mind is racing. Practise speaking half-formed thoughts: “I’m weighing two ways to split this…”.

The third is going deep too early, before the end-to-end path is connected, and running out of time with one perfect block and four empty ones. The fourth is a vague metric such as “happier customers” that cannot be measured by step 6.

How does this skill show up on client sites and on your CV?

On a client site, this framework is the first week of an engagement. “We want AI to do X” is almost always a requested feature, and your job is to trace the bottleneck behind it before writing a line of code.

When you read job ads, look for phrases such as “ambiguous customer needs”, “discovery”, “success metrics”, “ship a fast first version”. They show that breaking down vague goals sits at the core of the role, so it is worth preparing concrete examples for both the interview and your first week with a client.

On your CV, do not just write “built a document processing pipeline”. Follow the framework’s sequence: how vague the original request was, which bottleneck you found, which metric you set, how soon the first version shipped, and what you hardened afterwards. Written that way, a recruiter can see that you have taken a real client through each step of the framework.

Practise three prompts in three sessions, 45 minutes each, listening back every time. By the third, clarifying questions will come before solutions without you having to remind yourself.