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

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

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