Every company building AI products has discovered the same thing: the hardest part is not the model, it is the last mile at the customer. That is why Forward Deployed Engineer programs are growing so fast — and why so many of them struggle to pick the right people.
Most programs choose FDEs the way they choose developers: a résumé screen and a coding round. That finds people who can write code. It does not find people who can sit with a confused operations head, work out what they actually need, build it by Friday and explain why it was built that way.
What an FDE actually does
Across the companies that run these programs, the role keeps coming back to five capabilities.
- 1
Customer problem framing. Turns a messy business problem into a clear technical scope.
- 2
Hands-on engineering. Writes working code fast — integrations, data, APIs — on real systems.
- 3
Technical breadth. Knows enough cloud, data, security and AI to make sound calls alone.
- 4
Communication. Explains trade-offs to an engineer and to an executive, in their language.
- 5
Ownership under ambiguity. Prioritises, decides and ships without a complete spec.
Good developer, or FDE-ready?
Arjun
Top coding score · 6 years
Solves the task cleanly. Given a vague customer brief, he waits for a spec. Asked to explain his design, he lists technologies instead of outcomes.
Meera
Good coding score · 3 years
Asks two sharp questions, scopes a smaller first release and ships working code. She explains the trade-off in a minute, in the customer’s words.
A coding round picks Arjun. A customer would pick Meera. The difference is invisible unless the assessment looks for it.
“An FDE is judged twice — once by the code, once by the customer.”
One assessment, three lenses — and a voice
AlphaRecrewt’s FDE Readiness Check is a single sitting with three sections, plus speech analysis running across it.
Case study. A realistic customer brief. The candidate scopes it, picks an approach and defends the trade-offs in writing.
MCQs. Fast checks of breadth across cloud, data, APIs, security and AI — the ground an FDE must cover alone.
Coding. A time-boxed, practical task: integrate, transform, fix. Working code, not puzzles.
Speech analysis. The candidate explains their solution out loud. We measure clarity, structure, confidence and how well they pitch it to a customer.
Why no single score is enough
Each section proves different capabilities. Readiness means consistent evidence across all of them — a brilliant coder who cannot explain, or a great talker who cannot build, is not yet an FDE.
| Capability | Case study | MCQs | Coding | Speech |
|---|---|---|---|---|
| Customer problem framing | ● | ○ | ||
| Hands-on engineering | ○ | ● | ||
| Technical breadth | ○ | ● | ○ | |
| Communication | ○ | ● | ||
| Ownership under ambiguity | ● | ○ | ○ |
Exhibit 1 · Sample FDE readiness report
Verdict
Almost ready
Case study
80
MCQs
71
Coding
76
Speech
58
Focus before deployment
- Lead with the customer outcome
- Structure explanations: problem → choice → trade-off
Five FDE capabilities
Readiness bar: 70 in every capability
Speech analysis
64
Clarity
52
Structure
70
Confidence
48
Customer framing
Ready
Every capability at or above the bar. Deploy to a customer.
Almost ready
One or two clear gaps, with named focus areas.
Not yet
Core gaps in building or framing. Build these first.
Where teams use it
- FDE program intake. Choose the cohort on evidence, not résumés.
- Internal mobility. Find the developers already ready to move closer to customers.
- Bootcamp and campus graduation. A clear bar that says “ready to deploy”.
- Before a customer engagement. Confirm the person you send can carry the room.
One question to close on: of the engineers you would send to your most important customer tomorrow, how many have you actually seen explain their work? ■
Talk to sales →