Anthropic Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Anthropic:

• They hire people who can ship excellent code AND reason honestly about hard, open-ended problems.
• Pure LeetCode speed is not enough. Pure "big thinker" is not enough. You need both, plus a genuine reason to care about safe AI.
• The loop is built to catch single-axis candidates, and it catches them most of the time.
• In practice they fail in the behavioral or the follow-up moment, not in the first clean solve. A smooth opening round does not mean you are through.

2Getting the call (the part most guides skip)#

Anthropic gets flooded with applications. Some reqs clear thousands of applicants, and a human may spend 20 to 30 seconds on your resume. The filter is brutal. Here is how people actually get in.

Referrals matter a lot.

• A referral moves you from the slush pile to a human reader, and often routes you straight to the hiring team instead of general recruiting.
• If you know anyone there, ask.
• If you do not, the next best thing is public work: a thoughtful blog post, a real open-source contribution, an eval or tool people actually use.
• Anthropic engineers read that stuff. More than one hire started with "I saw your repo."
• A referral plus one piece of credible public work beats a cold application with a perfect resume almost every time. Spend your energy there first.

Write bullets that show scope and numbers.

• Weak: "Worked on backend services for the ML team."
• Strong: "Rebuilt the training-data ingestion pipeline in Python, cut per-epoch data load time from 40 min to 6 min, unblocking 12 researchers running daily experiments."
• Every bullet should answer "how big, how much better, who cared." No number and no outcome: cut it or fix it.
• Aim for 4 to 6 bullets per recent role, front-loaded with the one result you are proudest of. The 20-second skim rarely reaches bullet five.

ATS keywords that help (only if true):

• Python, PyTorch/JAX, distributed training, CUDA, inference, LLM, RAG, evaluation/evals, Kubernetes, Ray, large-scale data pipelines, latency, throughput.
• Match the exact words in the job post. The parser is literal: if the post says "evals" and your resume says "model evaluation," spell out both at least once.

What gets you shortlisted:

• Evidence you have worked near real ML systems or shipped production software at scale.
• Writing that reads like you think clearly. Anthropic values writing more than almost any company.
• A good cover note, a sharp README, or a tight design doc you can link does more than you expect.
• A two-paragraph note naming a specific problem you want to work on, in plain language, beats a page of adjectives. If your public writing is sloppy, fix it before you apply.

3The loop at a glance#

What the onsite feels like:

• Mostly practical. Anthropic leans toward "here is a real-ish problem, work it with me" over abstract whiteboard trivia.
• You will often share a real editor, run your code, and get a follow-up requirement dropped on you halfway through.
• The format rewards people who ship, not people who recite.
• One move before the onsite: ask your recruiter for the exact panel and the flavor of each round. The research round and the system-design round differ a lot by team, and the recruiter will usually tell you which you are getting.

4The coding or technical rounds#

This is where most of the signal lives. The bar is high and the format is often hands-on.

The difficulty.

• Solid medium to hard. Not puzzle-box hard, but you need fluency with the core toolkit.
• Arrays and hashmaps, two pointers, sliding window, recursion and backtracking, trees and graphs (BFS/DFS, topological sort), heaps, intervals, and dynamic programming you can actually reason through.
• Expect at least one problem where the naive answer is obvious and the interesting part is making it efficient.
• The classic shape: "brute force in two minutes, then spend the rest getting it from O(n^2) to O(n) and explaining why."

The 80/20 of what shows up. Drill these first, because they cover most of what gets asked:

• Hashmaps for counting, grouping, and dedup. Two-sum family, frequency maps, seen-sets.
• Two pointers and sliding window for subarray and substring problems with a size or sum constraint.
• BFS/DFS on graphs and grids, plus topological sort for dependency ordering.
• Heaps for top-k, merge-k, and streaming median.
• Intervals: sort by start, then merge or sweep.
• DP you can derive, not memorize: define the state, the transition, the base case, out loud.

The practical twist.

