What should you look for when hiring Forward-Deployed Engineers?

Screen for three signals: ships fast (speed to a working solution under real constraints), customer empathy (reads the stakeholder's actual concern and explains without jargon), and owns ambiguity (proposes a path instead of waiting for instructions). Resume pedigree predicts all three poorly. The loop that surfaces them is a breadth-first take-home, a client role-play, and a direct fundamentals check — not algorithm puzzles.

That's the whole post in one paragraph. The rest is how to run it, the red flags, and two candidates from real loops that show why the standard SWE filter fails here.

Why your normal loop misfires for FDEs

A Forward-Deployed Engineer works inside the customer's environment, alone, with the client watching. The failure mode that kills accounts isn't bad code — it's a misread client. One misunderstanding left unaddressed can undo months of engineering work. Your standard loop tests none of that: LeetCode measures algorithmic depth the field job never uses, and system-design rounds reward the over-architecting instinct you specifically don't want in a validation-stage deployment.

So the question to design the loop around isn't "is this a strong engineer?" It's: "would I put this person in front of our biggest client, unsupervised?"

The three-stage loop that works

1. A time-boxed, breadth-first take-home. Touch all the horizontals in brief: wiring APIs, handling messy data, and — if you're an AI company — the LLM layer (retrieval, evals, guardrails), running end-to-end. You're not scoring depth in any layer; you're scoring whether they can carry a small product across the whole stack without getting stuck. Strong candidates ask clarifying questions first, state assumptions in the README, build the simplest thing that works, and label their hacks honestly.
2. A client role-play. Play a stakeholder yourself — deliberately non-technical, mildly frustrated, holding an ambiguous problem ("the dashboard numbers are wrong"). Score three things: do they ask the right questions before proposing anything, do they explain simply, and do they stay with your actual concern instead of disappearing into architecture talk? This is the stage that separates FDEs from strong backend engineers, and it's the one most companies skip.
3. A direct fundamentals check. Ask about the languages at the top of their own resume — the event loop, threads and shared state, the runtime gotchas. FDEs debug alone in customer environments; fundamentals are the floor, and seniority doesn't exempt anyone. Check them explicitly, because polish hides gaps.

The red flags, from real loops

• Too much engineer, not enough human. Technically brilliant, but can't explain their work to a non-technical stakeholder and shows no curiosity about the customer's problem.
• Waiting for permission. In ambiguity scenarios they keep asking "what would you like me to do?" In the field, that question goes to a client who hired you to answer it.
• Over-engineering. The take-home comes back elegant, scalable, and late — when the signal you wanted was working, fast, pragmatic.
• Shaky fundamentals. Fuzzy on the basics of their own resume's languages. This candidate will freeze the first time something breaks on-site with no colleague to ping.
• Mishandling the role-play client. Talking past the stated concern, getting defensive, burying the "client" in jargon. A candidate who creates misunderstandings in a 30-minute role-play will create them in your accounts.

Two candidates

Composites from real loops — details changed, patterns exact.

The yes opened the role-play by asking the "client" three questions before proposing anything — what changed recently, who uses this report, what does "wrong" mean exactly. Halfway through, said "I don't know yet — but here's how I'd find out" and laid out the steps. The take-home wasn't the most polished that month: it ran end-to-end, the README stated every assumption, and the one hack was labeled as a hack with a note on the proper fix. Mid-level on paper. Easy yes.

The no had the strong resume, the big-name company, the polished take-home. Then the fundamentals check: couldn't explain what happens when two threads touch the same data, in the language at the top of their own resume. In the role-play, answered the client's complaint with an architecture lecture; the "client" repeated the concern twice and never got an answer. That's the exact profile that churns an account — not because the code is bad, but because the customer feels unheard. No, and it wasn't close.

Setting the bar for your first FDE hire

If you're a founder making the first FDE hire, optimize for breadth and ownership over any single deep specialty — the first FDE inherits everything from discovery to deployment. Generalists who've done client-facing delivery, internal-tools work with real "customers," or full-stack ownership under ambiguity outperform deep specialists here. And post the role under the names candidates actually search: the title isn't standardized, so a posting as Solutions Engineer or Applied AI Engineer reaches the same pool — the job description template covers the variants and gives you copy-paste responsibilities and requirements.

One more calibration source: the interview questions guide shows the loop from the candidate's side — useful for pressure-testing whether yours is scoring the right things.