The problem the client brings is rarely the real one: how FDEs clarify requirements before writing code

Imagine a client sends you a single line: “The team needs a tool that automatically reviews pull requests.” You can already see the solution: an agent that reads the diff, leaves comments and assigns a risk score. Three weeks later you demo it, the client says it looks great, and the time from opening a PR to merging it is exactly what it was before.

Learn Cursor’s FDE interview track opens with precisely this scenario. An engineer on the client side hands you a problem statement, and according to the track, it is almost never the real problem.

In that example, the bottleneck is not a lack of automation. Review takes four days because only two staff engineers are allowed to approve, and both are buried in work.

For a developer hoping to move into an FDE role, this is the skill that separates an FDE from someone who simply takes tickets. You already know how to write code. What you need to learn is how to turn a vague request into a plan that both the client and your teammates trust is heading in the right direction.

A request is only a hypothesis

The FDE discovery playbook published by Perspective AI in July 2026 starts from an assumption that sounds a little blunt: what the client asks for is not what the client needs. Not because clients lie. They describe the solution they can imagine, shaped by the tools they already know, rather than the place where the work is actually stuck.

So “we need automated PR review” is better read as “the client believes automated review will make everything faster”. That is a hypothesis, and your first job is to test it. If it holds, you build with more confidence. If it does not, you have just saved three weeks.

Which question overturns the brief?

The common mistake is to ask the client “what features do you want?” That only gets them to repeat the original request. The question Learn Cursor suggests goes in a different direction: ask the client to walk you through the most recent change they shipped, and to point out where it waited longest.

The question works because it pulls the conversation towards something that actually happened, with dates and real people. Here is a hypothetical exchange to show how it plays out:

FDE: Could you walk me through the last change your team shipped? Between opening the PR and reaching production, where did it sit waiting longest?

Client: Probably review. After a PR is opened it takes about four days before anyone approves it.

FDE: Who does the approving during those four days? What are they waiting on?

Client: Only two staff engineers can approve. They are also handling on-call and system design, so they always have a dozen PRs backed up.

At this point the brief has changed. An agent that posts automatic comments still leaves PRs sitting in the queue of those same two people. A more sensible plan might be to help those two review faster, or to make clear which kinds of change need them and which do not. But you should only choose after checking with the client.

Five phases, each with a clear sign it is done

One good question is not yet a method. Perspective AI’s playbook splits discovery into five sequential phases: Scope, Interview, Synthesize, Validate and Spec. Each has a condition that tells you when you can move on to the next.

Scope is done when you can draw a map of the people and systems involved on a single page. In the PR example, that page holds the people writing code, the two approvers, the CI system and the repository. The phase ends by naming the decision point: whom the system will help, to take what action. If you cannot say that sentence, you are not ready to interview.

Interview is where you use event-based questions like the ones above, with the people who actually do the work every day, not just the person who sent the request. Synthesize means grouping what you heard into opportunities and ranking them. A bottleneck that several people mention is usually more significant than a complaint raised by only one.

Validate is when you go back to the client’s domain experts to confirm that the opportunity at the top of the list really is the most valuable thing to build. Once you have a ranking in hand, you will be tempted to skip this step, which is exactly why you should keep it. Finally, Spec is judged by the “handoff test”: a teammate holding the spec must be able to build from it without any further meetings.

The mistakes that make discovery fail

The first and most common mistake is jumping straight to a solution. techinterview.org’s analysis of FDE interviews describes exactly this pattern: candidates hear the problem and rush straight into a solution. In real engagements, this becomes a polished demo that nobody uses.

The second is talking only to the person who made the request. The engineer who filed the ticket sees the symptom; the two approvers know why the queue is long. If your one-page map has only one name on it, you are almost certainly missing people.

The third is writing a spec that needs an extra meeting to explain it. If a teammate needs a meeting to understand the spec, the decisions are still in your head. Go back and check whether you have written down the decision point and why you chose this opportunity.

Interviews test exactly this skill

This is not just a skill you use after being hired. According to techinterview.org, Palantir’s decomposition round assesses the ability to break an ambiguous real-world challenge into smaller parts and then propose a solution. Strong candidates spend the first ten minutes asking questions.

So when you practise for interviews, train yourself to hold back the reflex to sketch an architecture right away. Ask who uses it, where work gets stuck and which decision is waiting, then talk through the map of people and systems out loud before proposing anything.

On your CV, instead of writing “built tool X”, write a line about a time you discovered the original request was wrong and how you changed course. A line like that shows exactly the skill the decomposition round scores.

Next time you receive a one-line request, don’t open your editor yet. Open a blank page. If you cannot yet draw who is waiting on whom on that page, you still don’t know what you need to build.