CrackingWalnuts
Staff goes deep. Engineering management goes to people. The FDE goes to the customer. Palantir, who invented the role, put it best: a product engineer builds one capability for many customers, and a forward deployed engineer does the inverse, one customer, many capabilities. It is the most horizontal engineering job there is, which is exactly why it is hard to hire for and hard to prepare for.
Own one customer's outcome end to end: scope the ambiguity, build inside their systems, and ship what survives.
Salary is approximate market context, not a promise. It varies a lot by country, company, and year.
Can you actually do this?
If one makes you hesitate, that is the gap. Open it to go learn it.
You will find confident articles describing a five-rung FDE ladder with salary bands for each. We could not find a single primary source for any of it. What the real postings show is the opposite of a standard ladder.
The critique is not just noise, and you should be able to tell the difference before you sign. Palantir's original FDEs configured a platform the company had already built. The AI-era version often builds bespoke software inside a customer's codebase, which is a materially different job.
The structure is conceding the point. The frontier labs have been standing up dedicated enterprise-deployment teams that sell embedded engineers. That can still be a great job. It is not automatically the Palantir job, and the title alone will not tell you which one you are being offered. Ask what you would be building, and who owns it afterwards.
This is not a reading list of six courses. It is the arc of a real deployment: you land in a stack you did not choose, fight your way to their data, build the thing, prove it works, get past their security team, and keep the customer while doing it. Each step below is one chapter, picked because the job actually demands it.
You did not choose any of this, and you cannot change most of it. The job starts by reading someone else's decisions accurately.
The decision layer, run in reverse. You are not choosing, you are reconstructing why they chose, and what it now costs you.
They already decided this years ago. Learn to read the decision fast, because it sets the shape of everything you can ship.
Their network is the reason your thing cannot reach their thing. This is the most common week-one blocker.
IAM blocks more deployments than code does, and the person who understands their policy tree left in 2022.
A firewall rule nobody will own is a schedule risk, not a networking detail. Learn to name it precisely enough that someone can approve it.
Where their keys live decides how you authenticate, and it is never where the architecture diagram says.
The demo works on clean data. The deployment meets theirs. This stage is where most pilots quietly die.
Their data model is the real spec. It encodes the business rules nobody wrote down and nobody will tell you about.
How you get data out of a system whose owner left the company, without being allowed to change it.
A real FDE call: reuse the Postgres they already run and already trust, or ask them to adopt and operate a new dependency.
The AI-era FDE ships RAG, agents, and MCP servers. This is the spine of the job in 2026.
The single thing you are most likely to be asked to ship at a customer.
Your pilot dies on their data quality, not on your model. Know the failure shapes before the demo, not after.
Anthropic's FDE posting names the deliverable outright: MCP servers, sub-agents, and agent skills.
Deterministic rails around a probabilistic core. This hybrid is exactly how OpenAI's FDE lead describes shipping into enterprises.
It times out at 2am inside someone else's estate, and you own the outcome even though you own no pager there.
Evaluation-driven development is the FDE's actual method: build the eval before you build the thing, because the customer will ask for a number.
Build the eval before the agent. This is the single most repeated piece of method advice from people who run FDE teams.
The number you defend in the room, and the thing that stops last week's fix from breaking next week's demo.
Their finance team asks what this costs at full rollout. 'I'll find out' is a bad answer in a room you flew to.
Roughly 90% of sampled FDE postings sit in regulated industries: financial services, government and defense, healthcare, insurance, energy. Their security team, not their engineers, is what stands between you and production.
The gate. Every other stage is wasted if you cannot pass a review you did not write and cannot appeal.
One tenant retrieving another tenant's documents does not lose you a sprint, it loses you the account.
Their actual fear, stated plainly: that your model quietly walks their data out of the building.
Read this before you put an MCP server inside their estate, because their security team already has.
The isolation argument you will have to make out loud, to someone paid to disbelieve you.
The most common reason an FDE fails is not the code. Across ~1,000 sampled postings, 'working directly with customers' is the single most common responsibility.
They will ask. Answering honestly, sometimes against your own product, is what buys the trust you spend later.
You own the outcome and you own nobody. Every person who can unblock you reports to someone else, at a different company.
Their favourite feature is why the deployment is failing, and you are the one who has to say so, on site.
One warning that no other FDE page will give you: the three distinctive rounds below are all documented at Palantir, who publish more about their process than anyone else. Other companies copied Palantir's model, but their loops are not publicly documented, and where we could not verify something we say so rather than invent it.
The signature FDE round, and the one candidates prep least. An open, barely-technical prompt (the one public example asks how you would help elderly people with poor vision cook for themselves). It is product framing wearing an engineering hat. Palantir's own advice: deliver a functioning idea first, then expand it. Perfectionism reads as failure here.
Reading 500 to 1000 lines of code you have never seen and finding the bug. Candidates report a broken API service: trace the logs, find the bottleneck, fix the memory leak. Graded on making confident decisions without perfect understanding of the whole system.
Nearly unique to this loop. You are handed an unfamiliar library and asked to integrate it within minutes, with the interviewer as your only documentation. It grades learning velocity, not knowledge, which is why you cannot revise for it. The only prep is having done it before.
Yes, there is LeetCode, and believing otherwise is the fastest way to fail. Candidates report easy-to-medium difficulty, contextualised in something you are building for an end user. Graded on structure, naming, edge cases, and maintainability rather than optimal complexity, but you still have to write it.
Present, but not the same as decomposition and not a substitute for it. This loop splits what a normal SWE loop fuses: one round on the design, a separate round on framing the problem in the first place.
Confirmed to exist at Anthropic, whose published candidate AI-usage policy names take-homes directly. Widely claimed for others, but not verifiably. Assume it is possible, do not plan the loop around it.
Every prep site describes a round where you present to a skeptical enterprise architect. We could not verify it at a single company, and we are not going to pretend otherwise. The skill is real and is tested inside other rounds; the standalone round may not exist.
| Round | Tested? | Weight | What to expect |
|---|---|---|---|
| Decomposition | yes | high | The signature FDE round, and the one candidates prep least. An open, barely-technical prompt (the one public example asks how you would help elderly people with poor vision cook for themselves). It is product framing wearing an engineering hat. Palantir's own advice: deliver a functioning idea first, then expand it. Perfectionism reads as failure here. |
| Re-engineering / live debugging | yes | high | Reading 500 to 1000 lines of code you have never seen and finding the bug. Candidates report a broken API service: trace the logs, find the bottleneck, fix the memory leak. Graded on making confident decisions without perfect understanding of the whole system. |
| The learning round | yes | high | Nearly unique to this loop. You are handed an unfamiliar library and asked to integrate it within minutes, with the interviewer as your only documentation. It grades learning velocity, not knowledge, which is why you cannot revise for it. The only prep is having done it before. |
| Coding | yes | medium | Yes, there is LeetCode, and believing otherwise is the fastest way to fail. Candidates report easy-to-medium difficulty, contextualised in something you are building for an end user. Graded on structure, naming, edge cases, and maintainability rather than optimal complexity, but you still have to write it. |
| System design | yes | medium | Present, but not the same as decomposition and not a substitute for it. This loop splits what a normal SWE loop fuses: one round on the design, a separate round on framing the problem in the first place. |
| Take-home / prototype | unclear | varies | Confirmed to exist at Anthropic, whose published candidate AI-usage policy names take-homes directly. Widely claimed for others, but not verifiably. Assume it is possible, do not plan the loop around it. |
| Customer role-play | unclear | low | Every prep site describes a round where you present to a skeptical enterprise architect. We could not verify it at a single company, and we are not going to pretend otherwise. The skill is real and is tested inside other rounds; the standalone round may not exist. |
The section has the practice set: eleven drills across decomposition, re-engineering, and the learning round, each with the bands you are graded against. Exactly one real decomposition question circulates publicly. We wrote the other ten, and every question is free to attempt.