• A common Anthropic format is a take-home or a live "build something real" session: parse this log format, implement a small rate limiter, build a mini key-value store, write a function that batches API calls with retries.
• They care that your code runs, handles edge cases, and that you can extend it when they add a requirement mid-interview.
• Working in an actual editor with a real language (usually Python) is normal.
• Write code you would actually ship: real names, small functions, a couple of tests, errors handled.
• Reaching for print debugging and a quick assert the moment something looks off reads as a working engineer, not a candidate performing.

A worked mini-example. Say they ask for a function that batches API calls with retries and backoff. A strong answer starts simple and stays readable:

import time, random

def call_with_retries(fn, *args, max_retries=3, base=0.5):
    for attempt in range(max_retries + 1):
        try:
            return fn(*args)
        except TransientError:
            if attempt == max_retries:
                raise
            sleep = base * (2 ** attempt) + random.uniform(0, 0.1)
            time.sleep(sleep)

def batch(items, fn, size=10):
    results = []
    for i in range(0, len(items), size):
        chunk = items[i:i + size]
        results.extend(call_with_retries(fn, chunk) for chunk in [chunk])
    return results

Then narrate the gaps out loud before they ask:

• Exponential backoff with jitter so retries do not stampede.
• A cap on retries so you fail loudly instead of hanging.
• Only retry transient errors, not a 400.
• Call out your own smell: the for chunk in [chunk] trick is ugly, say you would flatten it to a plain call. Catching your own mess beats hoping they miss it.

That running commentary is worth as much as the code.

How to practice.

• Grind NeoCode-style mediums until patterns are automatic, yes.
• Also practice building small working programs end to end under a timer.
• Take a blank file and implement an LRU cache with tests in 25 minutes. Build a tiny CLI that reads a file and aggregates it.
• The muscle you need is "idea to correct running code, fast."
• Most candidates can solve the problem given an hour. The ones who pass solve it in 30 minutes and spend the rest handling edge cases and the follow-up.

How to actually win the round. This is the part people fluff.

• Clarify first. Restate the problem. Ask about input size, edge cases, and what "done" means. "Can inputs be empty? Are duplicates allowed? How big does n get?" costs nothing and prevents most disasters.
• Think out loud. When I run a loop here, what I am really checking is whether you can tell me why. Silence reads as "I am stuck or memorized this." Narrate your plan before you type, and keep narrating when you hit a wall.
• State complexity. Say the time and space cost, and say it again when you optimize. "This is O(n^2), I can get it to O(n) with a hashmap" is exactly what I want to hear.
• Test your own code. Walk a real example through it. Catch your own off-by-one before I have to. Candidates who test themselves jump a full level in my notes.
• Handle the follow-up gracefully. We almost always add a twist: now the input is streaming, now it has to be thread-safe, now it has to run on 10x the data. Staying calm and adapting matters more than getting the first version perfect.

5System design and the ML-systems round#

For infra, product, and senior roles you will get a design round. For research-engineering roles it may be an ML-systems or experiment-design round instead. Know which one your team runs and prep accordingly. Ask your recruiter directly which flavor to expect, they will usually tell you.

A simple framework that works:

1. Clarify requirements and constraints. Scale, latency, consistency, read/write ratio, budget.
2. Name the core entities and the API.
3. Sketch the high-level components. Draw boxes, be concrete about data flow.
4. Pick storage and justify it. SQL vs key-value vs blob, and why.
5. Scale it. Caching, sharding, queues, load balancing. Call out the real bottleneck.
6. Talk tradeoffs and failure modes. What breaks at 10x? What is your fallback?

Classic prompts you might see:

• Design a system to serve LLM inference to millions of users with low latency. Talk batching, GPU utilization, KV cache, queueing, autoscaling.
• Design a large-scale data pipeline for cleaning and deduplicating training data.
• Design a rate limiter or an API gateway for a high-traffic service.
• Design an evaluation harness that runs thousands of model evals reproducibly.
• Design a feature store or an experiment-tracking system for researchers.

Here is roughly how an LLM inference serving design should flow. Keep the boxes few and the data flow obvious:

Walk the diagram:

