Concurrency & Systems

Anthropic keeps its loop quiet, but one live problem surfaces more than any other: build a web crawler for a small site, then make it multithreaded, then filter the crawled data by some characteristic. Treat the graph traversal as a warm-up. Each "then" is where the interview happens. A solution that runs clean on one thread can corrupt its visited set the moment a second worker touches it. That is the most common way this round goes sideways, and it goes sideways quietly: single-threaded, the same code looks correct.

Anthropic builds Claude on systems where many requests hit shared state at the same time. The people across the table want to watch you reason about what happens when two threads reach the same line. The bank of live problems is famously small, roughly six recurring shapes most candidates already know walking in. That makes follow-up depth the differentiator. The base crawler is forty seconds of work. The round is the layers stacked on top: bound the concurrency, dedup safely, isolate a dead host, slow down per domain, and explain why threads even help here when Python has a global lock.

The Anthropic angle

"Now make it concurrent" is the load-bearing follow-up, and clean object structure is what lets a new constraint slot in instead of forcing a rewrite. Anthropic coding is practical by design, recruiters say so directly, and the grade is how calmly you absorb scope that keeps expanding onto code you already wrote. A crawler that is a single procedure has nowhere to put a per-host delay or a domain filter without surgery. A crawler that is an object carrying a fetch policy, a visited set, and a bounded pool takes each new requirement as a few lines. Build the first version with the second version's seams already there, and narrate the four real decisions out loud as you go, because that narration is most of what gets scored.