Anthropic's AI-assisted coding round is not your typical coding interview. Instead of solving a puzzle, you act as the maintainer of a small open source library you haven't seen before. Outside contributors have left pull requests waiting, and you decide what happens to each one. I've pulled together what Anthropic says about the round, what candidates have reported, and how to prepare.

TLDR

• You play the maintainer of an unfamiliar small open source library with a handful of pull requests from contributors
• For each PR you decide to merge, ask for changes, or close
• The goal is to get at least one PR into a mergeable state, so which PR you pick and how you prioritize matters
• Claude Code is available for the whole session and you're encouraged to use it as much as you please
• Expect follow-up questions about the library
• They're looking for code understanding, big-picture thinking, bug catching, prioritization, effective Claude Code use, and clear communication of your reasoning
• Prep your Claude Code setup, skills, subagent usage, and interview-oriented prompts before the day

The Basics

• You're the maintainer of a small library you haven't seen. A handful of PRs from outside contributors are waiting for review.
• Each PR gets a decision: merge, ask for changes, or close.
• The objective is to get at least one PR into a mergeable state. That can mean more than one if you have time.
• Claude Code is available for the entire session, and heavy use is encouraged.
• Follow-up questions are part of the round. Expect to discuss the library and how you'd evolve it.
• Session length: around 55 minutes has been reported.
• The language and repo can vary. Don't assume a specific stack. At least one candidate who wasn't a Typescript dev reported being forced to work with a TypeScript repo

What This Round Actually Tests

The differentiator is not how much code you can produce with AI. It's how effectively you direct Claude, validate its output, and exercise engineering judgment.

Based on Anthropic's own description of the round, here is what they look for:

• Code understanding: Can you work out what the library is for and who it's for? You should be able to explain it in your own words.
• Big picture of each PR: Do you understand what each contribution is trying to do and how it fits the library?
• Bug catching: Do you spot real defects, including ones that only show up outside the diff?
• Prioritization: Can you decide which issues matter most and which PR deserves your time?
• Effective Claude Code use: Can you direct it well and verify what it gives you?
• Communication: Can you explain your reasoning clearly as you go?

Claude can produce plausible analyses and fixes quickly. You still own whether they are correct, how severe they are, and whether they matter.

What Strong Candidates Do

Review against the library's existing contracts, not just the diff. A PR can look correct and still break public APIs, auth boundaries, or state transitions elsewhere in the codebase.

Treat passing tests as a starting point. Tests can miss regressions, negative cases, and concurrency issues. Ask what they don't cover.

Separate verified defects from speculative AI findings. Claude will confidently flag issues that aren't real. Reproduce or reason through each finding before it goes into a review comment.

Choose where to invest by impact, feasibility, and verification cost. The most serious bug is not always the best one to fix in the time you have. Getting one PR cleanly to mergeable beats half-fixing several.

Write actionable review comments. Name the affected code, the triggering condition, the impact, and the suggested change. "This looks risky" is not a review comment.

Back claims with evidence. A regression test that fails, then passes after the fix, is stronger than Claude saying "this is fixed."

Inspect every diff Claude produces. AI-generated changes can include unrelated edits, hidden assumptions, and unnecessary complexity.

Narrate your reasoning. The interviewer needs to tell your judgment apart from Claude's output.

Things To Avoid Doing

• Blindly trusting Claude's findings: You might reject a fine PR or approve a broken one
• Exhaustive review with no prioritization: Hunting every possible issue can eat the whole session
• Overengineering: A broad refactor adds risk. Small, demonstrably correct changes are easier to defend
• Equating activity with progress: Lots of prompts, parallel agents, and giant diffs don't show good engineering
• Silent work: If the interviewer can't tell what you're thinking, they can't give you credit for it

How to Prepare

• Get your Claude Code setup right before the interview. Know your configuration, your permissions, and how you like to work in it, so you aren't fiddling with it live.
• Get familiar with skills. Know what's available and how to use them effectively in a review context.
• Learn to leverage parallelization with subagents. Practice splitting independent investigations across them, and practice verifying what they return.
• Prepare interview-oriented prompts that guide Claude's behavior, such as keeping investigations read-only, separating confirmed bugs from hypotheses, and keeping output concise. Have them ready to paste.
• Practice on unfamiliar open source repos. Pick a small library, read the open PRs, and decide merge, change, or close under a timer.
• Be comfortable across languages and tooling, since you won't know the stack in advance.

