Anthropic SWE Interview: Online Assessment Guide

Estimated read time: 8-10 minutes

Summary: Anthropic's online assessment is not a standard LeetCode grind. It uses a progressive gate format where your base implementation unlocks harder stages, meaning sloppy Stage 1 code makes later stages physically impossible to complete in time. AI tools are explicitly banned. This guide breaks down the format, what you'll face, and how to approach it.

---

---

TL;DR + FAQ (read this first)

At-a-glance takeaways

• Approximately 90 minutes, CodeSignal-style async platform
• Progressive gate format: problems escalate in stages and your base code must be clean enough to extend
• LLMs and AI tools are banned. Anthropic explicitly prohibits their use in assessments despite being an AI lab
• Questions lean toward stateful systems, concurrency, and resource management, not abstract puzzles
• Speed matters early: you cannot reach the hardest stages if you're rewriting Stage 1 at the halfway mark

Quick FAQ

Is this like LeetCode?
Not typically. Problems are systems-flavored: you might implement a data structure with TTL, add concurrency safety to it, then handle memory constraints. Classic algorithm trivia rarely appears as the main event.

Can I use AI coding assistants?
No. Anthropic explicitly bars AI assistance in their assessments. This is enforced by policy and you're expected to rely on your own knowledge and standard libraries.

What language can I use?
You typically have a choice of common languages. Pick the one you're most fluent in for systems-level code. This is not the time to try something new.

How many problems will I see?
Typically one base problem that evolves through multiple stages. Think of it as one problem with three difficulty layers, not three separate problems.

What happens if I don't pass all stages?
Partial credit matters. Passing Stage 1 cleanly and Stage 2 partially is a reasonable outcome. Failing to pass Stage 1 at all is a hard stop.

---

The progressive gate format explained

This is the defining structural feature of Anthropic's OA and the thing most candidates underestimate.

The assessment typically starts with a system implementation problem that appears simple. You might be asked to implement a basic in-memory key-value store, a rate limiter, or a scheduler. As you pass hidden test cases, the platform unlocks the next stage, which adds a significantly harder constraint on top of your existing code.

A typical progression looks like this:

• Stage 1: Implement the core data structure or service with basic operations
• Stage 2: Add TTL (time-to-live), expiry, or priority handling
• Stage 3: Make it thread-safe; handle concurrent access correctly

The critical insight: you are building on your own code. If your Stage 1 implementation is tangled, uses global state badly, or has unclear function boundaries, you cannot cleanly add concurrency in Stage 3. You'll spend the last 30 minutes rewriting instead of extending.

This is why the OA is as much a test of engineering discipline as it is of algorithmic skill. Candidates who write quick-and-dirty scripting-style code in Stage 1 consistently hit a wall at Stage 3.

---

What the OA is actually testing

1) Can you write extensible code under time pressure?

The progressive format is a direct proxy for production engineering judgment. In real engineering, you often build something simple first and then have to extend it without rewriting everything. The OA tests whether your instinct under pressure is to write clean, modular code or to "get it working" first and worry about structure later.

2) Correctness and edge-case handling

Hidden test cases probe edge conditions: empty inputs, boundary values, concurrent writes, memory limits, expiry timing edge cases. You won't see the test cases until after submission. That means you have to reason about edge cases proactively, not reactively.

3) Concurrency and thread safety

The hardest stage typically introduces concurrency. You'll need to correctly handle shared state: locking, atomicity, race conditions. This is not theoretical. You're expected to write working thread-safe code, not just describe what a mutex does.

4) Speed without sacrificing quality

90 minutes for a three-stage progressive problem is a tight timeline. The assessment tests whether you can move quickly while still making sound engineering decisions. Slow and clean loses; fast and messy loses. The winning approach is clean-first and quick-enough.

---

Question types and examples

Questions are not drawn from a public problem bank, but candidate reports cluster around a consistent set of themes:

Stateful data structures
Implement a data structure that supports standard operations plus time-based behaviour: expiry, versioning, or TTL. Examples include an LRU cache with expiry, a versioned key-value store, or a rate limiter with sliding window semantics.

Scheduling and resource allocation
Implement a scheduler or task queue that allocates resources under constraints. Follow-up stages typically add priority, preemption, or fairness requirements.

Concurrency-safe services
A service that handles concurrent operations on shared state. You'll need to demonstrate correct use of locks or other synchronisation primitives. Common failure: using a lock but not holding it across the full critical section.

Debugging a provided service
Some candidates report being given a small broken service and asked to trace execution paths, identify the bug, fix it, and verify the fix. This tests how fast you can read unfamiliar code and reason about its state.

---

Common failure modes

Writing scripting-style code in Stage 1. Variables scattered in global scope, functions with side effects baked in, no clear separation of concerns. This feels fast in the moment. It becomes a trap in Stage 3 when you need to make the same logic thread-safe and there's no clean seam to add a lock.

Failing to handle concurrency edge cases. Adding a lock is not enough. Common bugs include: releasing a lock before all shared state is updated, failing to handle the case where a thread reads stale data after a conditional check, and not considering what happens when two threads hit an expiry check simultaneously.

Over-engineering Stage 1. The opposite failure: spending 40 minutes building a beautifully architected system for Stage 1 and running out of time before Stage 3. Stage 1 needs to be clean and correct, not perfect.

Not testing your own code. You won't see the hidden test cases, but you can write your own quick sanity checks. Candidates who dry-run their code with a few edge cases before submitting catch significantly more bugs.

---

How to prepare

Practice building systems that you then extend. Pick a problem (implement an LRU cache), then give yourself a constraint to add (TTL support), then add concurrent access. Doing this repeatedly trains the right muscle: extensible-first thinking.

Get fluent in your language's concurrency primitives. You should be able to write correct locking code without looking anything up. Know the failure modes (deadlock, livelock, race conditions) and how to avoid them in your chosen language.

Practise with a timer. 90 minutes goes fast. Time yourself on multi-stage problems. If Stage 1 is taking more than 25-30 minutes, you're already behind.

Write code without AI assistance. Many candidates find their fluency has atrophied from relying on AI coding tools. You need to be able to write correct syntax from memory and work through implementation logic without autocomplete.

Focus on edge cases proactively. After writing any function, ask: what happens if the input is empty? What if two operations arrive simultaneously? What if state changes between a read and a write? Build this into your mental checklist.

---