Anthropic · Study
Anthropic Machine Learning Engineer Interview Process
TrueInterview
July 24, 2026 · 16 min read
Anthropic's Machine Learning Engineer loop tests whether you can build and debug training and serving code, not how much modeling you know. The technical screen is often picked from a short menu: reinforcement-learning debugging, a stateful data batcher, prompting and LLM engineering, or agentic coding. Recruiters choose the one that fits your background, so two candidates for the same team can sit very different screens. The design round asks about scaling, observability and GPU memory bandwidth, not model architecture. A separate culture round asks for your own critique of Anthropic's safety positions and carries real weight in the decision.
This guide breaks down each stage of the Anthropic Machine Learning Engineer interview, what interviewers evaluate in each round, and how to prepare, with questions candidates were actually asked.
Verified: Based on 22 candidate-reported interview experiences, primarily from 2025 Q3 through 2026 Q3, cross-checked against recent public accounts.
Anthropic Machine Learning Engineer interview process

This track covers Machine Learning Engineer, Research Engineer, data infrastructure and some fellowship roles, and the loop depends on the team. Training teams screen on reinforcement-learning mechanics and data pipelines. Applied teams screen on prompting and agents. Data infrastructure screens are pure system design and require no machine-learning knowledge. Most candidates sit one or two screens, then a virtual onsite of four or five rounds. Stages are often two to three weeks apart, so the process usually takes one to two months.
Senior candidates get design prompts with no stated scope and are expected to bring capacity numbers unprompted; some skip the screens entirely.
Here's what the interview process can look like:
- Recruiter screen: A 15 to 30 minute call on background and motivation that often fixes the format of the technical screen.
- Online assessment (many applied and MLE pipelines): A timed, four-level Python build, recently a recipe problem, scored automatically.
- Coding and design interviews: Hour-long notebook sessions such as a weighted data batcher, a longest-match tokenizer or a concurrent web crawler.
- ML fundamentals and RL debugging screen (training teams): Planted bugs in a policy-optimization snippet, then training dynamics line by line.
- Prompting and LLM engineering screen (applied teams): About 55 minutes of live prompt iteration, agent building or agentic-coding repair.
- ML system design interview: A broad production prompt, usually inference serving, sometimes a design-doc review.
- Behavioral and culture interviews: A project deep dive and a separate conversation on safety and mission.
Tip: Ask the recruiter which screen format you will get and what it covers. Recruiters for this track have shared specific preparation topics and changed the format to fit a candidate's background. Without that answer you are preparing for four different rounds.
Recruiter screen
The first call typically runs 15 to 30 minutes: your background, why Anthropic rather than another lab, the team, location and timeline. On this track it also decides the technical screen. One posting presented the technical assessment as a choice of four options. A candidate with an engineering-heavy background was moved from a research-style screen to an agentic-coding round. Another got concrete topics for the phone screen but no hint of the onsite design prompt.
Interviewers evaluate:
- Specific motivation: Reasons tied to Anthropic's safety work and products. Enthusiasm that would fit any AI lab earns little.
- Team fit: Whether your experience matches RL training, inference, data infrastructure or applied LLM work.
- Practical constraints: Willingness to be in the office part of the time and to work at the expected pace.
- Accurate self-description: A clear account of your strengths, which the recruiter uses to pick the screen.
Prepare a two-minute account of the ML systems you have built, and ask about the screen format and topics.
Note: Team assignment is easier to change early. A candidate who saw a poor match with the assigned team planned to ask for a different one before the next round. Raise it on the first call, not after the onsite.
Sample questions for the recruiter screen
Here are some questions reported by recent candidates:
-
Why Anthropic specifically, rather than another frontier lab?
-
What have you built in machine learning, and which part did you personally own?
-
Which format suits you best: ML coding, RL fundamentals, prompting and LLM engineering, or agentic coding?
Online assessment
Many applied and Machine Learning Engineer pipelines start with a timed Python assessment, typically 90 minutes. You build one practical system in four levels, and each level unlocks after the previous one. In 2026 the Machine Learning Engineer version was a recipe problem. One variant asks for a valid, minimal sequence of transformations that turns ingredients into a target dish. Another builds a recipe manager in four steps: case-insensitive unique names, search sorted by ingredient count with ID tie-breaks, owner-checked edits, and version history with rollback. Scoring is automatic; one candidate reported a perfect 600 of 600.
Another version had an LLM-related problem with a bug in its third part. A candidate on that version spent too long debugging, found copy and paste restricted, ran out of time and was rejected. Finishing several levels with clean code counts for more than meeting every requirement, and an unfinished early level blocks all the later ones.
Interviewers evaluate:
- Invariants from level one: Case rules, uniqueness and tie-breaks that the later levels depend on.
- State-transition modeling: Turning a large space of operations into explicit states and valid moves.
- Code that absorbs change: Data structures that let versioning or ownership slot in without a rewrite.
- Pace in a plain editor: Working code without autocomplete or easy copy and paste.
Practice four-level builds against a 90-minute clock in a plain editor, reading every level before writing code.
Sample questions for the online assessment
Here are some questions reported by recent candidates:
-
Given transformation rules, find a valid, minimal sequence of steps that combines starting ingredients into a target dish.
-
Build a recipe manager whose rollback creates a new version and fails if the restored name collides with an existing recipe.
-
Finish a multi-part LLM-related implementation whose third part contains a bug.
Coding and design interviews
Coding rounds last about 55 to 60 minutes in a shared Colab notebook, in Python, with no AI assistance. The best-known problem is the weighted data batcher, which one candidate called a fair sample of the team's real infrastructure work. You build on a supplied data registry that returns an iterator for each dataset name, in three parts:
- Yield batches of indices under per-dataset weights.
- Add an offset for reproducibility and sharding, plus exact checkpoint and resume.
- Drop the guarantee that the batch size divides the weight sum, and handle the leftovers without bias or lost data.
Discussion-only follow-ups cover weights changing between saves, sharding, weight lists too large for memory, and testing determinism. Some loops add ML configuration questions.
Other problems are just as practical. A tokenizer does longest-match lookup against a vocabulary, falls back to an unknown token, merges consecutive unknowns, and bounds its lookahead by the longest vocabulary entry. A web crawler starts as single-threaded BFS and moves to a thread pool, filtering by hostname and stripping URL fragments. Other screens use profiler stack traces with hidden prefixes, solved with two pointers, or the mode and median of numbers spread across many workers.
Interviewers evaluate:
- Explicit, serializable state: Exactly which counters, offsets and remaining weights must be saved to resume at the same position.
- Generalizing without regressions: Relaxing an assumption without breaking the offset and resume logic built on it.
- Unprompted optimization: Bounding the tokenizer's lookahead or cutting communication in the distributed median before being asked.
- Practical edge cases: URL fragments, hostnames, runs of unknown characters and uneven final batches.
Build a small checkpointable iterator from scratch, add each relaxation in turn, and test that a resumed run matches an uninterrupted one.
Tip: Write the batcher's first part as if save and resume were already required. Part one is explicitly stateless. From part two every counter must be serializable, and part three removes the divisibility guarantee the earlier logic relied on. Candidates say the follow-ups on resume and corner cases decide the round, not the sampler itself.
Sample questions for the coding and design interviews
Here are some questions reported by recent candidates:
-
Build a weighted sampler over a data registry, then add an offset, exact checkpoint and resume, and batch sizes that do not divide the weight sum.
-
Tokenize text by longest match, emit one unknown token per run of unmatched characters, and bound the search by the longest vocabulary entry.
-
Crawl one host from a start URL with BFS, then make it concurrent with a thread pool without crawling fragment variants twice.
ML fundamentals and RL debugging screen
Training teams use a screen that opens as a code review. You get a short policy-optimization snippet with planted faults, often three. Reported faults:
- A missing softmax before multinomial sampling, which produces NaNs.
- An advantage normalization with no epsilon on the standard deviation, which divides by zero when every reward in a group is equal.
- A policy ratio computed as a difference of log-probabilities instead of their exponentiated ratio.
Training dynamics follow: why PPO and GRPO clip the ratio, exactly when clipping triggers and what it does to the gradient, and why the ratio should equal one at a given line but did not. GRPO's trade-offs and variants come last.
Other versions open with transformer architecture, sampling temperature and a run that will not converge, or ask for attention in PyTorch. A performance-focused screen asked for the FLOPs of a matmul, its arithmetic intensity, and whether it is compute-bound or memory-bound on an A100 40GB. It then asked whether a 72-layer network with two alternating layer types fits in 40GB.
Interviewers evaluate:
- Mechanism, not vocabulary: Why each bug degrades learning or crashes the run, not just its name.
- Clipping precision: The sign-dependent conditions under which the clipped term becomes active, and its effect on the gradient.
- Numerical-stability instincts: Spotting missing epsilons, log-space errors and unnormalized logits on sight.
- Back-of-the-envelope rigor: Correct FLOP, byte and parameter counts across layer types, with nothing counted twice.
Write a small GRPO loop yourself, break it in each of the ways above, and watch what each break does to the loss and the ratio.
Note: Knowing what GRPO is buys almost nothing here. Candidates call the follow-ups deceptively deep, and a rejected candidate was pressed on why the ratio was not one after finding the planted bugs. Research-leaning teams may also give a timed take-home. One interpretability take-home allowed four hours to reproduce sample-wise double descent, analyze it with random matrix theory, show regularization removing the peak, and present the result as slides.
Sample questions for the ML fundamentals and RL debugging screen
Here are some questions reported by recent candidates:
-
A GRPO snippet produces NaNs; find the missing softmax before sampling and the unprotected division in advantage normalization.
-
What happens if the ratio is the new log-probability minus the old one, and when exactly does clipping activate?
-
Decide whether a large matmul on an A100 is compute-bound or memory-bound, then check whether a 72-layer network fits in 40GB at two bytes per parameter.
-
Mechanistic Interpretability Take-Home — Sample-Aspect Double Descent
Prompting and LLM engineering screen
Applied pipelines use this screen in place of the RL screen. In 2026 it was most often a 55-minute prompting and LLM engineering session in Colab. You refine prompts, few-shot examples and output formats until a model performs a non-trivial task reliably, while the interviewer adds constraints and edge cases. Other versions are different exercises:
- Build an agent on the Anthropic API that defines tools, handles tool-use responses, keeps conversation state and loops until it is done.
- Agentic coding: fix a broken agent, then make it answer every question within two turns, then within one.
Output parsing and malformed-response handling are graded too. One candidate finished all three agentic-coding parts in 55 minutes after rehearsing a near-identical prompt and was still rejected a week later. Finishing every part does not guarantee a pass.
Interviewers evaluate:
- Systematic experimentation: One change at a time, each tied to a named failure mode and a way to measure it.
- A working model of the LLM: Why the model produced this output, and which change fixes the edge case.
- Correct tool-use mechanics: Tool definitions, handling of tool-use responses, and a loop that ends cleanly.
- Robust surrounding code: Validation and fallbacks when the output does not match the expected format.
Build a small tool-using agent on the Anthropic API beforehand, and practice explaining aloud why each prompt revision fixes a specific failure.
Sample questions for the prompting and LLM engineering screen
Here are some questions reported by recent candidates:
-
Refine a prompt in a notebook until the model performs a specified task reliably, adapting as the interviewer adds edge cases.
-
Build an agent with the Anthropic API that executes the model's tool calls and loops until it returns a final answer.
-
Fix a broken agent, then make it answer all questions within two turns, then within one.
ML system design interview
Most onsites include one design round of about an hour. The prompt is broad and stays on production concerns: one candidate expecting a modeling discussion was asked about scaling, infrastructure, observability and optimization instead. The most common prompt is an inference API. Interviewers press on why GPU inference is memory-bound rather than compute-bound and how batching keeps accelerators busy.
Some loops use a design-doc review instead. In one, a document added a batching layer and a load balancer in front of an inference service, with 100 ms per batch at 10,000 QPS. The candidate found two or three flaws first. The deep dive then covered batching, server count, load shedding and circuit breaking, and scheduling across model types. Data infrastructure candidates at the Q5 level had a design-only screen: ingestion, processing, storage, access control, cost estimation and fault tolerance.
Interviewers evaluate:
- Scope negotiation: Clarifying questions that turn a deliberately vague prompt into concrete requirements.
- Hardware-grounded reasoning: Memory bandwidth, batch size against latency, and GPU utilization rather than generic web patterns.
- Capacity math: Server counts derived from a latency budget and a throughput target.
- Overload and multi-tenancy: Load shedding, circuit breaking and fair scheduling across models.
- Critical reading: Finding flaws in someone else's design before proposing your own.
Practice sizing an inference fleet from a latency budget and a QPS target, and practice critiquing an existing design doc.
Note: Design-doc reviews catch candidates who only practiced designing from scratch. A candidate in another track did well in coding but called the review the weakest round of the loop. On this track, the reported review was about inference serving.
Sample questions for the ML system design interview
Here are some questions reported by recent candidates:
-
Design an inference API serving system and explain why GPU inference is memory-bound and how batching changes that.
-
Review a design that batches and load-balances an inference service at 100 ms per batch and 10,000 QPS, then size the fleet and handle overload.
-
Design data infrastructure that ingests from many sources, enforces access permissions and estimates its own cost.
Behavioral and culture interviews
The onsite has two people-focused conversations. The project deep dive covers one substantial piece of work: team size, duration, your role and impact, and how you handled pushback. The culture round focuses on AI safety. Reported questions ask for your view of Claude's constitution, a real critique of Anthropic's safety positions, how you handle being wrong, your concerns about deploying LLMs, and the Long-Term Benefit Trust. Scenario questions ask whether you would delay a risky breakthrough and what happens if others do not. There is no fixed answer; follow-ups test whether your reasoning stays consistent.
This signal can decide the outcome on its own. A candidate in another track passed every technical round, got an extra culture interview because the first signal was weak, and was rejected after the hiring-manager conversation that followed.
Interviewers evaluate:
- Independent thinking on safety: A reasoned critique of Anthropic's own positions rather than agreement with the company line.
- Coherence under follow-up: Views on risk, delay and competition that hold up through several hypotheticals.
- Ownership: Your own decisions and their outcomes, separated from the team's.
- Changing your mind: A specific case where evidence moved you, and what you did next.
Read Anthropic's constitution and governance material, form one critique you can defend, and prepare one project you can discuss for 45 minutes.
Tip: Agreeing with Anthropic without any critique counts against you. Interviewers want a specific disagreement backed by reasons; candidates report that unconditional support does not score well.
Sample questions for the behavioral and culture interviews
Here are some questions reported by recent candidates:
-
What do you think of Claude's constitution, and where would you critique Anthropic's approach to safety?
-
If a major breakthrough had unknown risks, would you delay it, and what if competitors did not?
-
Describe your most substantial project: the team, your role, a conflict you resolved and the outcome.
-
Reason About Delaying an AI Breakthrough Under Uncertain Risk
How Anthropic levels and evaluates Machine Learning Engineer candidates
A hiring committee weighs technical, project and culture signal together; strong technical rounds do not offset a weak culture signal. The level is set after the committee decides and appears in the offer, since engineers mostly share the Member of Technical Staff title. The hiring-manager conversation, now often after the full loop and before team matching, can still end the process.
References, typically a former manager and a current colleague, are checked before the offer and can still end a candidacy: one candidate was rejected after references were contacted. Rejections rarely include feedback.
How to prepare for the Anthropic Machine Learning Engineer interview
- Confirm your screen format first: Ask the recruiter whether you will get RL fundamentals, ML coding, prompting and LLM engineering, or agentic coding, and prepare that one in depth.
- Implement GRPO and break it: Remove the softmax, drop the epsilon, compute the ratio in log space, and explain each effect on the loss, the ratio and clipping.
- Build a checkpointable weighted batcher: Support an offset, exact resume and non-divisible batch sizes, and test that a resumed run matches an uninterrupted one.
- Do the hardware arithmetic by hand: Matmul FLOPs, arithmetic intensity, roofline bounds, parameter memory, and fleet size from a latency budget.
- Treat inference serving as the default design prompt: Batching, memory-bound decoding, overload and multi-model scheduling, plus critiquing an existing design doc.
- Practice live prompt iteration and agent loops: Build a tool-using agent on the Anthropic API and explain each prompt change by the failure it fixes.
- Rehearse four-level builds in a plain editor: Get the level-one invariants right, because every later level depends on them.
- Form your own view of Anthropic's safety choices: Prepare one reasoned critique and test it against follow-up questions, and brief your references early.
About the Anthropic Machine Learning Engineer role
Machine Learning Engineers and Research Engineers at Anthropic build the systems that train, evaluate and serve Claude: data pipelines and samplers, RL training infrastructure, evaluation tooling, inference performance, and agentic applications. Candidates describe the interview exercises as close to the real work. Many Research Engineer postings do not require a PhD. Candidates report weeks of about 60 hours, and remote employees are expected in the office about a quarter of the time, roughly one week a month.
Anthropic hires Machine Learning Engineers across research and product. Teams include:
- Pretraining: Scaling distributed training of large language models, including multimodal work at some locations.
- Post-training and RL: Fine-tuning, reinforcement learning, training environments and RL infrastructure.
- Inference: Performance of the systems that serve Claude, including batching and accelerator efficiency.
- Interpretability: Infrastructure for reverse-engineering how trained models work.
- Safeguards: ML systems for detecting and preventing misuse.
- Data infrastructure: Ingestion, processing, storage and access control for training and evaluation data.
Machine Learning Engineer experience and education requirements
Postings ask for strong Python engineering and experience with large-scale ML systems, plus hands-on PyTorch or JAX work for training roles. Only a small share of Research Engineer postings require a PhD; some ask for a bachelor's degree or equivalent experience. Interviews are in Python, in shared notebooks, and onsites have been fully virtual.
FAQs about the Anthropic Machine Learning Engineer interview
How long does the Anthropic Machine Learning Engineer interview process take?
Typically one to two months. Stages are often two to three weeks apart, and some candidates waited longer after the assessment. Reference checks and team matching can add one to two weeks after the onsite.
What is the hardest round of the Anthropic Machine Learning Engineer interview?
For training-focused candidates, the RL debugging screen, whose follow-ups on clipping, ratios and GRPO variants require hands-on precision. For applied candidates, the open-ended system design round, which turns to production scaling and GPU behavior. Across the loop, the culture round causes the most unexpected rejections.
Is there an online assessment?
Many pipelines start with one: a 90-minute, four-level Python build, recently a recipe problem. Experienced candidates have skipped it, and some research tracks use a take-home instead.
Can you use AI tools during the interview?
Not in live interviews or take-homes unless explicitly allowed. Using Claude to prepare, or to polish an application you drafted yourself, is permitted.