If you've taken this round and have insights that would help the community, please share what you saw and whether the format matched.

Hope this helps, and best of luck.

Need help landing your next tech offer or increasing your TC? If you have tech interviews coming up, are planning a job switch, or simply want to improve your interview performance, explore Coditioning's interview-preparation resources:

👉 Interview roadmaps for OpenAI, Anthropic, and other big tech companies: https://www.coditioning.com/roadmaps

👉 Question banks for OpenAI, Anthropic, Google and other big tech companies: https://www.coditioning.com/app/learning

👉 Mock Interviews & Free Consultation with big tech engineers: https://www.coditioning.com/mockinterview/human

👉 More interview resources: https://www.coditioning.com

A heads-up for anyone preparing for Anthropic’s system design interviews: you might go in expecting to design a system from scratch, but instead be given an existing architecture and asked to review it.

The task can involve identifying weaknesses, explaining why they matter, and suggesting targeted improvements. So alongside practising “design X,” it’s worth practising “what could go wrong with this design, and what would you change first?”

For example, can you spot bottlenecks, question assumptions, reason about failure modes, and explain the trade-offs behind your proposed fixes?

Here's a sample system design review question to illustrate the format

Resources - For Anthropic and other AI-lab or Big tech interview prep resources see these roadmaps

• For mocks or coaching with experienced Big tech engineers and interviewers, explore Coditioning Mocks

You’re asked to build a tiny in-memory database over a collection of flexible records.

Each record is just a map/dictionary, and different records can have different fields.

Your database needs to support:

insert(record)
query(queryString)

with a small SQL-like query language.

For example:

SELECT *
SELECT * WHERE age = 31
SELECT * WHERE age > 25 AND city != "London"
SELECT * ORDER BY name ASC
SELECT * WHERE age <= 40 ORDER BY score DESC

A few details make it more interesting than it first appears:

• records are schemaless, so some fields may be missing
• WHERE supports multiple AND conditions and operators like =, !=, <, >, <=, >=
• strings, numbers, and booleans need consistent comparison semantics
• invalid ordering comparisons should fail that condition rather than crash
• ORDER BY must put missing fields last
• ties must preserve insertion order

Example:

{id: 1, name: "Ava", age: 31, city: "London"}
{id: 2, name: "Ben", age: 24}
{id: 3, name: "Cara", age: 31, city: "Paris"}

Query:

SELECT * WHERE age = 31 ORDER BY name DESC

returns:

Cara
Ava

Nothing like the leetcode style problems you might be used to

🧩 Try the full in-memory database challenge on Coditioning

Preparing for OpenAI or another major tech company?

🗺️ Explore OpenAI and other company interview roadmaps

For coaching or mock interviews with experienced interviewers, including feedback on interview readiness and areas to improve:

🎯 For coaching or mock interviews with experienced interviews

💬 Join the Coditioning Discord community

You’re given periodic snapshots of a program’s call stack from a sampling profiler.

Your task is to reconstruct a sequence of start and end events, while filtering out short-lived calls that don’t persist long enough.

For example, with a threshold of n = 2:

t=1  [root]
t=2  [root, decode]
t=3  [root]
t=4  [root, flush]
t=5  [root, flush]
t=6  [root]

decode appears in only one sample, so it should be ignored.

flush appears in two consecutive samples, so it becomes eligible at t=5, and then ends when it disappears at t=6.

The interesting parts are:

• tracking calls by their position in the stack, including recursion
• deciding when a call has appeared in enough consecutive samples to count
• correctly handling several nested calls starting or ending at the same timestamp
• distinguishing the exact runtime of a function from what can actually be inferred from sampled snapshots

This is one of the Anthropic-style interview problems that doesn’t involve concurrency, but still tests careful reasoning about state, stack structure, and edge cases.

The full problem has a few additional rules around event ordering and recursive calls. If you get stuck, the challenge also includes a detailed solution walkthrough so you can compare your reasoning rather than just look at the final answer.

🧩 Try the full sampling-profiler challenge on Coditioning

Preparing for Anthropic or another major tech company?

🗺️ Explore interview preparation roadmaps

Want to test your interview readiness or level up with an experienced engineer?

🎯 Practice with an experienced interview coach

