The Forward Deployed Engineer Interview Loop, Round by Round
In the first post on this role I said the FDE interview loop is harder than it looks, then left it closed. This post opens it.
A caveat up front, in the same spirit as the last one: I am targeting this loop, not reporting from inside it. What follows is assembled from public interview guides (ElevenLabs, Exponent's 2026 FDE guide, Sundeep Teki's guide), first-person candidate write-ups from 2026, and the hiring language in live FDE postings. Each company orders and weights its rounds differently, and the public primary-source detail is not enough to reconstruct any single company's loop perfectly. The shape below is the part that holds across sources.
The shape
A modern FDE loop runs five to six stages. The thing that separates it from a standard software-engineering loop is not an extra coding round. It is two rounds a pure SWE loop usually does not have: a problem-decomposition round where you write no code, and a customer-simulation round where you are graded on what you say when a deployment is on fire.
The narrowing is the point. Each round downstream of the recruiter screen drops people, and the two rounds that drop the most are the ones a candidate coming straight from a SWE pipeline has never practiced.
Round 1: Recruiter screen
Around thirty minutes. It checks motivation, whether you understand what the role is, and whether your past work reads as ownership rather than ticket-taking. The "why FDE instead of SWE" question is doing real work here. A candidate who wants FDE because the SWE market is tight, and says so without a customer-shaped reason, tends not to clear this round. The recruiter is also calibrating appetite for travel and for customer friction, because a meaningful share of FDE attrition is people who took the title without wanting the job.
Round 2: Technical screen
Forty-five to sixty minutes. Coding still happens, so the LeetCode-is-dead framing oversells it. The difference is the framing of the problem. Candidate reports describe algorithms presented as customer issues: a graph traversal arrives as tracking data lineage through a failing pipeline, or you debug a block of Python before extending it into a small design. Some loops run a code-along where you prototype a generative-AI flow in something like LangGraph. Correctness matters, but the round is also watching whether you make sane decisions quickly in a context that looks like a customer's, rather than reaching for the theoretically optimal answer that takes the whole hour.
Round 3: Problem decomposition
Sixty minutes, usually with no code written. This is the round that most clearly separates the FDE loop from a SWE loop, and it is where strong engineers most often lose leverage.
The interviewer hands you a vague customer goal. Reduce 911 response times. Cut this clinic's no-show rate. Make this bank's analysts faster. There is no spec, the constraints are unstated, and you have to turn the goal into something scoped and shippable while the interviewer watches how you think. The failure mode named across every source is the same: jumping to a solution before validating the customer's actual constraints, or sketching an elegant six-month architecture when the round rewards scoping something deliverable in two weeks.
The grading is about judgment. What would you ship first. What would you deliberately not build yet. What data would you ask for before committing to an approach. Where is the real problem likely to be a workflow or policy problem rather than a technical one. Engineers who design for scale and purity get passed over for engineers who scope aggressively and ship a pragmatic, functional slice. The role rewards judgment over correctness, and this round is where that preference is most visible.
Round 4: System / integration design
Sixty minutes. It looks like a normal design round until the constraints arrive. You are asked to design a RAG pipeline, an agent workflow, or an MCP integration, and then it gets bounded by the things that make enterprise deployment hard: legacy SSO, VPC limits, data-residency rules, API rate limits, observability, eval coverage, latency and cost. Google, Anthropic, Glean, Databricks, and Harvey all hire against some version of this pattern in their public postings. The signal the interviewer is looking for is whether you name those constraints yourself, before drawing a single box, the way someone who has deployed into a real customer environment would.
Round 5: Take-home
The shape has moved away from "implement an algorithm" toward "ship a thin but production-shaped AI system and explain the tradeoffs." Two concrete 2026 patterns show up repeatedly.
The first is an OpenAI or Anthropic style task: you build a RAG system over a messy dataset, and the graded deliverable is the evaluation harness that shows the system resists hallucination and prompt injection. The follow-up deep-dive asks you to defend your prompting-versus-fine-tuning tradeoffs.
The second is a Snorkel-style live scenario: you are handed three files, a fictional client brief, a ground-truth CSV, and a set of raw model outputs, and asked to decide what metrics matter, write the code that evaluates the model against ground truth, find the error patterns, and summarize the findings for a non-technical client. A 2026 candidate report from Northslope describes a near-identical exercise built around four clinic datasets.
In both, the eval harness is the artifact that carries the most weight. Building an honest evaluation, one that can show your own system losing, is the transferable skill this round is testing.
Round 6: Client simulation and behavioral
Forty-five to sixty minutes, run under simulated pressure. The questions are unusually specific, and they are consistent enough across sources to prepare for directly:
A deployed AI agent returns inconsistent results in production but worked correctly in staging. Walk me through your exact debugging protocol.
A client calls during a live demonstration. Their system is returning errors on the screen in front of their executive team. What exactly do you say and do.
You are three weeks into a deployment at a bank, and the agent produces outputs that are technically correct but violate internal compliance policies the client never shared with you. What happens next.
Tell me about a deployment you owned that failed to deliver the expected result. An actual failure, not a disguised success.
These reward composure, boundary-setting, and the ability to translate a probabilistic system to executives who do not think in probabilities. The last question is the trap: the disguised-success answer ("my biggest failure was caring too much about quality") reads as someone who has never actually owned a deployment that went wrong.
What gets people screened out
The rejection patterns are consistent across the reports, and they are specific to this loop rather than to engineering loops in general:
- Strong coding but no credible customer-facing example.
- Architecture talk with no evidence of having shipped to production.
- AI enthusiasm with no deployment experience behind it.
- An inability to discuss evals, adoption, reliability, or metrics in concrete terms.
- The round-3 failure: jumping to solutions, over-engineering, optimizing for elegance over a shippable two-week increment.
There is also a framing fix that the guides keep returning to. STAR answers anchored to a customer outcome beat answers anchored to a technical metric. "I cut query latency by 40 percent" becomes "I cut query latency by 40 percent, which moved the customer's daily reporting from hours to minutes and unblocked the rest of the deployment." Same work, but the second version is the one this loop is built to reward.
Where I sit in this loop
To stay honest about it, the way the first post did. The rounds I would be strongest in are the technical screen, the design round, and the take-home: RAG, agents, MCP, and eval harnesses are the things I have actually built, between the MCP SDK PR, the WebMCP work on this site, the 10-day CAG research system, and a recent validation study whose whole spine was an eval that reported my own hypothesis losing. Those are round-4 and round-5 muscles.
The round I would have to work hardest at is the same gap I named last time. The client-simulation round rewards real external-deployment stories, and mine are still internal or portfolio-scale. The decomposition round sits in between: I can scope a vague problem, but I have done it for internal stakeholders, not across the table from a skeptical external customer with their own politics. So the prep that moves the needle for me is not another pass through algorithm drills. It is one real external deployment to draw round-3 and round-6 answers from, which is exactly the thing I said I was going to go build.