Convert Stack Samples to Trace Events: Given a list of sampling-profiler snapshots — each a (timestamp, stack) pair where stack is ordered outermost-to-innermost — convert them into a chronological list of (type, timestamp, name) start/end trace events. A follow-up (Part 2) adds a filter: a frame must persist across at least N consecutive samples before emitting events, with start times backdated to the frame's first-seen timestamp.

The key insight is stack diffing: for each consecutive pair of samples, find the longest common prefix; emit end events (innermost first) for frames only in the earlier stack, then start events (outermost first) for frames only in the later stack. Part 2 requires tracking per-frame streak counts and first-seen timestamps, emitting backdated starts when a streak reaches N. Time complexity is O(S * D) where S is the number of samples and D is max stack depth. Follow-ups probe handling of recursive calls (same function name at different depths are distinct frames) and same-timestamp ordering (ends before starts). Correctness of the diffing logic under edge cases (empty stacks, identical consecutive stacks, recursion), clean incremental extension to Part 2 without a full rewrite, and ability to reason aloud about temporal semantics.

Implement an In-Memory Database: Build a simplified key-value store across four progressive levels. Level 1: basic SET, GET, DELETE. Level 2: filtered SCAN with prefix/field conditions. Level 3: TTL support — entries expire at a given timestamp. Level 4: backup/restore via ZIP and UNZIP operations (compress and decompress the stored state).

Start with a plain dict for Level 1. Level 2 requires iterating and filtering — avoid premature optimization. Level 3 needs per-key expiry metadata and lazy or eager expiration; lazy is simpler and usually sufficient under the time constraint. Level 4 serializes the current state; a clean internal representation makes this straightforward. The key insight is designing the internal schema in Level 1 so each subsequent level is an additive patch, not a rewrite. Follow-ups test TTL edge cases and concurrent access. Incremental design discipline — each level should build cleanly on the last. Interviewers watch whether candidates over-engineer early levels or back themselves into corners that require rewriting core data structures.

Implement a Banking System: Build an in-memory bank where all operations are processed in non-decreasing timestamp order. Operations include DEPOSIT, WITHDRAW (fail if insufficient funds), TRANSFER between accounts, and TOP_SPENDERS — return the N accounts with the highest total outgoing spend.

Each account is a dict entry tracking balance and cumulative spend. Process events in timestamp order (input guarantees this). TOP_SPENDERS is a partial sort — use a heap or sorted slice rather than a full sort for efficiency. The key insight is maintaining the spend accumulator on every debit rather than recomputing on query. Follow-ups add interest accrual, account freezing, or concurrent transaction safety, which shifts the problem toward locking or optimistic concurrency. Clean handling of failure cases (overdraft, missing account), efficient TOP_SPENDERS without O(N log N) on every call, and correct timestamp semantics when multiple events share the same timestamp.

Design an LLM Inference Batching System: A single GPU processes requests sequentially, but batching multiple requests together amortizes compute cost — 100 requests take roughly the same time as 1. Design a system that accepts individual inference requests from users, batches them efficiently, routes batches to available GPUs, and returns responses to the correct requesting user with acceptable latency.

The key components are an ingestion layer (HTTP/gRPC frontend), a batching queue with a configurable wait window (collect requests for up to T ms or until batch size B, whichever comes first), a GPU worker pool with health-checked routing, and a response demultiplexer that correlates GPU outputs back to originating requests via request IDs. The central tension is throughput versus latency: a longer wait window increases GPU utilization but raises p50 latency. Follow-ups probe dynamic batch sizing based on request length (token count), handling heterogeneous model sizes, and failover when a GPU worker crashes mid-batch. Whether the candidate independently identifies the batching window trade-off, how they handle the request-response correlation problem (not trivial with async batching), and depth on GPU utilization metrics versus SLA guarantees.

Design a Distributed Search System for 1 Billion Documents at 1 Million QPS: Build the infrastructure to index and query a corpus of 1B documents under a query load of 1M requests per second. Address sharding strategy, caching, and — specific to Anthropic's context — LLM-augmented reranking of results.

Partition the index by document ID hash across N shards; each shard stores an inverted index. Query fanout broadcasts to all shards, which return top-K local results; a coordinator merges and reranks globally. A multi-tier cache (query-result cache at the coordinator, shard-level posting-list cache) cuts most of the QPS before it hits disk. The LLM reranking layer is a late-stage post-processor on the top-50 candidates — decoupled from retrieval to avoid adding GPU latency to the hot path. Follow-ups probe hotspot mitigation (popular queries hit the same shards), consistency on index updates, and the trade-off between ANN vector search and classic BM25. Clean separation of the retrieval pipeline from the reranking stage, awareness of the fanout amplification problem (1M QPS at the coordinator becomes N*1M QPS across shards), and realistic discussion of caching effectiveness.

