Anthropic FDE Interview Guide: Why the Company Is Spending Big on a New Class of On-Site Engineers

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.

Related readingSame AI Model, Opposite Outcomes: Why Some Companies Compound Gains While Others Get NothingFour implementation principles, backed by real-world data from L'Oréal, Lyft, and Rakuten→

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.

What is the interview actually screening for?

Anthropic hasn't published a fixed process that applies to all FDE teams. Teams like Applied AI, Custom Agents, Federal, and Life Sciences face different clients and cases, so the rounds, their order, and the specific questions may vary. However, the original guide covers a fairly complete preparation scope, which can be mapped out as follows:

Each of these stages tests a different skill, but they're all answering the same underlying question:

Given a vague, sensitive, cross-system enterprise task, can you turn it into an AI product the customer is willing to trust, without a complete script to follow?

1. Can you actually write code?

FDEs aren't just there for meetings, requirements, and architecture diagrams. Anthropic's official job description is explicit: candidates need strong Python skills, ideally with proficiency in TypeScript, Java, or similar languages, and experience shipping production applications.

Don't prepare for this round like it's a LeetCode test. The original guide highlights question types that resemble real delivery much more closely:

Production ability isn't just about implementing the happy path. It covers APIs, authentication, permissions, pagination, timeouts, retries, idempotency, logging, tests, secrets management, and handling malformed data. Interviewers are also watching whether you proactively ask about input scale, dirty data, failure behavior, and how you'd define success.

A reliable approach for live coding rounds:

1. Restate the task in your own words to confirm your understanding;
2. Ask about input formats, data scale, authentication methods, latency requirements, and edge cases;
3. Define what success, failure, retry, and escalation should return before writing code;
4. Implement the simplest secure version; don't prematurely over-engineer;
5. Add tests for normal paths, edge cases, no-permission scenarios, duplicate data, and tool failures;
6. Explain production hardening: logging, observability, secrets, rate limiting, idempotency, and audit trails;
7. Place the code back into the client's workflow and explain how it connects to upstream and downstream systems.

A generic answer might be: "I'd build a RAG for the enterprise documents and have Claude call a search tool." A stronger FDE-style answer would also address: who handles document-level permission filtering? How do you recover from tool failures? What data doesn't need to be in the model context? How do you prevent duplicate write operations? How do you confirm that an action the agent claims it completed actually changed the backend state?

For example, if you're asked to implement a document search tool, a strong answer doesn't start coding right away. It first confirms whether permissions are enforced upstream or inside the tool. Even if upstream filters exist, you can verify ACLs again at the tool layer. Your results should only include fields the model needs to complete its task. Your tests should cover empty results, unauthorized documents, corrupted metadata, and duplicate IDs. This process demonstrates production judgment far more than saying "I used a vector database."

Interviewers aren't just checking if the code runs; they're checking whether a customer could trust that code.

2. Can you design agents without being seduced by them?

A seasoned candidate doesn't hear a requirement and immediately declare: "We're building a multi-agent system."

They first assess whether the task actually needs an autonomous loop, whether a standard workflow with a single model call would suffice, which parts must be handled by deterministic code, which decisions are best left to Claude, and which actions require human confirmation.

In this round, you might be asked to design an enterprise customer support assistant, a CRM MCP server, due-diligence sub-agents, or an Agent Skill for regulated reporting. You might also be asked to diagnose an agent stuck in a loop between two tools and repeatedly fetching stale data.

The knowledge you need isn't a list of product names. It's understanding the conditions under which each component is the right choice.

"I'll optimize the prompt" is no longer a sufficient answer. Candidates need to be able to discuss context selection, tool schemas, structured outputs, identity and permissions, state management, sandboxing, logging, failure recovery, and overall system complexity.

For a full system design question, a ten-step framework can help you move forward:

