What a Forward Deployed Engineer Is

Six weeks after signing, and nothing in production

Picture a fictional regional insurer that has bought an AI platform to read claims emails and route each one to the right adjuster. Six weeks after signing, nothing is in production. The claims team still forwards emails by hand, IT has not granted access to the shared mailbox, and the platform's default extraction misses the policy-endorsement field the adjusters care about most, because their emails attach scanned forms nobody tested against. The deal is stalling in the gap between a sensible general product and this customer's actual working day.

So who closes that gap? Someone has to sit with the adjusters for a day, get the mailbox access through security review, write the glue code, fix extraction for those scanned forms, ship a version ten adjusters actually use, and then tell the product team which of those fixes every insurer will need. That person is the forward deployed engineer, and the rest of this lesson works out why the job is shaped that way.

Two halves of one job

A forward deployed engineer (FDE) is a software engineer embedded with a customer to ship working software against a real business problem, and to carry what they learn back into the product. Both halves count. An FDE who ships for one customer and teaches the product nothing has done a consulting engagement, and the next insurer starts from zero. An FDE who files product feedback without shipping anything has done account management, and the first insurer is still forwarding emails by hand.

Two familiar descriptions each catch one half and drop the other. One is the support engineer triaging tickets against a fixed product; the other is the consultant who writes the recommendation and leaves the build to someone else. The support picture misses that FDEs change what the software does. The consultant picture misses that they write production code themselves, in the customer's environment, and answer for whether it works.

Success follows from the same idea: it is the customer's outcome in production. A demo that impresses the sponsor and is never used counts for little. A plain internal tool that cuts adjuster handling time and is still running after you leave counts for a lot. Lines of code are a poor unit too, and some of the most useful FDE days end with a planned feature deleted because discovery showed nobody needed it.

Choosing what to do first

One week on an engagement mixes work that other companies split across several jobs:

• discovery: which decision or workflow the customer wants changed, and who owns it
• scoping a slice that can run in their environment within one or two weeks
• data work, which means access requests, schema mapping and cleaning whatever actually arrives
• integration with their auth, their APIs and their network rules
• applied AI at the AI labs and AI-native employers: retrieval, tool calling, evals, prompts that survive real inputs
• writing up what generalizes, so the core product team builds it once instead of every FDE rebuilding it

Because the mix is broad, the hard part is choosing. You have three weeks, a skeptical sponsor and no production data yet. Do you start on extraction, since that is the visible failure, or on mailbox access, since nothing ships without it? For the insurer, a reasonable call is to file the access request on day one, because security review has a lead time you cannot compress, and to work on extraction against a few sample emails while you wait. A customer who had already granted access would flip that order. The interview loop is built to test that kind of choice as much as the skills underneath it.

Where the role came from and where it has spread

The role's origin is Palantir. A secondary summary of Palantir's own blog describes product developers as "one capability, many customers" and forward deployed software engineers, called Deltas internally, as "one customer, many capabilities" (Ophy's Palantir guide; Palantir's original post was not retrieved for this lesson, so treat the wording as paraphrase). The same summary describes a second deployed role, the Deployment Strategist or "Echo", as an analyst and generalist working in Python, R and SQL, with reported travel of 25 to 75 percent.

The title has since spread, and the names drift. Candidate-prep guides document forward deployed loops at OpenAI, Anthropic (where the title is reported as Applied AI), Databricks, Scale AI and Google Cloud. Sierra's closest equivalent is titled Agent Engineer (Exponent guide). These are prep aggregators, so read them as reported accounts.

Job postings show the embedded half directly. Salesforce's Lead Forward Deployed Engineer posting for Agentforce describes an engineer embedded with one enterprise customer, writing the code that ships an agent (Built In posting). Sarvam AI in Bengaluru lists forward deployed roles, one of them for air-gapped, on-premises and classified deployments, and asks for production agent experience (Sarvam posting).

What interviewers actually score

Postings say what a company hopes for. Rubrics show what it pays attention to when deciding, which makes them the clearest evidence of what the job values.

Nothing in the middle column rewards volume of code or demo polish. Every row rewards finding the right user, cutting the right scope, and knowing whether it worked, which is the insurer problem restated as a scoring sheet.

One caveat before you plan around the wider material. Prep sites that cover FDE interviews frequently cite each other, and the percentages they quote, such as pass rates per round or the share of evaluation given to judgement, have no traceable source. This track does not repeat them.

Preparing for a role this broad

Start with breadth at a working level. You should be able to write a paginated API client, a SQL aggregate with a join and a small retrieval pipeline without looking things up, and run a twenty-minute discovery conversation without pitching. Depth in one or two of those areas is a bonus, but a gap in any of them is a round you can fail.

Then practise choosing out loud. For every open-ended prompt, say three things in this order before any architecture: who uses the output and what decision it changes, what ships in the first week, and how you will know it worked. That order maps onto the Palantir decomposition rubric line for line.

You also need one story about the feedback loop, where something you learned from one user changed what got built for many. Customer work is the obvious source, and an internal platform story works too: you built a tool for one team, noticed which parts every team needed, and pulled those into a shared library. Finally, drop the enthusiasm script. "I love working with customers" tells the interviewer nothing they can score, while a time you changed a plan because of what a user showed you tells them a lot.

How this shows up in the interview

You meet the definition of the role twice. Directly, in the recruiter and hiring-manager screens, it arrives as "why FDE?" or "what do you think this job is?". Indirectly, in every decomposition and discovery round, the rubric lines above are the definition turned into scoring.

The probe that exposes a thin understanding is the question after shipping. Palantir decomposition interviewers reportedly inject new constraints partway through (Aced), and a natural late constraint is "you are leaving in two weeks; what happens then?". Candidates who think of the job as building stop there; candidates who know it includes the handoff have an answer ready. Expect a question about how you work, too: one Sierra candidate report lists "How do you use AI regularly?" from the recruiter call (Aced candidate report).

Credit goes to an answer that covers both halves. A sentence that does it: "I'd ship the narrow version first on the extract they can give us this week, measure handling time for the ten adjusters using it, and write up which parts of the mapping every insurer will need so the product team builds it once."

Check yourself

• An engineer spends a quarter building a bespoke tool for one customer, ships it, and it works. Nothing reaches the core product. What part of the FDE role is missing? Answer: The feedback half. The engagement produced a one-off; nobody decided which parts generalize and pushed them back, so the next customer starts from zero.
• How did the summary of Palantir's blog distinguish product developers from Deltas? Answer: Product developers build one capability for many customers; Deltas serve one customer with many capabilities.
• Why is "I love working with customers" a weak answer to "why FDE?" Answer: It names a feeling, not evidence. The rubric lines reward end-user anchoring and judgement, so a concrete case where a user changed your plan carries the signal.
• Which claims about FDE interviews should you not repeat from prep sites? Answer: Their unsourced percentages, such as per-round pass rates or how much of the score is judgement. Round structures backed by several independent sources are safer.