Anthropic FDE Interview Guide: Why the Company Is Spending Big on a New Class of On-Site Engineers
This isn't a hire for someone who can write clever prompts. It's a search for people who can get model capabilities, customer workflows, and safety boundaries all the way into production systems.
- Anthropic's current US FDE roles pay between $280,000 and $320,000 a year. The salary isn't for prompt skills—it's for the ability to get Claude working inside customer production environments.
- The full FDE loop is: discover a workflow, define risk boundaries, build, evaluate, ship, then feed field patterns back to product teams.
- Interviews really test whether five capabilities can combine in one person: production coding, agent architecture judgment, evidence from evals, customer management, and safety engineering.
Anthropic is hiring engineers for a somewhat unusual role.
These engineers won't just write code inside a frontier AI company; they'll work within client systems and alongside teams at banks, healthcare providers, government agencies, and large enterprises. The listed US salary for Anthropic's current FDE positions is $280,000 to $320,000 per year, plus equity.
Why would a company with frontier models pay a premium to hire people who work on-site with customers?
On the surface, this FDE interview guide appears to be preparing candidates for the hiring process. But what it really reveals is a more significant shift: as models become more capable, the scarcest skill in AI deployment is no longer the ability to call a model, but the ability to reshape a client's chaotic workflows into an evaluable, controllable, and deployable system.
Anthropic isn't paying a premium for prompt engineering tricks; it's buying the ability to carry model capabilities across the last mile.
What exactly is an FDE?
FDE stands for Forward Deployed Engineer—a role that embeds engineers directly with customers to build production systems.
The role was popularized by Palantir. It's not traditional on-site outsourcing, nor is it a pre-sales position that just draws architecture diagrams and gives demos. An FDE goes directly into the client environment to turn a vague business need into a working production system.
Anthropic places its FDEs within the Applied AI team. Official responsibilities include building production Claude applications within client systems, delivering MCP servers, sub-agents, and agent skills, providing enterprise deployment support, and feeding recurring field patterns back to the Product and Engineering teams.
Looking at the current job posting, the role comes into sharper focus:
- Responsibilities and qualifications: Requires experience with production LLM applications, solid Python skills, customer communication and discovery abilities, high autonomy, and a track record of delivering systems in enterprise environments;
- Key deliverables: Claude applications, MCP servers, sub-agents, Agent Skills, and deployment patterns that can be reused across clients;
- Current US salary: $280,000–$320,000 per year, plus equity;
- Work style: Expects about 25% travel to client sites and at least 25% of time in the office;
- AI use in interviews: You can use Claude to prepare, but live interviews are expected to be completed independently; assessments cannot be outsourced to AI unless explicitly allowed.
These aren't disconnected tasks; they form a continuous, end-to-end pipeline.
The final step is what distinguishes an FDE from a typical contractor. After a consulting project, insights often stay trapped in a report. After custom development, code might serve just one client. An FDE, however, must also ask: can the problem solved here be turned into an MCP, a Skill, an eval suite, or a product feature usable by the next hundred clients?
This makes the FDE role part of Anthropic's field-based product-development loop.
To understand why companies using the same model get wildly different results, look at deployment conditions, not just model parameters.
Why does a frontier AI company need FDEs?
Because there's a wide gulf between "the model is very capable" and "the enterprise can actually use it."
Say a bank approaches Anthropic with a request: "We want to build a compliance agent." While it sounds like a clear goal, it contains almost no actionable information. An FDE has to keep asking questions:
- Which specific compliance process?
- Who are the users: investigators, auditors, or relationship managers?
- Will the system only retrieve, summarize, and draft, or can it modify records, send messages, or even freeze accounts?
- Which systems hold the authoritative data, and is it complete, timely, and trustworthy?
- How do user permissions translate to the tools Claude calls?
- What's the real cost of a single wrong answer from the model?
- Which actions require human approval?
- Will success be measured by time saved, recall rate, false positive rate, or case completion rate?
The hard part isn't writing "You are a senior compliance expert." It's turning these questions into concrete mechanisms for identity, permissions, tool interfaces, data filtering, audit logs, evaluation tasks, human approvals, and rollback.
This is also the difference between context engineering and ordinary prompt engineering. Anthropic's definition of context engineering goes beyond prompts to include system instructions, tools, MCP, external data, message history, and the ever-changing state of the agent. Just because the model handles reasoning doesn't mean it should handle authentication, permission filtering, retries, data validation, or approval of high-risk actions.
Evaluation can't just check whether the final answer looks good. If the agent claims "the case has been updated," you need to verify whether the backend record actually changed, whether permissions were respected, and whether the audit trail is complete. Anthropic's agent eval framework separates the complete trajectory from the final environment state precisely because a successful claim doesn't equal a completed task.
So the FDE's job isn't just to integrate Claude into an enterprise; it's to decide the boundaries, the evidence, and the manner in which Claude enters that enterprise.
How is it different from similar roles?
FDEs are often mistaken for software engineers, solutions architects, AI application engineers, or consultants. They do absorb parts of each, but their primary output and failure modes are distinct.
The key difference isn't just the combination of technical and customer skills. FDEs also act as product scouts.
They stand at the collision point between model capabilities and customer reality. They often see earlier than internal product managers which tools are awkward, which permission models are missing, which agent behaviors are hard to evaluate, and which needs keep recurring across different clients.
This is also the dividing line between a senior FDE and an ordinary project deliverer. The former distills a single deployment into a reusable pattern; the latter might complete a project successfully but leave the next engineer to start from scratch.