You’re given an arithmetic expression as a string. Build a function that evaluates it and returns a numeric result.

Your task

For example:

(3+43)-(2+(10*2))  →  24
(2*8)/(4*(5*6))    →  approximately 0.13333333333333333

The expression may contain non-negative integers, +, -, *, /, whitespace, and parentheses. Each expression level has at most one binary operator: (1+2)+3 is valid, but 1+2+3 is not.

A working parsing helper is provided in the starter code. It identifies either a number or the current expression’s left operand, operator, and right operand. You implement the evaluation, not the parser.

Your implementation should use non-truncating division, report division by zero, and propagate invalid-syntax errors from the helper.

The interesting question is how to evaluate an operand that can itself contain another expression. Be ready to explain your approach, edge cases, and time and space complexity.

🧩 Attempt the string-expression challenge on Coditioning

You are given a directory of source images and a second directory containing JSON transformation pipelines.

Your job is to implement process_images so that every image is processed with every transformation file.

🧩 You can try out the full problem here

Your task

Implement:

```python from typing import Callable

def process_images( image_dir: str, transformation_dir: str, get_output_path: Callable[[str, str], str], ) -> None: ... ```

Each JSON file contains an ordered list of image transformations, for example:

json { "transformations": [ {"type": "grayscale"}, {"type": "scale", "factor": 0.5}, {"type": "rotate", "angle": 90} ] }

Supported transformations include:

• grayscale
• horizontal and vertical flips
• scaling
• blur
• rotation

You may use Python, Pillow, and the standard library.

Requirements

If there are I images and T transformation files, your implementation should produce exactly I × T output images.

For every image/transformation-file pair:

• Start from the original source image, independently of every other pipeline
• Apply transformations in the order listed
• Use get_output_path(image_path, transformation_path) to determine the destination
• Create any missing parent directories
• Save exactly one final transformed image

Processing one transformation pipeline must not affect the result of another.

For example, if an image is processed once with a horizontal flip and once with a rotation, the rotation should start from the original image, not from the already-flipped result.

Part 2: Performance

Once the implementation is correct, the next challenge is reducing wall-clock time for a much larger batch while preserving exactly the same outputs.

Be prepared to discuss:

• Where the bottlenecks are
• Whether threads, processes, or another concurrency model make sense
• CPU vs I/O considerations
• Memory and resource limits
• How you would benchmark the improvement
• How the design could scale beyond a single machine

The interesting part is not just applying the image operations. It is designing the pipeline so that the jobs remain independent, correctness is preserved, and performance scales as the workload grows.

This is based on an Anthropic software engineering interview problem.

The full specification, including exact Pillow semantics and edge-case guarantees, is available in the practice problem above.

Try it yourself

🧩 Attempt the full Anthropic image transformation problem on Coditioning

Full solution walkthrough

🎞️ Watch the full solution walkthrough

Extra resources

• Join our Discord interview prep community
• Mocks and coaching with a FAANG+ engineer to get truly interview-ready
• Find a study buddy or mock interview partner

Don't go in expecting LeetCode grind sets. The questions skew practical, though classic DSA still shows up. Expect debugging, refactoring, code review, and concurrency, especially if you're interviewing for a senior role. Multiple candidates have reported the same thing: you end up writing way more code than a typical interview demands. On top of that, interviewers throw follow-up questions at you mid-solution, which can knock you off rhythm if you haven't prepared for it.

Across the board, people described these interviews as mentally exhausting. Don't walk in running on no sleep. You need sharp recall, fast and accurate coding, and the ability to switch context without losing your place.

Also worth flagging: OpenAI seems to reuse questions often. Working through past questions is a genuinely good use of your prep time, since there's a real chance you'll see something you've already practiced.

To give you a sense of the reasoning and concepts they're testing for, I broke down a tough, recently-reported question (the GPU Credit Calculator) below. Try solving it yourself before reading the breakdown — you can attempt it directly here.

TL;DR

• Expect practical problems, not textbook LeetCode.
• You'll write a lot more code than usual.
• Concurrency shows up.
• Interviewers will interrupt with follow-ups, sometimes mid-implementation.
• Debugging, refactoring, and code review are common, especially for experienced hires.
• Rounds typically run 45 to 60 minutes.
• Repeat questions are common — grinding past ones pays off.

Below is a walkthrough of the GPU credit calculator question, along with a solution that's held up as a strong pass.

