“Why do you want to be an FDE?”: building a 60-second answer for the recruiter screen

When a recruiter asks “why do you want to be an FDE?”, the answer that comes most easily is that you like talking to customers and like building AI. GoodSpace’s set of FDE interview questions files exactly this under weak answers. It romanticises the role rather than showing you understand the real work.

There is nothing wrong with the attitude. The problem is that this call is not a formality. According to Scaler’s analysis of the mistakes that sink FDE candidates, the recruiter screen in an FDE process is a real round. The recruiter is filtering for one specific signal: can this person build, and can this person talk to customers?

So the 60 seconds you spend on “why” are the first place you can prove both. The steps below help you build that answer before the call.

What you will build, and what you need

The end product is a spoken answer of about 60 seconds in four parts, in this order: motivation tied to the job itself, a trade-off stated plainly, proof from work you have done, and a “why now”. You do not need to memorise it word for word, only to have the four points down firmly.

Prepare four things: a real FDE job posting from a company you are targeting, two or three past projects whose details you remember well, a stopwatch and a voice-recording app. Have an empty text file open.

Step 1: Read the job posting like a spec

Do not start from your feelings. Start from what the company has written. OpenAI’s FDE posting, for example, says you will work closely alongside customers, in places where model performance really matters.

There, delivery is always urgent and ambiguity is the default. The same posting asks for up to 50% travel.

Copy these three lines into your file, using only material from the posting:

Context:      working closely alongside customers, urgent delivery, ambiguity is the default
Trade-off:    up to 50% travel
Expectation:  send field feedback to Research and Product

The third line also comes from OpenAI’s posting: FDEs must share field feedback so the Research and Product teams understand where the models are doing well and where they need to improve.

Check: every line must point back to a sentence in the posting. Delete any line you made up.

Step 2: Choose a trade-off you genuinely accept

This is the part that separates a good answer from a romantic one. According to GoodSpace, a good answer spells out the cost compared with being a product engineer: you give up deep ownership of one codebase and a predictable roadmap.

There are other trade-offs to choose from. FDE Academy writes that engineers usually go deep on one system, whereas FDEs develop breadth across many systems and industries. It also warns that the work can be stressful for people who do not enjoy meetings or communication. If the posting says up to 50% travel, that is a trade-off too.

Pick only one, and write it in two halves: what you lose, and why you still want it.

What I lose:        no deep ownership of one codebase, no stable roadmap
Why I still choose: [reason tied to work I have done]

Check: if you cannot say what you lose, you have not really chosen. Admitting to a weakness such as “too dedicated to customers” is not a trade-off. It is a compliment in disguise.

Step 3: Dig proof out of your own history

GoodSpace advises proving motivation with your work history, not with adjectives. Scaler sets an even clearer bar: if you cannot tell a story involving a non-technical stakeholder, you have not demonstrated the core skill.

The reason lies in the nature of the job. According to Scaler, FDEs do not build for one user but for an entire customer organisation with many stakeholders. So your best story should involve at least one person who does not write code, and a result that person received.

Picture a backend engineer at a logistics company. The head of operations complains that the late-delivery report is wrong every day. He does not just fix the query: he sits with her for a session to understand what “late” means to the dispatchers, then rewrites the definition and puts it into the dashboard. That story has both building and working with real users.

Compress your story into a three-line frame:

Who (non-technical): ...
What I built/changed: ...
Result for them + what I brought back to the product team: ...

The last part is optional but well worth having. It matches the field-feedback requirement in OpenAI’s posting: you have turned a user-side problem into a change in the product.

Check: count the self-describing adjectives in the frame, such as “passionate”, “enthusiastic”, “great communicator”. The target is zero.

Step 4: Close with “why now”

The last part needs only one sentence. GoodSpace suggests ending with the observation that the 2025-26 wave puts FDEs exactly where model capability meets enterprise reality. Say it in your own words and connect it to your story from Step 3, so it does not turn into a slogan.

Step 5: Assemble, time, cut

Put the four parts together. The draft below is a hypothetical, simplified example based on the logistics story above. It is written as notes, with subjects dropped; when you speak, use your own natural voice:

Past two years, the most meaningful part of the work was sitting with the
operations team to fix the late-delivery report: learning what "late"
meant to the dispatchers, then rewriting the logic and the dashboard. FDE
is the role that makes that kind of work the main job. The cost is clear:
no deep ownership of one codebase, an unpredictable roadmap, possibly a
lot of travel. Still choosing it, because learning is fastest when standing
between a system and the people who use it. Right now FDE is where model
capability meets enterprise reality, and that is exactly where this kind
of experience is most useful.

Read it aloud and time it. If it runs much past 60 seconds, cut the opening first, since it is usually the longest part with the least proof. Record it and listen back as if you were the recruiter.

Check: after listening, you must be able to answer three questions. What does this person give up? Who that does not write code has this person worked with? What did this person build? If any is missing, go back to the relevant step.

Mistakes that make an answer sound like you have never done the work

The most common mistake is falling back on the romantic line: love customers, love AI. A subtler one is a proof story that is purely technical, such as cutting latency or migrating a database, with not a single real user in it. By Scaler’s bar, a story like that does not demonstrate the core skill.

Another mistake is stating the trade-off as a complaint. Go on about being tired of working on the same codebase and the recruiter will hear someone running away, not someone who has made a choice. State the loss in a neutral tone and spend more time on why you accept it.

How this skill shows up on the customer site

This 60-second answer is a miniature of the real job. Working closely alongside customers, where ambiguity is the default, you will often have to explain a trade-off very briefly to a non-technical person: what you lose by going fast, which path you give up by choosing this one.

The structure is the same: state the cost, give the proof, then give the reason.

So reuse the three-line frame from Step 3 for your CV. A good bullet point in an FDE résumé should name the stakeholder’s role, such as head of operations or chief accountant, along with what you built and the result they received.

When reading job postings, look for phrases such as “embed with customers” or “field feedback”. That is where your proof belongs.

The recruiter does not need you to love the FDE job. They need to hear, once and briefly, that you were already doing it before it had a name.