Design the Claude Chat Service: Design the backend service that powers a multi-turn conversation product like Claude.ai. Users send messages and receive streaming token responses; conversations must persist across sessions; the system must handle high concurrent user load.

Core components: an API gateway handling auth and rate limiting, a conversation state store (per-user conversation history in a database, with the full context serialized per turn), a streaming inference gateway that forwards assembled prompts to the model backend and streams tokens back via SSE or WebSockets, and a session cache to avoid re-fetching history on every turn. Key design decisions: where to truncate context when it exceeds the context window (sliding window vs. summarization), how to handle mid-stream failures (partial response recovery), and how to isolate noisy tenants. Follow-ups probe abuse prevention, cost accounting per user, and multi-region latency. Awareness that conversation history grows unboundedly and must be managed, correct streaming architecture (SSE vs. WebSocket trade-offs), and whether the candidate naturally thinks about cost as a first-class constraint given inference pricing.

Tell me about a time you made a safety-first decision in a project, even if it meant a trade-off in speed or features.

Use a specific engineering example where you explicitly chose a slower, safer path over a faster, riskier one — ideally one where you can quantify the trade-off (delayed a launch by X weeks, chose a less capable model to avoid a failure mode). Lead with the risk you identified, the options you weighed, and why safety took precedence. Avoid vague platitudes about 'always prioritizing safety'; the interviewer wants evidence you've actually navigated the tension. Follow-ups probe whether the decision paid off and how you handled pushback from stakeholders who wanted to move faster. Genuine internalization of safety-versus-velocity tension — not rehearsed talking points. Interviewers flag candidates who only share stories where being cautious was also the popular choice.

Tell me about a time a technical misjudgment you made led to a project delay. What did you learn?

Choose a real failure with concrete impact — not a humble-brag ('I worked too hard'). Structure: what was the misjudgment, what assumptions were wrong, what were the downstream effects, what you did to recover, and what you changed afterward. The key is intellectual honesty; Anthropic interviewers explicitly flag candidates who cannot own a genuine mistake. Follow-ups push on what signals you missed and whether the learning has since changed a recurring pattern in your work. Psychological safety with failure, specificity (vague regret is a red flag), and whether the candidate demonstrates updated behavior — not just insight in retrospect.

Describe a time you had a technical disagreement with a colleague. How did you resolve it?

Pick an example where the stakes were real and you did not simply defer or 'win.' Describe the technical crux of the disagreement clearly, the evidence each side brought, and the resolution process — whether that was an experiment, a third-party tie-break, or one side updating their view. Emphasize the intellectual content of the disagreement, not the interpersonal dynamics. Follow-ups probe what you did when you believed you were right but lost the decision, and whether the outcome validated or refuted your position. Ability to disagree rigorously without being combative, comfort with uncertainty and updating on new evidence, and whether the candidate can articulate the other side's position charitably.

Anthropic Interview Questions

Anthropic runs a 5-to-6-stage loop: recruiter screen, 90-minute CodeSignal online assessment (OA), hiring manager call, and two onsite loops (Loop 1 = coding + system design; Loop 2 = project deep dive + values/culture). The OA uses a well-known, small question bank and candidates are typically told the prompt family in advance; live rounds are evaluated by senior engineers. The values and culture round is explicitly flagged by Anthropic recruiters as where most candidates are eliminated, outweighing technical performance. The process takes roughly 3-4 weeks from recruiter screen to offer.

17 real questions across 3 rounds

Reported via Questions corroborated across: Medium first-hand write-up by Anqi Silvia (2025 SWE interview experience + concurrency follow-up article), prachub.com Anthropic coding question database, 1Point3Acres thread and question bank (banking system, duplicate files, LRU cache), GitHub repo ryanhestin/anthropic-challenge (viral call-stack sampler), showoffer.io (banking system), interviewing.io Anthropic page, and coditioning.com onsite coding guide.

Run a Anthropic mock with the AI interviewer. It asks questions like these, follows up on your answers, and tells you exactly what to fix. The only score that means anything is the one on your real answers.

Continue with Google

Keep prepping

All company interviews