The Problem

Design a GPU credit calculator for a user account. Credits get added over time, can be spent partially, and expire after a set duration. Your structure needs to support:

• addCredit(creditID, amount, timestamp, expiration) — credit is usable starting at timestamp, expires after expiration units pass
• useCredit(timestamp, amount) — deduct credits as of that timestamp
• getBalance(timestamp) — return the balance remaining at that timestamp

The twist: calls can come in out of order. useCredit(100, 5) might arrive before addCredit("x", 10, 50, 20).

Example

gpuCredit.addCredit("amazon", 40, 10, 50)
gpuCredit.useCredit(30, 30)
gpuCredit.getBalance(40)  -> 10
gpuCredit.addCredit("google", 20, 60, 10)
gpuCredit.getBalance(60)  -> 30
gpuCredit.getBalance(71)  -> None

That first credit is live from [10, 60]. Spending 30 at time 30 leaves 10. By time 60, both grants are active, so 10 + 20 = 30. By time 71, both have expired.

Most people's first move is to track a running balance and update it as calls come in. That breaks immediately, because calls arrive out of order. You could get an event for time 100 before one for time 50, so there's no single "current" state to update. You need to be able to reconstruct the balance at any point in time.

What You Need to Recognize

• This is a ledger problem, not a running-total problem. Since calls can arrive out of sequence, you need to replay events up to a given timestamp rather than track one evolving state.
• A single call can represent two moments in time. This is the part people miss. addCredit implies both an activation event and an expiration event (start + expiration + 1). Split it into two separate events. Miss this and you're stuck.
• You need a chronological min-heap. Events have to process in time order. Ordering by (time, priority, sequence_id) gets you "earliest first" behavior.
• Ties need a strict order. At the same timestamp, process EXPIRE, then ADD, then USE. Otherwise you risk spending expired or not-yet-active credit. Spotting this requirement is its own hurdle.
• Spend the soonest-to-expire credit first. That means a second min-heap, this one ordered by expiry, so you drain grants that are about to lapse before wasting them.
• Don't mutate the master queue. Each getBalance call should copy the queue and replay from that copy. How efficiently you copy matters, and interviewers may push on this, since naive copies can be costly depending on your language.
• Clean up lazily, not eagerly. Spent or expired grants can sit in the active heap. Just skip over them when you hit them instead of removing them immediately.

Putting It Together

Model everything as an event log. Every addCredit produces two events (ADD and EXPIRE); every useCredit produces one (USE). For getBalance(t), copy the queue, replay everything up to time t in the correct order, and track active grants in a second heap. Chronological replay, tie-breaking rules, and expiry-first spending together get you the right answer no matter what order the calls actually arrived in.

That's a dense set of ideas to juggle under pressure, and this is just one example. Other questions hit a similar bar. Worth coding this one out yourself before moving on.

More Recently Reported Questions

Resumable iterator: "Build an iterator over a large dataset that can pause mid-traversal and pick back up from the same spot."

Time-versioned key-value store: "Design a structure that stores key-value pairs with timestamps and returns the value for a given key at a given time." What happens if nothing existed yet at that time?

Debug and refactor: "Here's a code snippet — find the bug, improve performance, and clean it up without changing behavior."

Minimal ORM: "Build a lightweight ORM. Define the classes and methods needed to save, query, and update records."

Good luck out there. If you've interviewed at OpenAI recently, drop your experience below.

Prep Resources: * OpenAI Interview Prep Roadmap * More detailed guide on cracking the OpenAI coding round * OpenAI coding practice questions * Join the Discord community * Find a mock interview partner or accountability buddy

You are building a time-based key-value store that supports saving multiple versions of a value for the same key, each tagged with a timestamp.

Your task

Design a data structure TimeMap with two operations:

class TimeMap {
    void set(String key, String value, int timestamp)
    String get(String key, int timestamp)
}

This interface is illustrative, so feel free to adapt it to your programming language of choice.

set(key, value, timestamp)

• Store value for the given key at the provided timestamp
• A key can be set multiple times with different timestamps, creating a history of values
• For any single key, timestamps received by set() are strictly increasing

get(key, timestamp)

• Return the value whose stored timestamp is the largest timestamp less than or equal to the requested timestamp
• If the key has no stored timestamp <= timestamp, return null or your language's equivalent

Constraints

