Forward Deployed Engineer went from a Palantir curiosity to the most-recruited role in AI in twelve months - postings up 729%.
This is the 10-step roadmap into it: what the job actually is, the stack that gets you in, and the interview round that eliminates 60% of people who pass the coding.
Follow my Substack to get fresh AI alpha: movez.substack.com
That is not a research scientist’s package. It is not a staff engineer at a big tech company.
It is the going rate for an engineer who does something almost nobody optimizes their career for: getting AI to actually work inside a real company.
Nobody is asking this person to train a model. They don’t need a PhD, and they don’t need to beat anyone at algorithm puzzles.
They need to walk into a business with legacy systems, a compliance department and a skeptical ops team - and come out six weeks later with something that runs.
The reason it pays that much is one statistic. An MIT NANDA study of 300 enterprise AI projects found 95% produced little or no measurable impact on profit and loss.
The models worked fine. The deployments died - because nobody could make them talk to a legacy database, pass a compliance review, or survive being handed to the team that inherited them.
The name is borrowed from the military: forward deployed means stationing specialized units close to the operational theater rather than back at headquarters.
Palantir built the modern version in the early 2010s and called them *Deltas* - and until 2016, the company had more Deltas than it had software engineers.
The premise was that customers didn’t need more product features. They needed engineers who could make the product work inside their fragmented, legacy, regulated, politically complicated environments.
That premise was niche for a decade. Then AI broke generic SaaS, and it became the whole game.
This is not a job description. It’s a go-to-market strategy - and the people executing it are the best-paid non-research engineers in the industry.
01. Learn what the job actually is
An FDE is the engineer the company sends to the customer. Not for a sales call, not for a kickoff meeting - for weeks at a time, sitting next to the people who will actually use the product, learning their workflow in painful detail, and shipping custom code that makes their version of it work.
The best mental model isn’t consultant and it isn’t solutions engineer. It’s founding engineer, working on someone else’s product.
There is no PM in the room to decide scope, no staff engineer to escalate the architecture to, and no backlog telling you what matters - you decide what to build, what to fake, and what to push back on, in the room, that week.
The typical rhythm across top AI companies is remarkably consistent: an FDE sits with a customer for four to eight weeks, ships something that works, and then the core engineering org slowly productizes whatever turned out to be general.
That loop is the entire strategic point of the role. You are simultaneously delivering revenue and doing the company’s highest-fidelity product research.
02. Understand why the role exploded
That 95% number from the lede is the foundation of this entire career path, so it’s worth understanding precisely.
- Those enterprise AI projects didn’t fail because the models were bad.
- They failed on integration: systems that couldn’t talk to legacy SQL databases, couldn’t handle the customer’s SAML authentication, couldn’t meet data residency requirements, and couldn’t be maintained by the operations team that inherited them.
Three forces then pointed the same direction at once.
- AI broke generic SaaS - the horizontal promise of buy-it-and-plug-it-in survives in mature categories but not in AI, where every enterprise has unique data, unique workflows, unique compliance constraints, and its own definition of good enough. Selling AI to a Fortune 500 is now always also selling an integration project.
- Labs need to deploy at the speed the technology moves - a six-month integration kills a pilot before it lands.
- And AI tools made the economics close: with Claude Code and the modern stack, one strong FDE does what took a team of three a few years ago, which is the only reason sending a human onsite for six weeks pencils out.
Notice what that means for you. The bottleneck in AI is no longer capability. It’s deployment - and the market is repricing accordingly.
03. Map the market and pick targets
The title is unstable, and that’s the first practical thing to know - searching only for “Forward Deployed Engineer” will hide most of the market from you.
The same job ships as Applied AI Engineer (Anthropic’s name for it), Forward Deployed Software Engineer or FDSE (Palantir’s), Solutions Engineer, Deployment Engineer, and Founding Engineer (Customer Facing) at smaller startups. Search all of them.
The growth is not subtle. FDE postings on Indeed went from 643 in April 2025 to 5,330 in April 2026 - a 729% increase in twelve months.
By mid-2026 there were 224 open FDE roles across 39 AI companies, and that counts only what was publicly posted. Salesforce committed to hiring a thousand. EY launched a dedicated FDE practice in the UK and Ireland in April 2026 - the first major consultancy to formally adopt the model.
Compensation reflects the scarcity, and it splits sharply by tier. Levels fyi data puts average US total comp around $238,000, with a typical range of $205,000–$486,000 and staff-level FDEs clearing $630,000. Palantir’s median sits near $215,000.
At the frontier labs it’s a different market entirely: senior FDEs at Anthropic and OpenAI clear $785,000, with Anthropic’s Applied AI Engineers above $300,000 base at senior levels and total comp regularly crossing $500,000.
One planning note worth having early: Anthropic typically does not negotiate offers.
04. Build engineering breadth
This is the counterintuitive part, and it’s where engineers coming from a specialist track get it wrong.
The strongest FDEs are not the deepest engineers their company has.
They’re the ones who can hold six domains in their head at once and switch between them cheaply. Depth in one area is worth less here than being genuinely solid across all of it.
Concretely, the floor looks like this. Python and TypeScript cover most of the ground you’ll touch. One cloud - AWS, GCP, or Azure, pick whichever your target customers actually run.
One database you know well and can debug under pressure, and one frontend framework you can throw a working interface together in.
That’s enough to start. You do not need to be the best engineer in the room; you need to be the only person in the room who can do all of it.
Two softer layers matter as much as the technical ones, and they’re what the interview will actually probe.
Product judgment, because you are the PM in the room and nobody else will decide what to build versus what to fake.
And business acumen - someone will ask what the ROI of this is, and they’ll need the answer to defend the project to their own leadership.
Framing your work in dollars and hours saved is a real, learnable skill that most engineers never practice.
05. Learn to ship AI, not train it
Here is the single most common misconception standing between engineers and this job: they assume they need to be able to train models.
You do not. Nobody is asking an FDE to fine-tune anything. You absolutely do need to ship them - which is a completely different and far more learnable skill set.
The AI-native layer is well defined at this point. Strong prompt engineering. Fluency with the major model APIs.
- RAG patterns - and specifically, knowing when retrieval is the wrong answer.
- Structured outputs, because production systems need validated shapes, not prose.
- Basic eval discipline, which is the layer that separates people who demo from people who ship.
And at least one agent framework you’ve actually built something in.
Weight your preparation toward evals and failure modes, because that’s what enterprise deployment is actually made of. Debugging hallucinations, retrieval failures, bad tool calls, brittle multi-step workflows.
Knowing how to reason about latency, cost, reliability, and security as tradeoffs rather than checkboxes.
Anyone can get a demo working; the entire value of an FDE is being the person who knows why the demo won’t survive contact with a real company, and what to do about it.
06. Build the three artifacts enterprises buy
This is where a generic “learn AI” roadmap stops being useful and specifics start to matter.
Anthropic’s own FDE postings describe the deliverables plainly: you embed with strategic customers to build production applications with Claude, and you ship MCP servers, subagents, and agent skills.
Those three artifacts are the concrete unit of work.
- MCP servers are the integration layer - the thing that connects Claude to the customer’s actual systems: their ticketing, their warehouse, their internal API that has no documentation and one person who understands it.
- Agent skills encode the customer’s specific workflow and institutional knowledge so Claude follows their process rather than a generic one.
- Subagents handle the work that would otherwise blow out a context window on a long-running task.
Build one of each, against a real system, and you have something almost no candidate has: a portfolio of exactly the artifacts the job produces.
An MCP server that wraps a genuinely messy API is a stronger hiring signal than any certificate, because it proves the thing they can’t otherwise test for - that you can make a frontier model useful inside a system nobody designed for it.
07. Master Claude Code as your multiplier
Remember the third force from Step 2 - the underrated one. AI tools made FDEs dramatically more productive, and that is what made the role economically viable at scale.
One strong FDE now does work that took a team of three a few years ago. Sending a single human onsite for six weeks only pencils out because of that multiplier.
So the tooling isn’t a nice-to-have on top of the job; it’s load-bearing to the business case for your seat.
Practically, that means fluency with Claude Code is part of the skill stack, not adjacent to it.
The specific leverage points map directly onto FDE work: ramping into an unfamiliar codebase fast when you land at a new customer, writing the integration glue that makes up most of your output, and delegating research to subagents so a long deployment task doesn’t collapse under its own context.
There’s a hiring-signal reason to get good at this too, and it’s unusually direct. In Anthropic’s technical use-case screen, you may be given access to Claude and asked to work through the problem with it - deliberately, because it mirrors the actual job.
How you drive the model is part of what’s being evaluated. Practicing that is preparing for the interview and doing the work at the same time.
08. Ship one real deployment for a real user
Every FDE job posting screens for the same phrase in some form: shipped production AI systems. Not studied, not prototyped - shipped, to someone who depended on it.
That’s the wall most candidates hit, and it’s the one thing on this list you cannot read your way past.
So manufacture the experience deliberately. Find one real workflow belonging to someone who is not you - a small business, a nonprofit, a team inside your current company, a friend’s ops process.
Sit with them. Watch them work. Build the thing that removes the worst part of their week, deploy it where they actually use it, and then stay long enough to fix what breaks.
That last part is not optional the whole job is what happens after the demo.
Then write it up the way an FDE reports, because the write-up is half the artifact. Not “built a RAG chatbot with LangChain.”
Instead: what their workflow cost before in hours, what constraints you couldn’t change, what you deliberately chose *not* to build, what broke in week two, and what it costs them now.
That document is your interview. Every hiring manager reading it learns more about you than any résumé line could tell them.
09. Learn customer discovery
This is the step to read twice. Anthropic’s Applied AI Engineer loop includes a customer-conversation round, and it carries a hidden weight: it filters out roughly 60% of candidates who already passed the coding stages.
Strong engineers, eliminated at the round they didn’t prepare for. Meanwhile 73% of frontier-lab FDEs report that running discovery conversations was the skill they were *least* prepared for coming from a traditional software background.
The failure mode is predictable and almost universal: the candidate hears a customer problem and starts solving it. They propose an architecture. Some open an editor.
- The candidates who advance do the opposite - they run the round like a research interview. They ask about the buyer’s current evaluation criteria.
- They ask about previous failed AI deployments, which is where all the real constraints are buried. They ask what genuinely cannot change: compliance, latency, data residency.
- They ask which specific workflow this would replace and who loses work if it succeeds. They take notes. They reflect back what they heard. They do not write code.
Anthropic screens for this explicitly because enterprise Claude deals don’t close on technical depth alone. It’s a learnable skill - and you can practice it in the exact same sessions from Step 8.
Every time you sit with the person whose workflow you’re fixing, you’re rehearsing this round.
10. Run the interview loop
The loop is unusually consistent across the top companies, and it’s built to filter in both directions at once - against pure algorithmic engineers who can’t communicate, and against smooth consultants who can’t code.
Expect roughly five stages:
- A recruiter screen on motivation, background, and level fit.
- A technical use-case screen - at Anthropic, a practical scenario around deploying Claude with MCP tooling, where you plan and execute a long-running task and reason about reliability, context-window management, and consistency in production.
- A coding round that is practical rather than LeetCode: a rate limiter, streaming data processing, a distributed job queue, a token-budget allocator, a structured tool-use orchestrator - often with new customer constraints layered in mid-exercise to see whether you refactor cleanly.
- A hiring manager round on past projects and customer reasoning. Then a final panel on solution design and values.Two preparation notes that people skip.
- Mission alignment is screened seriously at Anthropic - read the Core Views on AI Safety, the Responsible Scaling Policy, and recent interpretability work before you apply; generic enthusiasm does not pass.
And their postings ask for *“calibrated judgment about model risks,”* which is the bullet that quietly eliminates otherwise strong candidates. Being able to say clearly where you would *not* deploy a model, and why, is part of the bar.
Six starting points - find yours
- Add the AI layer, keep the rigor. Your production instincts are the scarce half - most AI-native candidates have never run anything real. Add prompting, model APIs, structured outputs and evals, then ship one MCP server against a messy internal system.
- Stop training, start landing. You’re overqualified on modeling and underqualified on everything else. The job is integration, constraints and stakeholders. Deliberately build something boring that survives a compliance review and an ops handoff.
- Go where the deployments are. Frontier-lab FDE roles are rarely entry level. Aim one ring out - the startups and consultancies deploying AI into enterprises - where you’ll do the same work with less gatekeeping, then move up in two years.
- Close the coding gap, fast. You already have the half that eliminates 60% of applicants. Now get past the coding round: practical exercises, not LeetCode - rate limiters, streaming, job queues, tool-use orchestrators, written cleanly under changing constraints.
- Prove you can actually build. Discovery and stakeholder management are already yours. The loop is explicitly designed to filter out smooth talkers who cannot code - so your entire preparation is one shipped, maintained, publicly documented system.
- You may be doing this job already. Internal platform engineers who sit with business units are running the FDE motion under a different title. Rewrite your experience in the role’s language - workflows changed, hours saved, constraints navigated - and you’re a live candidate today.
Conclusion:
The scarce thing was never the model. It’s the person who can *land* it.
Capability stopped being the bottleneck somewhere in the last two years.
What’s scarce now is the engineer who can walk into a company with legacy systems, a compliance department, and a skeptical ops team -and come out six weeks later with something that actually runs.
That’s a strange combination of skills, which is exactly why it pays like it does. Engineering breadth over depth. J
udgment with no PM to lean on. The patience to sit in someone else’s messy reality long enough to understand it before writing a line.
Most engineers will keep optimizing for the roles that existed in 2020. The ones who learn to deploy will own the decade - because every model that ships from here still has to survive contact with a real company.
