The FDE crash course.
Forward deployed engineer is the role AI companies are hiring for fastest, and its interview is nothing like a SWE loop: roughly half of it is not coding. Here is the whole path in plain language: the role, the loop, the decomposition round that decides the offer, company-by-company playbooks, and the prep system that closes the gap, each idea explained twice: loose plain English first, the interview-precise version second. That two-voice format is not a gimmick. Explaining the same fact at two altitudes is the job.
1 · What the role actually is
Before the loop makes sense, the role has to. A forward deployed engineer is not a support engineer with a laptop, and not a consultant with opinions. The whole interview is downstream of one idea: this person ships production software inside someone else's messy company.
Forward deployed engineer
An engineer embedded in the customer's world rather than the vendor's. You take a half-formed ask ('flag suspicious claims before we pay them'), find the real problem underneath it, and ship working software inside their environment, with their data, their politics and their deadlines. You own an outcome, not a feature.
The role Palantir invented and AI companies industrialised. An FDE owns the deployment end to end: scoping, integration, go-live, production support, iteration. Hiring managers describe the bar as closer to a senior product engineer than a field-applications engineer, meaning production code plus discovery plus stakeholder judgment, all in one person.
FDE vs SWE
A SWE builds the product once, for everyone. An FDE makes it work for one customer at a time, and the hard part is rarely the code. It's working out what the customer actually needs, which is never quite what they first asked for.
The interviews split exactly the same way. A SWE loop is mostly algorithms and system design. An FDE loop is roughly half case studies, stakeholder scenarios and business judgment, and the coding that remains is practical: debugging, SQL, integrations, unfamiliar APIs read from their docs.
FDE vs solutions engineer vs consultant
A solutions engineer demos and hands off before production. A consultant recommends and leaves. An FDE stays, writes the production code, and is still the one paged when it breaks at 2am.
Pre-sales owns the promise, consulting owns the advice, the FDE owns the running system. Interviews probe this boundary deliberately: incident-response and on-call questions exist to catch candidates who have only ever handed systems over, never carried one.
'Why FDE, not SWE?'
Asked in every recruiter screen, and it filters out more people than you'd expect. 'I like talking to people' fails. 'I want to solve hard problems' fails. What passes is specific evidence of customer-facing technical work, plus a believable reason you chose it on purpose.
The strong shape: name the experience first, then the preference. Along the lines of: the engineering was rarely the bottleneck, understanding what the customer actually needed was, and I'd rather sit with someone's messy problem and ship the fix than chase frontier complexity. Then back it with a deployment you owned end to end.
The market, briefly
FDE postings grew roughly eight-fold in a year, from about 640 in April 2025 to about 5,300 in April 2026 (a figure reported consistently across prep guides and open-source handbooks). It's currently the fastest-growing engineering role, and the market is short of people who have genuinely shipped into customer environments.
Compensation reflects the shortage: reported averages sit around $238K total comp, with senior packages running $300K to $600K. The practical consequence for a candidate is simple: portfolio projects showing production deployments with real integration work outweigh academic polish.
2 · The shape of the loop
The loop is remarkably consistent across companies, and it is not weighted the way candidates assume. The round most people prepare hardest for matters least, and the one almost nobody drills carries the most weight.
The five rounds
Recruiter screen, practical coding, a deep dive on your past work, an ambiguous case study, then behavioural. Three to six weeks end to end, faster at OpenAI, about a month at Palantir.
Each round has a distinct job: the screen leans hard on 'why FDE', coding is practical rather than algorithmic, the deep dive grades your past architecture decisions, the case study decides the offer, and behavioural tests how you handle angry customers and being wrong.
The case study round
You're handed a vague brief ('the CTO wants an AI copilot that flags suspicious claims') and a stakeholder to question. Prep-guide consensus puts its pass rate around 40%, the lowest of any round, and its weight around 30%, the highest (reported figures; no company publishes round stats). The most common way to fail it: proposing a solution before understanding the problem.
Interviewers are not grading the answer; they're watching how you move through a problem you've never seen. What scores: structured discovery, questions about data lineage and compliance, and a visible bias toward understanding the business workflow before naming any technology.
Coding, but practical
Debugging a broken integration, writing SQL against messy joined tables, fixing a large buggy file, or learning an unfamiliar API live from its docs. The bar is real, but the flavour is production work, not puzzles.
Grinding LeetCode for an FDE loop is the documented fastest way to fail one: those hours displace case-study reps, and the case study is what decides. Palantir even runs a dedicated 'learning' round where the material is deliberately new and the interviewer is your resource; it tests how you absorb, not what you already know. (One documented exception: Google's FDE loop keeps a real DSA round alongside collaborative practical coding, so check the company before skipping algorithms entirely.)
Take-homes and AI-assisted rounds
Most AI-native loops now gate on a build artifact: a few hours building on the company's APIs from a deliberately vague brief, then a short recorded walkthrough. Meanwhile live coding has split in two: rounds where you're graded on driving AI tools well, and rounds engineered so AI can't help, like debugging an unfamiliar codebase with no assistant.
Documented grading for take-homes, per candidate reports: it runs end to end first try, it ships with an eval harness (its absence is the named red flag), production hygiene like retries and error handling, and stated assumptions in a short README. In AI-assisted rounds the transcript may be reviewed, so prompt with stated intent and verify aloud; in debugging rounds, trace one request end to end against the spec and ignore the planted ugly-but-working code. Always ask which mode you're in.
The discovery-call simulation
A newer round, heaviest at Anthropic and spreading: the interviewer role-plays a VP at a fictional enterprise and you run a 30-to-60-minute discovery call. Candidate reports call it one of the strongest offer predictors in the loop, and the universal failure is pitching instead of discovering.
Run it like the real thing: open with their world ('walk me through how this works today'), ask what they've already tried and what happened, quantify the pain, find the immovables (compliance, data residency, procurement), identify users, sponsor and blockers, define success as a number together, and close by summarising what you heard plus one concrete next step. If pushed to architect early, earn the delay: 'a couple more questions so I don't design the wrong thing.'
3 · The decomposition framework
One framework covers the round that decides the loop: clarify, decompose, prioritise, propose, risk. In that order, out loud. The order is the point, because every documented failure in this round is a step skipped or taken too early.
The framework
Five moves, always in sequence. Understand the problem, break it into named pieces, pick the narrow first win, propose a phased plan, then say what might be wrong with it. Naming the structure as you go lets the interviewer watch you drive.
Open by declaring intent: 'I'll spend the first ten minutes understanding the workflow before I propose anything, because the wrong problem solved perfectly is still wrong.' That one sentence signals the exact discipline the round exists to test.
Clarify
The step everyone rushes. Who actually uses this? What do they do today, click by click? What does success look like in numbers? What's the deadline, and why that date specifically? Who owns the data? What's the compliance surface?
Treat the questions as a checklist, not inspiration: users and workflow, success metric, data ownership and lineage, compliance, timeline. A vague stakeholder is not an obstacle here; drawing specifics out of vagueness is the skill being scored.
Decompose
Turn the vague outcome into named sub-problems, out loud. 'Automate onboarding' becomes document collection, identity checks and account setup, each with its own users, data and risk.
Naming the pieces proves you see a problem space rather than a single solution path, and it sets up the next move: you cannot prioritise what you have not separated. Strong candidates decompose along the customer's workflow, not along their own tech stack.
Prioritise
Pick the narrow first problem that delivers value fastest, and say why the rest can wait. This is the single highest-signal move in the whole round.
The shape interviewers want: a Phase 1 that ships in weeks, an explicit list of what you deferred, and the reason each deferral is safe. Breadth reads as indecision; a justified narrow slice reads as judgment.
Running it live
Documented mechanics from candidate reports: narrate continuously, because interviewers read silence as stuck. State assumptions with numbers ('say 200 dispatchers, five thousand calls a day') instead of waiting for permission. And when the interviewer injects a constraint mid-round ('now assume half the users have no smartphone'), treat it as a gift: restate it, adapt one component, keep moving.
Real briefs from documented loops, worth drilling cold: cut a city's 911 response times given call, traffic and ambulance GPS data. Design technology that helps low-vision elderly people cook (scored on user empathy, not tech). Unify fraud detection across three acquired banks with inconsistent systems. Reroute shipments for a logistics firm running SAP, weather APIs, and 400 warehouse managers. And the sleeper: 'our ops team doesn't trust the dashboard.' Two minutes of structure before any solution, every time.
Propose & risk
Sketch the phased plan, then name what could sink it: the data that might not exist, the users who might not adopt it, the assumption you haven't verified yet.
Risks come last because credible ones only exist after scoping: data quality, adoption, the promised dataset that turns out to be empty. Naming a falsifiable assumption ('I'm assuming claims history is queryable; if it isn't, Phase 1 changes') is what separates a plan from a pitch.
4 · Scenarios: how answers split
The difference between passing and failing is rarely knowledge. Given the same question, the weak answer guesses at one path while the strong answer builds a structure. These are documented questions from real loops, with the split made explicit.
'Staging works, production breaks'
The weak answer is 'I'd check the logs'. The strong answer runs parallel hypotheses (data drift, environment differences, upstream API changes), isolates each one, and then proposes monitoring so the failure can't happen silently again.
The pattern generalises to every debugging question: enumerate hypotheses, order them by likelihood and cost to test, isolate, then close the loop with prevention. Interviewers are listening for the structure, not for a lucky guess.
'Data quality degrades every Monday'
Guessing fails here. The strong answer notices that Monday means weekend, suspects the Sunday-night batch job upstream, and proposes automated quality gates with alert thresholds so the next regression pages someone instead of hiding.
Cadence is evidence: a weekly rhythm points at a weekly process. The strong candidate treats the schedule itself as a clue and instruments the pipeline; the weak one treats it as a coincidence and starts poking at rows.
'Their auth is SAML, your API is OAuth'
'I'd convert one to the other' is a fail. The strong answer maps the token exchange flow, places a middleware adapter where it belongs, and covers retry logic and credential rotation, because the bridge has to survive production rather than a whiteboard.
Integration questions grade production thinking: where the adapter sits, what happens when a token expires mid-request, how credentials rotate without downtime. The happy path is assumed; the marks live in the failure paths.
The behavioural five
Five stories, prepared in structured form and rotated until they're boring: an ambiguous problem you scoped, a time you were wrong and the data proved it, a silent failure you caught, something you built that failed, and speed delivered with judgment.
This round tests two capacities: handling angry customers, and being wrong in public. 'Tell me about a project that got stuck' carries a hidden rubric (you must be the one who unstuck it), and 'tell me about a product that failed' rewards a deliberate wind-down over a rationalised one.
5 · Company playbooks
Every documented loop keeps the same spine: screen, practical coding, deep dive, case, behavioural. What changes is the last-mile flavour, and one page of research per company covers it. These are the documented variants, from candidate reports and public repos.
Palantir
Invented the role and the round. The loop centres on decomposition plus a 'learning' interview where the material is deliberately new and the interviewer is your resource. Coding has included a HackerRank that was one large file full of bugs.
Palantir publishes its own guidance on open-ended questions, and it's the highest-value single read: deliver a functioning idea first, then expand it. Reported loop length around 28 days. Their published advice aligns exactly with the framework here: scope aloud, state assumptions, get to a minimal working solution before optimising.
OpenAI
Case studies, customer empathy and business judgment carry roughly half the evaluation. The loop runs faster than most, reportedly three to five weeks.
The documented take-home: around five hours building on their APIs with a recorded video walkthrough. Graders reportedly score a running artifact, an eval harness, production hygiene and written trade-offs. The walkthrough is a customer-demo proxy: working thing first, one architecture diagram, one conscious trade-off, your evals, next steps, under five minutes.
Anthropic
The discovery-call simulation is heaviest here: the interviewer plays a VP at a fictional enterprise and you run the call. Candidate reports rank it among the strongest offer predictors.
The documented take-home is a three-to-four-hour app from a fictional customer brief, and notably their briefs have prohibited AI assistance unless explicitly permitted; read the rules and follow them, since transcripts and style make usage obvious. The discovery round fails one way: pitching instead of discovering.
Sierra
Agent system design, customer-service-specific evals, and conversational architecture. If the product is a support agent, expect to design the eval suite that keeps one honest.
Runs a documented 'AI-native interview' where you're graded on driving AI tools well (intent-first prompts, visible verification, rejecting bad output), plus an anti-AI debugging round on an unfamiliar codebase. The pair tests the same competency from both sides: can you judge code, not just produce it.
The documented exception to 'skip LeetCode': Google's FDE loop keeps a real DSA round, alongside collaborative 'vibe coding', a Googleyness behavioural round, and agentic ML system design. Six to eight weeks end to end.
Documented in a widely-starred candidate repo (linked in the sources below). The practical rounds emphasise working with ambiguous requirements and communication during live coding, so the FDE skills still decide; the DSA bar is simply also real. Calibrate prep to the company, not the role title alone.
ElevenLabs & Ramp
ElevenLabs runs a tight startup loop with no dedicated behavioural round; the case study is central and they want visible speed and scrappiness. Ramp grades real integration fluency: enterprise SSO, accounting systems, actual API questions.
Both reward the same candidate shape from different angles: someone who has wired real systems together under time pressure. For Ramp specifically, the SAML-to-OAuth bridge and webhook idempotency questions in the case trainer are the documented flavour.
Fin (Intercom) & the data platforms
Fin's documented loop: recruiter, take-home, a practical pair-programming build, a values assessment, then system and data design. They ask 'tell me about a product you built that failed'. Data-platform loops (Databricks, Snowflake) weight SQL, Spark and panel presentations.
The Fin build round is collaborative rather than adversarial: they're simulating working with you. The data-platform variant is the reminder that FDE means different stacks at different companies; the discovery and decomposition spine transfers, the tools column of your prep does not.
6 · The two-altitude drill
⇄ vocabulary shared with the AI crash courseThe recurring FDE skill, tested explicitly in both Palantir and OpenAI loops, is explaining one technical fact at two heights: precise for their staff engineer, consequence-first for their exec. This page has quietly been doing it to you the whole way down.
The drill
Take one fact you know cold. Explain it to a staff engineer: exact, trade-offs named. Now to an exec: no jargon, business consequence first, one analogy at most. Same truth, two altitudes.
Run it as a daily rep: one item, two written answers. The engineer version proves depth; the exec version proves you can be put in front of a customer unsupervised. Interviews test the switch mid-conversation, which is why it has to be drilled rather than merely understood.
The failure patterns
The documented ways candidates fail: over-preparing algorithms while under-preparing the case study, jumping to solutions before scoping, and showing no evidence of customer-facing work. All three are preparation problems, not talent problems.
Each has a mechanical counter. Spend prep hours on spoken decomposition reps instead of LeetCode. Drill the clarify step until proposing early feels physically wrong. Lead with deployments you owned rather than titles you held; delivery evidence beats the missing job title.
The vocabulary
The applied-AI language the domain rounds expect (embeddings, chunking, retrieval metrics, agent patterns, eval design) has its own course on this site, one level down the stack.
Domain questions in FDE loops are fluency checks, not research quizzes: hosted versus self-hosted trade-offs, how you'd evaluate a RAG system, when hybrid search loses to dense. The AI crash course explains each of those twice, plain then precise, in the same format as this page.
7 · The prep system
Everything above is knowledge; offers go to preparation. The documented prep shape is small and repeatable: a temperament to demonstrate, stories with numbers, a daily rep, and a knowledge base that compounds. None of it is glamorous, which is why it works.
The FDE mindset
Interviewers screen for a specific temperament: bias to action (demos over decks), comfort with ambiguity, extreme ownership (you chase the blocker, you don't wait), customer empathy strong enough to say 'AI is the wrong tool here', and pragmatism: the simplest shipped thing beats the elegant thing in a branch.
The documented rule is show, don't claim. 'I'm comfortable with ambiguity' scores nothing; a sixty-second story where the spec was vague, you stated assumptions, shipped a rough working thing fast and iterated with the user scores everything. Every trait on the list wants a story attached, prepared in advance.
Stories, with numbers
Five or six flexible stories in STAR shape (situation, task, action, result), covering: shipped under ambiguity, a difficult stakeholder, learned a technology fast, a hard trade-off, a failure you own, and end-to-end ownership beyond your lane. Rotate them out loud until they're boring.
The documented sinker is the unquantified ending. Every story ends in a number: 'cut triage time 40%', 'shipped in nine days', 'the customer renewed'. Result is the R in STAR, and it's the part candidates skip. Map each story to multiple questions in advance so nothing in the behavioural round surprises you.
The daily rep
Thirty minutes. One decomposition case out loud on a timer (record it and play it back; you will hear yourself jumping to solutions). One behavioural story out loud. One domain card written at both altitudes.
Spoken retrieval under conversational pressure is a practice problem, not a learning problem. Reading answers silently trains recognition; saying them, timed and slightly uncomfortable, trains recall in the shape the interview actually demands. The case trainer on this site is built for exactly this rep.
The knowledge base
One place where everything you fumble goes, with its fix. A case-reps log (date, brief, what you missed), the discovery checklist you ask every time, your five stories at two altitudes, and one page per target company: product, customers, their loop's flavour, your hook.
The compounding asset is the gotcha log: every fumbled answer becomes a card, every card gets drilled, and the same mistake stops costing you twice. Write answers by hand before digitising; production beats recognition, and handwriting is production.
Why this company
Have a crisp, specific reason for this company and this role: their product, their customers, something true you noticed. Generic enthusiasm reads as a mail merge, and interviewers see forty of those a week.
Prepare sharp questions for them too; documented guidance is that curiosity about the actual work reads as fit. The strongest version references something concrete: a product decision, an engineering post, a customer story, and connects it to work you've already done.
The portfolio
Documented consistently across sources: production deployments with real integration work outweigh academic projects and title history. One live system you built, integrated, shipped and supported says more than any list of frameworks.
The strongest portfolio artifact for these loops demonstrates the loop's own skills: a deployed system with an eval harness, real integrations, and a written trade-off log. It answers 'what have you built lately' with the exact competencies the take-home would otherwise have to extract from you.