• The gateway rate-limits and authenticates.
• The queue absorbs spikes so GPUs stay busy.
• The batcher groups requests to raise GPU utilization.
• The KV cache holds attention state so you do not recompute the prompt on every token.

The tradeoff to name out loud:

• Bigger batches raise throughput but hurt p99 latency for the unlucky request that waited.
• So you cap batch wait time, say 5 to 10 ms, and flush early when the batch fills.
• That one sentence tells me you have actually thought about serving.

Push one level deeper if they let you:

• Continuous batching so a finished sequence frees its slot mid-flight instead of blocking the whole batch.
• Prefix caching so a shared system prompt is computed once across many requests.
• Those two details separate "read a blog post" from "ran a serving stack."

For the ML-systems flavor, expect:

• Distributed training (data vs model parallelism).
• Throughput vs latency tradeoffs in inference.
• Memory on accelerators.
• How you would debug a training run that is silently producing garbage.

A good debug answer is a loop, not a guess:

• Check the data first (bad batch, bad labels, bad tokenization).
• Then the loss curve shape.
• Then gradients for NaNs or explosions.
• Then a single-batch overfit test to prove the model can learn at all.

You do not need to have trained a frontier model. You do need to reason clearly about the systems around it and admit what you do not know. When you hit the edge of your knowledge, say "I have not run model-parallel training at that scale, here is how I would reason about it." A clean honest boundary scores higher than a confident wrong answer.

6Behavioral and culture fit#

Do not skip this. At Anthropic, the values round can sink an otherwise strong candidate, because mission fit is real here, not a poster. I have seen clean technical loops lose the offer on this round alone.

What the culture actually centers on:

• Taking safety seriously as a technical problem.
• Doing high-quality honest work.
• Communicating clearly. They genuinely prize good writing and direct communication.
• Acting for the good of the mission over personal glory.
• Being pragmatic rather than ideological.

The two-sided test they are running:

• They want people who can hold "AI is powerful and risky" and "we should still build it carefully" at the same time, without flinching.
• Argue only one side and you read as naive or as a doomer. Neither lands.
• The way to show you hold both: describe a real tradeoff where speed and caution pulled against each other, and say how you decided.

Prepare 5 or 6 STAR stories:

• A hard technical call you owned.
• A time you disagreed with someone.
• A time you were wrong and fixed it.
• A time you shipped under pressure.
• Why you care about this specific mission.

On "why Anthropic and not another lab":

• Have a real answer. Generic enthusiasm gets caught instantly.
• The honest, specific version sounds like "I care about interpretability because I have shipped models I could not debug and it scared me," not "I love the mission."

One full worked STAR example:

• Situation: Our inference service was dropping requests during traffic spikes, and on-call was paging twice a week.
• Task: I owned reliability for that service and had to stop the pages without a big rewrite we had no time for.
• Action: I profiled the hot path and found we were re-tokenizing identical prompts on every call. I added a bounded LRU cache for tokenized inputs, put a request queue with backpressure in front of the GPU workers, and wrote a load test to prove it before shipping. I also wrote a short doc so the team understood the tradeoff: slightly higher memory for far fewer drops.
• Result: Dropped requests fell by about 94% during spikes, p99 latency improved by roughly 30%, and we went from two pages a week to none for the next two months. The doc got reused when another team hit the same issue.

Why that example works:

• One clear problem, specific actions, a number at the end. That is the shape they want.
• Notice the doc. At a writing-heavy company, "I wrote it down so others could reuse it" is a real signal, not a throwaway.
• Keep each story to about 90 seconds spoken, lead with the result, and have one follow-up detail ready for when they probe the hardest decision.

A specific true story about your own work beats any amount of enthusiasm for the mission.

7Your prep plan#

4-week plan

• Week 1: Core DSA patterns. 3 to 4 problems a day across arrays, hashmaps, two pointers, trees, graphs. Narrate out loud as you solve, not in your head.
• Week 2: DP, heaps, intervals, backtracking. Plus one "build a small working tool from scratch" session every other day, timed, with tests.
• Week 3: System design or ML systems. Do 6 to 8 full mock designs. Read about LLM inference, distributed training, and caching.
• Week 4: Write your STAR stories, do 3 full mock loops with a friend, and polish your "why Anthropic." Rest the day before.

