The Anthropic FDE interview: use the job posting as your study plan for each round

You open Anthropic’s posting for a Forward Deployed Engineer in London and come across a line that is easy to skim past: spend 25-50% of your time travelling to customers to build directly alongside them. At first glance it is a logistics detail. In fact it tells you the role needs someone who can build in front of a customer, not just someone who is good at algorithm puzzles.

The most effective way to prepare, then, is to use the posting itself as your syllabus and match each requirement to the round most likely to test it.

The job posting is a syllabus, not an advert

According to the posting, the role sits in the Applied AI team. FDEs build production applications with Claude inside customers’ own systems. What they deliver is concrete: MCP servers, sub-agents and agent skills. That is a list of things you must be able to build yourself, not just name.

The requirements are just as direct. Candidates need 4+ years of experience in a technical, customer-facing role, such as FDE.

They need production experience with LLMs, including advanced prompt engineering and agent development. They need strong Python, and the posting wants someone highly self-directed who can find their way through large, multi-layered and ambiguous organisations.

Each of these requirements can be matched to the round most likely to touch it. So the first thing to do is not to open a coding practice site but to build that mapping.

Four rounds, each testing one capability

An interview-prep guide from Exponent/Aced sets out a sample process for this role. The first round is a 30-minute recruiter call about your background, motivation, references and the right level for you.

Next comes the technical screen, built around a realistic scenario: deploying Claude with MCP tools and keeping the system stable when the context gets very long.

The coding round, according to the same guide, is a step-by-step practical exercise on a CodeSignal-style platform, with a new requirement added at each step.

The final panel combines two parts: solution design, meaning the architecture of a Claude system for a customer, and questions on behaviour and company values.

This is a sample process, not a fixed schedule, so ask your recruiter about the order of your own rounds.

Line in the posting	Round likely to test it	How to prepare
Delivering MCP servers, sub-agents, agent skills	Technical screen	Build a small MCP server that connects Claude to a real data source
Advanced prompt engineering, agent development	Technical screen, design	Prepare a set of test cases to compare two prompt versions
Strong Python	Incremental coding round	Practise writing small, extensible functions with tests for each step
Finding your way when things are unclear	Design, behavioural	Practise asking clarifying questions before drawing an architecture
4+ years working with customers	Recruiter, behavioural	Have three stories ready, each with a customer, a conflict and an outcome

Example: a coding exercise that adds a requirement at each step

Imagine the following problem. It is a practice exercise, not a real interview question. Step one: take a list of support tickets as JSON and group them by customer. Step two: remove tickets with duplicate content. Step three: before sending to the model, trim them so that each customer’s total length stays under a threshold.

The trap is writing step one as a single long function. By step three you have to tear it apart and rewrite it while the clock is running. The safer approach is to make each requirement a pure function, so that a new requirement only asks you to add one link to the chain:

from dataclasses import dataclass
from collections import defaultdict

@dataclass(frozen=True)
class Ticket:
    id: str
    customer: str
    created_at: str  # ISO 8601, e.g. "2026-03-01T09:30:00Z"
    text: str

def load(rows: list[dict]) -> list[Ticket]:
    return [Ticket(r["id"], r["customer"], r["created_at"], r["text"].strip())
            for r in rows]

def dedupe(tickets: list[Ticket]) -> list[Ticket]:          # step 2
    seen, out = set(), []
    for t in tickets:
        key = (t.customer, t.text.lower())
        if key not in seen:
            seen.add(key)
            out.append(t)
    return out

def group(tickets: list[Ticket]) -> dict[str, list[Ticket]]:  # step 1
    groups = defaultdict(list)
    for t in tickets:
        groups[t.customer].append(t)
    return dict(groups)

def budget(groups, max_chars: int):                            # step 3
    trimmed = {}
    for customer, items in groups.items():
        total, kept = 0, []
        # newest first: ISO 8601 strings in one timezone sort chronologically
        for t in sorted(items, key=lambda t: t.created_at, reverse=True):
            if total + len(t.text) > max_chars:
                break
            kept.append(t)
            total += len(t.text)
        trimmed[customer] = kept
    return trimmed

def pipeline(rows, max_chars=4000):
    return budget(group(dedupe(load(rows))), max_chars)

In step three the code sorts by when each ticket was created, not by id, because a higher id is not necessarily a newer ticket. If the data has no timestamp field, state your assumption clearly before falling back to the id.

What earns the marks is what you say while coding, not the code itself. Spell out your trade-offs: you keep the newest tickets because you assume they are more relevant, and you would check with the customer if that assumption turned out to be wrong.

This context-budget problem is also close to the long-context stability question at the heart of the technical screen.

The design round: ask first, draw later

Because the posting stresses the ability to find your way when things are unclear, expect the design prompt to leave out a lot of detail, and practise the habit of asking before drawing.

Imagine the interviewer says: “An insurer wants its staff to ask Claude about policy terms.” Rather than immediately sketching a diagram with a vector database, you can ask a few questions first.

You might open with three: “Who will use it, call-centre staff or the claims department? Which system do the policies live in, and does it have access controls? If Claude answers wrongly, is the result an irritated caller or an incorrect payout?”

Only after those three questions do you propose an architecture: an MCP server that respects the existing access controls, a sub-agent dedicated to citing policy clauses, and a set of test cases built from real staff questions.

Behavioural and deep-dive rounds: real stories beat polished ones

Educative’s guide to Anthropic’s engineering hiring process in general notes that the technical deep-dive favours people who genuinely understand the systems they have built. In behavioural rounds, interviewers tend to value honesty, self-awareness and reflection over polished success stories.

In practice, prepare at least one story about a deployment of yours that failed. Cover the technical cause, the decisions you made and what you did differently afterwards. If you can still explain yourself when pushed two layers deeper, that story is worth more than ten projects described only on the surface.

This is also the place to fix your CV. Don’t write a vague “experience with LLMs”. Write that you built an MCP server connecting a model to which system, who it ran for, and how you measured its quality.

Specific lines like these do not replace the 4+ years of experience the posting asks for. They simply let the reader see straight away what you did with those years.

Rules on using Claude: know them in advance

Anthropic has published official guidance on candidates’ use of AI. You may use Claude to refine your application, but you must write the first draft yourself. You may use Claude to research the company, practise your answers and prepare questions for your interviewers.

The line falls at the assessments themselves. Live interviews are “all you”, with no AI assistance unless the interviewer says otherwise. Take-home assignments are also done without Claude unless permitted.

That may sound paradoxical for a role spent working with Claude all day, but the sensible reading is that they want to see your underlying ability without an assistant at your side.

Mistakes that sink strong candidates

The first common mistake is preparing for the wrong kind of test: spending weeks on algorithms when the technical round, according to the sample process, is a scenario about deploying Claude with MCP. The next is writing code as one solid block, so that every new requirement forces a rewrite.

Then there is jumping straight into architecture while the design prompt is still open-ended, skipping exactly the ability to navigate ambiguity that the posting spells out.

The remaining two mistakes are about people. One is telling stories that are too perfect, so the listener cannot find anywhere you actually learned something.

The other is using Claude where it is not allowed, for instance in a take-home assignment without permission. That costs you trust, and in a role that depends on customers’ trust, losing it means losing everything.

This week’s exercise: ask a colleague to play the interviewer and give you only a deliberately vague design prompt, such as “a hospital wants to use Claude for its reception desk”.

Set a 30-minute timer. For the first 10 minutes you may only ask questions, not draw anything. Afterwards, ask your colleague which of your questions clarified the problem most.