/writing · thoughts
The Forward Deployed Engineer Interview Loop, Round by Round
· 8 min read
The first post on this role explained what the job is and left the interview loop closed. This post opens it.
A caveat up front, same as last time: I'm trying to get through this loop, not reporting from inside it. What follows is pieced together 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 there isn't enough public primary-source detail to rebuild any one company's loop exactly. The shape below is the part that holds across sources.
The shape
A modern FDE loop runs five to six stages. What sets it apart from a standard software-engineering loop is two rounds a pure SWE loop usually doesn't have, neither of them about coding: 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. Every round after the recruiter screen drops people, and the two 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 checking how much travel and customer friction you can stomach, because a good 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. What changes is how the problem is framed. 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 they are also watching whether you make sane calls quickly in a setup that looks like a customer's, instead of chasing the theoretically optimal answer that eats 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 ground.
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. Every source names the same failure: jumping to a solution before checking the customer's real constraints, or sketching an elegant six-month architecture when the round rewards scoping something you can deliver 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 lose out to engineers who scope hard and ship a small slice that works. The role rewards judgment over correctness, and this round is where you see it most.
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. What the interviewer wants to see is you naming those constraints yourself, before you draw 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 2026 patterns keep showing up.
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 what carries the most weight. What this round tests is a skill that travels: building an honest evaluation, one that can show your own system losing.
Round 6: Client simulation and behavioral
Forty-five to sixty minutes, run under simulated pressure. The questions are oddly specific, and similar enough across sources that you can prepare for them 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 staying calm, setting boundaries, and explaining a probabilistic system to executives who don't 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 reports agree on why people get rejected, and the reasons are specific to this loop, not 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.
The guides also keep coming back to one framing fix. 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
Same as in the first post, here is where I stand. 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 a mixed, partly negative result. 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 more algorithm drills won't move the needle for me. One real external deployment will. It gives me round-3 and round-6 answers to draw from, and it is the thing I already said I'd go build.