2-week plan

• Days 1 to 5: Mediums and a few hards daily, focused on the patterns above. Timed.
• Days 6 to 9: System design framework plus 4 mock designs. Build 2 small end-to-end programs under a timer.
• Days 10 to 12: Behavioral stories written and rehearsed, 2 mock interviews.
• Days 13 to 14: Light review, sleep, logistics check.

2-day crash plan

• Day 1 morning: Re-drill the 10 patterns you are weakest on. Afternoon: one mock design and read about inference serving.
• Day 2 morning: Write and say out loud your top 5 STAR stories plus "why Anthropic." Afternoon: two fresh mediums under a timer, then stop and rest.

8Why people get rejected at Anthropic#

1. Coding too slow or too silent. Correct but sluggish, or correct with zero narration. The bar assumes fluency: still thinking about the data structure five minutes in is a flag.
2. "I'd just use a library" syndrome. When asked to implement something, show you understand the mechanics. Nobody is impressed that you know functools.lru_cache exists when the task was to build an LRU cache.
3. No real safety or mission grounding. Candidates who cannot say anything specific about why safe AI matters to them. It shows, and it is usually the fastest no.
4. Weak writing and fuzzy communication. Rambling answers, unclear design explanations. Anthropic weights clarity heavily, and a disorganized take-home README can quietly end you.
5. Not handling the follow-up. Freezing when the problem changes mid-interview, or getting defensive. Adaptability is a signal, and the follow-up is where the level call often gets made.
6. Overclaiming. Padding your resume with ML work you cannot back up under questioning. Honesty is a core value, and they probe. Say "I do not know" cleanly when you do not. One caught exaggeration can cost the whole loop.

9The offer, comp and negotiation#

Anthropic pays at the top of the market. US total comp is largely cash-heavy with meaningful equity, and the bands are wide because level is set during the loop.

• US (SF/NY): roughly $300K for mid, climbing to $500K to $900K+ total for senior and staff. Equity can be significant given the company's trajectory.
• London: typically £150K to £300K+ total depending on level.
• Toronto / other: present but thin. Comp tracks the local senior market, below US numbers.

Negotiation tips:

• Anchor on level, not just dollars. The biggest lever is which level they peg you at. If you can show staff-level scope in your stories, lead with those stories before you ever talk numbers.
• Use competing offers honestly. A real offer from another top lab or FAANG gives recruiters room to go to the committee. Be straight about it. They respect directness and will catch a bluff, and a caught bluff poisons the rest of the conversation.
• Ask about equity structure. Understand the terms, vesting, and any liquidity details before you fixate on cash. For a company on this trajectory, the equity question is worth real attention. Get specific: strike price or grant type, the vesting schedule, and whether any secondary or tender events have happened, because "equity is big" means nothing until you know those three.

10FAQ#

Is there a take-home? Often, yes, especially for the technical screen. Treat it like production work: clean, tested, documented. Do not over-engineer, but do handle edge cases. A short README that states your assumptions and tradeoffs can matter as much as the code itself.

Do I need ML research experience? For research-engineering roles it helps a lot. For many infra and product MTS roles, strong systems and coding plus curiosity about ML is enough. Read the job post, and if you are unsure, ask the recruiter which skills the team actually screens for.

What language should I use? Python is the safe default and what most of the codebase uses. Use what you are fastest and cleanest in, but if you have a choice and no strong preference, pick Python.

How hard is the DSA? Medium to hard. Fluency and speed matter more than exotic algorithms. You rarely need the most obscure trick, but you do need the common ones (the 80/20 patterns above) to be automatic.

How important is the "why Anthropic" answer? Very. A specific, honest answer about the mission is close to required. Vague "I love AI" answers hurt you. Tie it to something true about your own work, not a mission statement you memorized.

If you want, map all of this onto a dated week-by-week plan that fits your own timeline and the exact team you are targeting, and work backward from your interview date.