1. Clarify the workflow: Who does what, at what frequency, and what's the cost of failure?
2. Define success metrics: accuracy, completion rate, time saved, escalation rate, adoption, and safety indicators.
3. Map the data and systems: documents, databases, CRM, APIs, IAM, owners, and data freshness.
4. Set the action boundaries: decide how far the system may go—from read-only access and drafting to recommendations, writes, and automatic execution.
5. Choose the architecture: how do Claude, retrieval, tools, MCP, Skills, sub-agents, and deterministic code divide the work?
6. Add security controls: authentication, least privilege, secrets, PII, data flow, and audit.
7. Design the eval: golden tasks, edge cases, trace review, outcome graders, and a regression set.
8. Design observability: tool failures, loops, latency, cost, user feedback, and production status.
9. Plan the rollout: pilot users, human review, pass thresholds, expansion criteria, and rollback.
10. Close the product loop: which capabilities are reusable, and which platform gaps should be fed back to Product and Engineering.

A strong answer usually makes a clear division of labor: authentication, permission filtering, retries, and data validation go to deterministic code; Claude handles the parts that require semantic understanding and reasoning; tools expose only narrow interfaces; and high-risk write operations require human approval. Start with a single workflow as a pilot, examine real traces and outcomes, then decide whether to grant the agent more autonomy.

Often, the best agent design is the one that removes an unnecessary agent.

3. Can you turn "it works well" into evidence?

An agent saying "the task is done" doesn't mean the task is actually done. The right thing to verify might be whether a record appeared in the database, whether a file was generated correctly, whether a ticket reached its target state, or whether a user's permissions were actually applied.

Anthropic's official explanation of agent eval distinguishes between task, trial, grader, trace, and outcome. Capability evaluation answers "what can the system do now?" while regression evaluation answers "can it still reliably do what it used to do?"

If you're asked in an interview to design an eval for a customer support agent, a compliance assistant, or a report generation system, a six-step answer works well:

1. Define tasks from real workflows, not from "the answer looks good."
2. Build a golden set from historical cases, then add edge samples like missing data, conflicting sources, insufficient permissions, and tool failures.
3. Choose a grader per objective: rule validation, state checks, human scoring, or model scoring.
4. Run the same task multiple times to distinguish occasional success from stable ability.
5. Check both trace and outcome: how it completed the task, and whether the backend result is actually correct.
6. Slice failures by type to form a regression set and rollout thresholds.

Metrics have to follow the task. For customer support, look at resolution accuracy, citation quality, escalation precision, tool success rate, latency, and user adoption. For compliance scenarios, you also need evidence completeness, policy citation, false escalation risk, hallucinated facts, and audit completeness. High-risk write operations shouldn't rely on a language grader alone—check the database, files, tickets, or permission states directly.

So candidates can't just show a few success screenshots. They need to answer: Which real tasks does the system succeed on? Is the same task stable across repeated runs? Which failure mode is most common? Do capabilities regress after changing models, tools, or context policies? Is the final business state actually correct? Who decides the rollout threshold, and how does the system degrade or roll back when the bar isn't met?

Without eval, "it works well" is usually just the presenter's feeling.

4. Can you manage the customer, not just comply with them?

This capability is already being assessed at the recruiter screen. You should prepare for five types of questions: why Anthropic, why FDE instead of SWE or Solutions Architect, the most mature production AI system you've worked on, the hardest customer deployment, and how you think about safe AI implementation.

A weak answer is "I've built Claude chatbots," "I have customer experience," or "I know prompt engineering." A strong answer walks the full chain: what workflow the customer originally needed to solve, how you found the real bottleneck, which integrations you built yourself, how you handled permissions and risk, what eval you used to decide readiness, and what outcome or product feedback resulted.

When a customer says "we want to roll out autonomous agents company-wide in 30 days," the FDE's job isn't to nod and sprint.

Strong candidates work through eight discovery dimensions first:

Then narrow the goal down to a single workflow, a set of real users, a limited permission scope, a batch of historical test tasks, and explicit rollout criteria. The first version might only allow read and draft, not auto-execution. High-risk actions require human approval. The system only expands once accuracy, tool success rate, risk metrics, and user adoption meet the agreed bar.

