Cruxly › Forward deployed engineer › Running the Decomposition Round

Interrogating an Ambiguous Prompt

the questions you ask are the deliverable, not a prelude to it

You've been given a one- or two-sentence customer problem — "help our ops team catch fraudulent claims faster", "our field technicians can't find the right documentation on-site." It has no functional spec, no user count, no existing-system description. Your first job is not to solve it — it's to find out what's actually being asked.

Work through the sections, then use them as your live script for the first fifteen minutes of a real decomposition round.

Why the prompt is missing exactly what matters

The gap is deliberate. A customer describing their own problem, in their own words, almost never states the actual bottleneck — they state the symptom that's been visible to them for the longest. "Catch fraudulent claims faster" could mean the detection logic is bad, or that a good detection system exists but a human has to manually check every flag one at a time, or that flags exist but nobody owns following up on them. Those are three completely different systems to build, and the sentence doesn't distinguish them.

The candidates who fail this round treat the prompt as a spec. They pick the most obvious reading — usually "build a better detection model" — and start there, because it's the reading that lets them start designing something familiar. The candidates who pass treat the prompt as the opening line of a conversation they need to have before design starts.

A useful frame: ask what happens today, without you. Not "what do you want," but "walk me through what the analyst actually does right now, step by step, when a claim comes in." The gap between that walkthrough and where they wish they were is the real problem — and it is almost always narrower and more specific than the original sentence suggested.

The four questions that narrow almost any prompt

These are not a rigid script, but they cover the dimensions candidates most often skip:

• Who, specifically, does this today, and what's their actual workflow right now? Not a persona — the literal sequence of steps a real person follows, including the annoying manual parts.
• What does this system replace or sit next to? A greenfield build and an integration into a fifteen-year-old legacy system that nobody fully understands anymore are different jobs wearing the same prompt.
• What does success look like in a number, to them, not to you? "Faster" and "better" are not requirements. "Cuts review time from 20 minutes to 2" is. If they don't have a number, that itself is information — it means part of the job is helping them find one.
• What's the cost of a wrong answer here? A tool that mis-flags a claim for human review costs a few minutes. A tool that auto-denies one costs a customer relationship and possibly a lawsuit. The acceptable error mode changes which architecture is even in play.

:::key Why exactly four, not a longer checklist A real conversation has limited time, and a list of fifteen questions reads as a script, not curiosity. Four sharp questions, asked in response to what they actually say, cover the dimensions that most reshape the plan — workflow, integration surface, success metric, and error cost — without turning the round into an interrogation. :::

Turning answers into a scoped first slice

Once you have real answers, the job is to propose the smallest slice that produces a visible result for the actual bottleneck you found — not the smallest slice that's easy to build. If the walkthrough revealed that detection is fine but triage is the bottleneck, a beautifully engineered new detection model is a wrong-problem solution regardless of its accuracy.

State the slice as an observable outcome, the same discipline as scoping a system-design prompt: "First, I'd build a queue that ranks already-flagged claims by a simple risk score and puts them in front of the analyst in that order — no new detection logic yet. That alone should cut review time if triage ordering, not detection quality, is the actual bottleneck. If it doesn't move the number, that tells us the real problem is somewhere else, and we've spent a week finding that out instead of a quarter."

Say explicitly what you're deferring and why, the same "explicitly out of scope" move as a design interview — except here the reason is usually "because we don't yet know if it's needed," not "because there's no time." A forward-deployed engineer who ships a small thing that tests the actual hypothesis is doing the job; one who ships a large thing that assumes the hypothesis is guessing at customer expense.

How to say it in the interview

"Before I propose anything, I want to understand who does this job today and what breaks for them right now — a solution I propose without that is a guess wearing a diagram. Can I ask a few questions first?"

Checklist

• Spent the first third of the round only asking questions before proposing anything
• Asked what the actual workflow looks like today, not what the customer wants
• Asked what the system replaces or integrates with, not just what it does
• Pushed for a concrete success number instead of accepting 'faster' or 'better'
• Asked what a wrong answer costs before proposing an architecture
• Proposed the smallest slice that tests the real bottleneck, not the smallest slice that's easy to build
• Stated what was explicitly deferred and why, framed as 'we don't yet know if it's needed'