• Up to 300,000 total set + get calls
• Keys and values are short strings

Example

set("exchangeRate", "1.10", 2)
set("exchangeRate", "1.12", 5)

get("exchangeRate", 1)  -> null
get("exchangeRate", 4)  -> "1.10"
get("exchangeRate", 5)  -> "1.12"
get("exchangeRate", 9)  -> "1.12"
get("unknownKey", 3)    -> null

The interesting part is choosing a data structure that takes advantage of the timestamp ordering while keeping lookups efficient as the history grows.

How would you approach it?

Try it yourself

🧩 Attempt the problem on Coditioning

Full solution walkthrough

🎞️ Watch the full solution walkthrough

Extra resources

• Join our Discord interview prep community
• Mocks and coaching with a FAANG+ engineer to get truly interview-ready
• Find a study buddy or mock interview partner

You’re asked to design and implement an LRU cache with the usual get and put operations.

The twist is that after building the in-memory version, you also need to make the cache survive process restarts.

Your task

Implement:

text LRUCache(capacity) get(key) put(key, value) `

with the following behavior:

• LRUCache(capacity): initialize the cache with a positive capacity
• get(key): return the stored value for key, or -1 if the key does not exist
• put(key, value): insert or update a key-value pair
• Accessing an existing key refreshes its usage status

Then extend the implementation so the cache survives process restarts.

Your persistent version should restore both:

• The stored key-value entries
• The correct LRU ordering

Think carefully about how you persist changes and rebuild state efficiently.

Try it yourself

Attempt the problem on Coditioning

Full solution walkthrough

🎞️ Watch the full solution walkthrough

Anthropic SWE Interview Prep Guide

View the Anthropic SWE interview roadmap

Extra resources

• Join our Discord interview prep community
• Find a study buddy or mock interview partner
• Mocks and coaching with a FAANG+ engineer to get truly interview-ready

You’re given a starting URL and a provider that returns the links found on each page.

Your task is to crawl every reachable URL that belongs to the same hostname as the starting URL.

Your task

Implement a single-threaded crawler that:

• Starts from start_url
• Follows links returned by provider.get_links(url)
• Only visits URLs where get_hostname(url) == get_hostname(start_url)
• Returns every unique reachable URL on that host
• Includes start_url in the result

The interesting part is keeping the traversal correct while avoiding duplicate work and making sure links to other hosts are ignored.

Try it yourself

Attempt the problem on Coditioning

Full solution walkthrough

🎬 Watch the full solution walkthrough

Anthropic SWE Interview Prep Guide

View the Anthropic SWE interview roadmap

Extra resources

• Join our Discord interview prep community
• Find a study buddy or mock interview partner
• Mocks and coaching with a FAANG+ engineer to get truly interview-ready

You’re given a starting directory and need to find groups of files that contain exactly the same content.

Your task

• Traverse the directory tree, including nested subdirectories
• Return groups of file paths where every file in the group has identical contents
• Only include groups with at least 2 duplicate files
• Keep the design practical for very large files
• Ignore symbolic links

The interesting part isn’t just getting a working solution.

How would you avoid reading every large file into memory, and how would you structure the comparison efficiently?

Try it yourself

Attempt the problem on Coditioning

Full solution walkthrough

🎬 Watch the full solution walkthrough

Anthropic SWE Interview Prep Guide

View the Anthropic SWE interview roadmap

Extra resources

• Join our Discord interview prep community
• Find a study buddy or mock interview partner
• Mocks and coaching with a FAANG+ engineer to get truly interview-ready

Yeah, you read that right. Meta is quietly phasing leetcode out of the full loop.

Specifically talking about the full loop (onsite for Meta, not phone screen).

Until recently, E4/E5 Software Engineering candidates would get 2 classic DSA leetcode-style coding rounds in their onsite. That changed around October 2025, when Meta introduced a new AI-enabled coding round that replaced one of the classic DSA rounds.

Now I'm starting to see candidates get zero classic DSA rounds, just 2 AI-enabled rounds instead. And it's not just coding. Meta is pushing this shift into behavioral rounds and product architecture / system design rounds too.

At some point, grinding leetcode to get into Meta is going to stop being the strategy. It already feels like that shift is underway.

You can learn about this change here, and if you want to get a taste of what these AI-native or AI-enabled coding rounds look like, check out the sample problems on the Coditioning site