Behavioral interviews follow the same chain. Plain STAR isn't enough; add a final Learning element:

Prepare stories that cover end-to-end ownership, ambiguous requirements, architecture changes, customer conflict, security trade-offs, failure, product feedback, cross-functional collaboration, and fast learning. Don't prepare ten unrelated anecdotes. More effective is three to five information-dense case studies you can tell from different angles.

Levels aren't demonstrated by titles either:

The value of an FDE isn't in accepting everything you're asked to do. It's in finding the customer's real problem and stopping a wrong solution from shipping faster.

5. Can you build security into the architecture?

For Anthropic, "I believe in AI safety" is not a valid answer.

Real safety judgment translates into least privilege, sensitive data boundaries, tool call scoping, human approval for high-risk actions, audit trails, rollout evaluation, production monitoring, anomaly escalation, and rollback mechanisms.

A medical agent that merely helps doctors organize literature and one that can directly modify a patient's medication record cannot use the same rollout standard. Same capability, different action permissions, completely different risk level.

The FDE needs to define what the system can read, what it can decide, what it can write, and where it must stop and hand off to a human. That's security engineering.

This round's common questions fall into five categories:

Don't perform mission alignment when answering. First acknowledge the business value, then make the risk concrete: what data the system touches, what actions it can take, who is affected by a failure, what the existing eval can demonstrate, where human approval is needed, and how degradation gets monitored. End with actionable options: narrow the scope, switch to read-only or draft-only, add approval steps, delay the rollout, or expand gradually once there's enough evidence.

If you have four weeks, here's a preparation sequence:

The most worthwhile portfolio piece isn't a chatbot — it's a small production workflow. Pick one scenario — customer support triage, sales research, compliance review, document Q&A, or code modernization — and deliver at minimum: Claude integration, one or two narrow tools, a clear permission boundary, structured output, golden evals and edge evals, trace logging, latency and error tracking, a documented security model, pilot metrics, a go-live threshold, and a rollback plan. Also note which findings could be productized into reusable capabilities.

Finally, before starting the formal process, ask the recruiter these questions:

The original guide identifies the most common failure as candidates proving strength in only one dimension:

The FDE interview is essentially testing whether all these capabilities can coexist in one person.

The bigger picture

Anthropic's creation of the FDE role isn't just another high-paying job posting. It signals that competition among frontier model companies is shifting from who has the most capable model to who can get models working inside the most complex, expensive, and sensitive real-world workflows.

Model capability is becoming easier to access, but customer environments don't get cleaner because of it:

• Every company has different identity and permission systems;
• Enterprise data is often incomplete, duplicated, stale, or contradictory;
• Actual workflows rarely match what management believes they are;
• Security, legal, IT, procurement, and business units all have conflicting goals;
• Agent failures often emerge across multiple tools and multi-turn state;
• A successful demo is still far from organizational adoption.

What makes FDEs scarce is a hard-to-standardize blend: deep coding ability, organizational understanding, the drive to move deployments into production, and the restraint to limit automation. They solve one customer's problem without dragging the company into endless custom development.

The role also serves as a frontier AI company's on-the-ground learning loop. If multiple customers request the same permission controls, the platform may be missing a unified authorization capability. If several agents fail on the same tool call, the tool design may be at fault. If a certain workflow can't produce reliable evals, the product may not yet be ready to promise automation.

That information — flowing from customer sites back to product and engineering teams — is what turns into next-generation platform capabilities. FDEs aren't at the tail end of the delivery chain; they're the people who loop the field back into the start of the product cycle.

And that leads to the guide's most counterintuitive conclusion:

The more general AI becomes, the more the last mile demands highly skilled people.

Not because Claude isn't smart enough. Because messy enterprise reality can't be tidied up by a generic prompt.

The FDE is the person standing in that chaos, turning model capability into trustworthy outcomes.