Concurrency Interview Questions: Web Crawler, LRU Cache, Counter

As of 2026-10-16, TrueInterview's bank holds 71 candidate-reported concurrency questions from 23 big-tech companies. Candidates report them mostly in live rounds: 37 phone-screen reports and 33 onsite reports, against 6 in the online assessment, and one question can carry more than one round. The most-linked prompts are Parallel Courses III, Anthropic's Concurrent Web Crawler, an LRU cache with a thread-safe follow-up, and Coinbase's Mining Block. Our view: the skill to train is adding correct synchronization to code that already works, while an interviewer pushes follow-ups at you, and reciting definitions is the weakest use of your time.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

Which concurrency questions do candidates report most?

Ranked by candidate write-ups that link them, eight prompts lead the bank, from Parallel Courses III at 15 write-ups down to Maximum Concurrent Processes / Meeting Rooms at 3. Five of the eight were last reported in a phone screen, so these are prompts you will talk through live. Practise the top three before anything else.

The table gives each prompt's companies, its reported round and month where the bank records one, the write-up links, and the split by the level candidates reported on their write-ups.

Read the level column before the totals. If you are interviewing at L5 or above, weight Parallel Courses III and the two prompts in the table linked only by senior-or-above candidates. Mining Block leans most strongly junior and the LRU cache prompt leans slightly junior, so treat those two as the baseline every level must clear.

What the top prompts ask, and what cracks them

Parallel Courses III (Snowflake, ByteDance, Netflix). The bank files the Snowflake report as an object-oriented design question from a phone screen, and it has the most senior-or-above links in the table, 12 of 15. The bank does not describe its statement or tags here, so read the practice page before deciding which tool it needs, and do not assume it is a locking problem.

Concurrent Web Crawler (Anthropic). TrueInterview's site lists a separate Web Crawler entry, last reported in 2026-05, tagged async, bfs, concurrency, python and threading. The core is a breadth-first frontier drained by a pool of workers. In our view, the two decisions to prepare are the visited set, where check-and-insert must be one atomic step or two workers fetch the same page, and termination, where an empty queue does not mean the crawl is done while a worker is still fetching.

LRU Cache + Thread-Safe Follow-up (five companies). This is the clearest case of the follow-up shape, and it gets its own worked example below.

Mining Block (Coinbase). It is filed as a coding question from a Coinbase onsite, and it is the most junior-leaning entry in the table (see above). Our recommendation: if Coinbase is on your list, give it a timed attempt.

ByteDance's backend fundamentals oral round. The title names the scope: CAP, database indexing, concurrency and logging. Prepare it as a spoken round: for each of the four topics, one two-minute explanation and one incident from your own systems.

Where in the loop do concurrency questions appear?

The round counts in the opening paragraph make concurrency a live-round topic, so we would spend little timed-drill time on threading. The two live rounds differ: in non-coding phone screens, cs fundamentals lead (7) ahead of concurrency (5), while non-coding onsite rounds are led by concurrency (7).

That split changes what you rehearse for each stage. For a phone screen, the table shows concurrency mostly as implementation prompts, so practise those, plus short spoken explanations for the fundamentals questions that come up beside them. Concurrency is the most common non-coding onsite subtype, so for an onsite expect a full problem with follow-ups, and practise at least two follow-ups per problem.

PracHub's guide describes the interactive shape directly: "Interviewers rarely ask for definitions in isolation." The same guide says interviewers show a loop or an interleaving and ask what can go wrong. Train for that by talking through an interleaving aloud, step by step, on a problem short enough for a phone screen.

Which companies ask concurrency questions, and in what format?

Format follows the company. Of the 71 questions, 25 are coding, 20 object-oriented design, 11 behavioral or knowledge, 9 system design, 4 AI-assisted coding and 2 SQL. Coinbase and Uber lean coding, Microsoft and OpenAI lean object-oriented design, ByteDance leans knowledge rounds, and Amazon spreads across three formats.

The question counts come from the bank's company breakdown, which also lists Netflix, Apple, Anthropic and Google at 4 each. Use the row for your target company to pick the prep mode. If your loop is at Microsoft, coding drills on threads are the wrong investment: none of its six questions is coding, so build an object model and then add locking. At ByteDance, half the questions are knowledge rounds, so rehearse explanations before code.

System design versions sit in the booking, inventory and ticketing family: Design Amazon Locker, Microsoft's Design a High-Concurrency Incident Ticket Correlation Platform and Salesforce's Design a Concurrent Car Reservation Service. Design Amazon Locker was last reported in an Amazon onsite in 2026-08. In our view, the decision to prepare in this family is where the reservation becomes atomic: one conditional write in shared storage, so two requests cannot claim the same locker or car.

How does the thread-safe follow-up work?

A common shape, clearest in LRU Cache + Thread-Safe Follow-up, is a known problem first, then a request to make it safe for concurrent callers. Hello Interview's guide says that for senior roles concurrency tends to "show up directly or get added as a follow-up." PracHub's guide gives the answer method: name the shared state, state the invariant in one sentence before writing code, then choose the smallest mechanism that protects it.

Hello Interview's guide gives the low-level design version, a parking lot that now has two cars racing for one spot. The bank also lists Meta's In-Memory Database with Record CRUD and Lock/Unlock, an object-oriented design question last reported in a Meta onsite in 2026-05.

Worked example: LRU Cache + Thread-Safe Follow-up

Start with the ordinary cache, a hash map plus a doubly linked list, and get it correct single-threaded. Then the interviewer asks what happens when two threads call get and put at once.

Say the invariant out loud: the map and the list hold the same set of keys, and the list order is the recency order. A get moves a node to the front and a put may evict the tail, so the two must not interleave. Making the map a concurrent map does not fix this. PracHub's guide makes the same point about a bank transfer: separate atomic balance updates are not enough, because another thread could see the debit before the credit. The multi-field invariant needs one boundary, so the correct first answer is one lock around each operation.

Only then talk about cost. Devinterview's list warns that heavy locking degrades performance through synchronization overhead, and says efficient programs keep time inside critical sections short. A senior follow-up answer names the trade-off: a single lock is simple and correct, sharding by key reduces contention but makes eviction order approximate, and a read-write lock does not help because get also mutates the list.

Which failure modes do interviewers probe, and in which reported prompts?

Our view: five failure modes are worth drilling, and each can be practised on a reported prompt. They are a lost update on a shared counter, a broken multi-field invariant, a deadlock from lock order, a stale wakeup in a work queue, and a lock placed in the wrong process. The prompt mapping in the table is ours, not a record of what interviewers probed.

A race can pass every test you run. Devinterview's list says unhandled shared resources lead to races that corrupt data, and the Go blog describes a real bug where shared-buffer races produced wrong hashes with no errors or panics. Our take: when you finish any thread-safe answer, walk one bad interleaving aloud and show the line that now prevents it. That one habit covers the counter, the cache and the database prompt.

For the work queue, PracHub's guide calls the while loop essential, because a wakeup does not guarantee the condition still holds once the thread reacquires the lock. Hello Interview's guide adds that condition variables underlie blocking queues but are rarely used directly in interviews. Prefer your language's blocking queue in the crawler, and be ready to write the bounded version by hand if asked.

When is a concurrent-sounding prompt not a locking problem?

When the overlap is in time, not in memory. Intervals tie with sorting as the most frequent tag on the 25 coding questions, at 6 each, and intervals lead the phone-screen coding tags with 3. Maximum Concurrent Processes / Meeting Rooms counts overlapping time ranges, and the tool there is a sweep line, not a mutex.

PracHub's guide puts overlapping meetings, trips and sessions in a row of its own, with a sweep line or sorted endpoints as the first tool. The bank also files interval-flavoured coding prompts such as Stripe's Subtract Blocked Periods from Allowed Deployment Windows, last reported in an online assessment in 2026-09.

Before writing any code, name which of three overlaps the prompt has. If several threads touch one object, you need locks, atomics or single ownership. If independent tasks should run side by side, you need a pool or a queue. If time ranges overlap, sort the endpoints and sweep. Practising the Meeting Rooms prompt straight after the crawler is the fastest way to build that reflex, because the two titles sound alike and need opposite tools.

What changes at senior and staff level?

Senior-or-above candidates account for 62 write-up links to these questions, junior-or-below candidates for 39, based on the level each candidate reported. The senior skew sits in object-oriented design (31 vs 14) and system design (10 vs 3), while coding runs 14 vs 18. At senior level, expect concurrency as a design follow-up rather than a standalone puzzle.

By subtype, concurrency questions are linked 14 times by senior-or-above candidates and 4 times by junior-or-below. Multi-thread Atomic Counter and Block Malicious IPs at an API Gateway Across Data Centers are linked only by senior-or-above candidates (see the table). Implement a Multithreaded Map and Double-Checked Locking / Locking Correctness in Multithreaded Code are each linked from 2 senior-or-above write-ups. Mining Block runs the other way, as the table shows.

One reported example shows the boundary moving out of the process. One candidate's write-up reports that a Stripe rate-limiter question began with a sliding window and was then redone for three app servers sharing a store, with a follow-up on staying correct under clock skew. TrueInterview files it under Stripe's system design onsite, asked in July 2026. Prepare to say where the atomic step lives once there is more than one process, and what you do when clocks disagree.

Down-leveling note (our view)

The level signal in these loops sits in the follow-ups. A correct single-lock LRU cache passes the coding bar at any level. What separates a senior answer is the second step: naming the contention cost, choosing whether finer locks are worth it, and saying how the design changes across processes. In our view, stopping at a single lock in a senior onsite risks reading as a mid-level answer. Your project deep dive is the other place to show it, so bring one production story about a race you found and how you proved the fix.

What to prepare for (our view)

Prepare four shapes, each anchored to a reported prompt from the table. A senior candidate should be able to make a known data structure thread-safe, run independent work through a pool with a correct shutdown, reason about a lock order, and move an atomic step into shared storage. Learn a definition, such as a critical section or a memory barrier, only when one of these four answers needs it.

• A structure made safe: LRU Cache + Thread-Safe Follow-up and Multi-thread Atomic Counter. Know the single-lock answer, then the sharded and lock-free trade-offs.
• Work spread across workers: Concurrent Web Crawler. Know the visited-set race, the termination condition and how you bound in-flight requests.
• Locks across several objects: In-Memory Database with Record CRUD and Lock/Unlock. Know lock ordering and what happens when a caller dies holding a lock.
• The boundary outside the process: Block Malicious IPs at an API Gateway Across Data Centers and Design Amazon Locker. Know conditional writes, the cost of a cross-region round trip, and what a stale read does to your guarantee.

Hello Interview's guide says the interviewer wants to see you reason about what breaks when actions overlap and "fix it without overcomplicating things." Use that as your bar for every prompt above: state the single-lock or single-write fix first, then offer one refinement and its cost.

Our take: skip the 40-question definition list

Definition lists train recall, while the reported prompts test repair. The Devinterview repository lists 40 concurrency questions for 2026, and its first asks how concurrency differs from parallelism. Most reported big-tech prompts are named implementation or design problems instead; only 11 of the 71 are knowledge questions, such as ByteDance's oral round. PracHub's guide itself says the strongest preparation is not memorizing a large concurrency library.

The author of a Java concurrency article on levelup.gitconnected.com makes the same argument, saying nobody asks in 2026 what a thread is. That author says interviewers instead want to hear how you implemented something, the trade-offs, and what happens at the JVM, OS and CPU level. We agree with the direction and would go further: replace flashcards with snippet drills. Take ten lines of shared-state code, find the race, and fix it with the least synchronization that works. In our view, a handful of such drills on counter, cache and queue snippets covers more of the reported prompts than a long question list.

Do Java, Python and Go concurrency questions differ?

In our view, the follow-ups change with the runtime more than the prompts do. We would prepare Java answers on thread cost and virtual threads, Python answers on the Global Interpreter Lock for CPU-bound work, and Go answers on how you would find a race, not only how you would avoid one.

Java. Oracle's tutorial says Java has had high-level concurrency APIs since version 5.0, in the java.util.concurrent packages. One author's write-up of a senior Java interview at a company in the Netherlands reports that mentioning virtual threads in Java 21 led to questions on how they work. That is one interview at one unnamed company, so treat it as a hint, not a big-tech rule. The same author says Java threads map 1:1 to OS threads at about 1 MB of stack each, and that thread pools exist to conserve threads.

Python. Python's documentation says threads suit I/O-bound tasks and that the GIL limits threading gains for CPU-bound work. Free-threaded builds arrived in Python 3.13, so say which build you mean if the interviewer asks about CPU parallelism. Hello Interview's guide notes that Python lacks native atomics, so a shared counter needs a lock. For the crawler, Python's documentation says the queue module provides a thread-safe exchange between threads.

Go. The Go blog says its concurrency mechanisms make clean concurrent code easy to write but do not prevent races. The Go blog also says the race detector, enabled with the -race flag, only finds races that the code actually triggers while running. If you code in Go, say how you would test a fix under load, since a passing run proves little.

How we counted

TrueInterview files each candidate-reported concurrency question by company, round, month and the level the candidate reported; these are reconstructed for practice and are not any company's official question list. Of the 71 questions, 63 were last reported within the 12 months before 2026-10-16. Counts measure what candidates reported, not how often a company asks a question, and write-up links count reports that point to a question, not distinct interviews.

FAQ

Are concurrency interview questions on LeetCode representative of big-tech loops?

Partly. Several reported prompts are recognisable coding problems, and interval problems that use the word concurrent are among the most common coding tags (see the Meeting Rooms section). What LeetCode-style practice misses is the follow-up: several of the most-linked prompts, such as LRU Cache + Thread-Safe Follow-up, add a thread-safety step after the base solution, and in our view that step carries the senior signal. Solve the base problem, then rehearse the follow-up aloud.

Which primitives should I know?

Know a mutex, an atomic counter, a condition-variable wait inside a while loop, and a blocking queue, plus your language's thread pool. That set covers the counter, the cache, the crawler and the database prompts in the table. Semaphores matter mainly for bounding in-flight work, such as capping concurrent fetches in a crawler. If you can write each of these from memory and explain why each line exists, you can skip the rest of the library.

Are concurrency questions harder for experienced candidates?

They are more often design-shaped. Senior-or-above write-ups dominate the object-oriented and system design links, while coding links are close to even (see the senior section). For an experienced hire, the extra difficulty is the follow-up: moving from an in-process lock to shared storage, and explaining what that costs. Plan your preparation around those design versions rather than harder coding puzzles.

Do concurrency questions appear in the online assessment?

Rarely in the reports: the OA is the smallest of the three rounds in the opening counts. One OA example in the bank is Stripe's deployment-window problem, which is an interval exercise rather than a threading one. Our advice is to spend timed-drill hours on other OA topics and keep concurrency for spoken practice, where an interviewer can push follow-ups.

Your practice plan

A three-week plan for someone working full time, at about an hour on weekdays and longer sessions at weekends. This is our recommendation, not a guarantee of any outcome.

1. Week one, first half: Solve Multi-thread Atomic Counter in your interview language, then explain the lost-update interleaving aloud and fix it two ways, with an atomic and with a lock.
2. Week one, second half: Build the plain cache, then answer the follow-up in LRU Cache + Thread-Safe Follow-up: shared state, one-sentence invariant, one lock, then the sharding trade-off. Write a bounded blocking queue by hand with while-loop waits.
3. Week two, first half: Do Concurrent Web Crawler with a worker pool, an atomic visited check and a correct termination condition.
4. Week two, midweek: Do Maximum Concurrent Processes / Meeting Rooms straight after, as a sweep line, and write down in one line why no lock is needed.
5. Week two, weekend: Practise your target company's format from the company table. For ByteDance, rehearse the backend fundamentals oral round; for Coinbase, add Mining Block.
6. Week three, first half: Work the design versions: In-Memory Database with Record CRUD and Lock/Unlock for lock ordering, then Design Amazon Locker for a conditional reservation in shared storage.
7. Week three, second half: Take Block Malicious IPs at an API Gateway Across Data Centers and practise moving the counter from one process to shared storage, then answer what changes when clocks disagree. Finish with one mock follow-up round on any prompt above, spoken end to end.

Sources

• TrueInterview question bank — concurrency at big-tech companies — counted 2026-10-16
• Coding Interview Questions by Company · TrueInterview — checked 2026-10-16
• Concurrency Interview Questions: The Failure Modes and Patterns Companies Actually Test | PracHub Knowledge Hub — checked 2026-10-16
• Introduction to Concurrency | Hello Interview Low Level Design — checked 2026-10-16
• GitHub - Devinterview-io/concurrency-interview-questions: 🟣 Concurrency interview questions and answers to help you prepare for your next software architecture and design patterns interview in 2026. · GitHub — checked 2026-10-16
• Introducing the Go Race Detector - The Go Programming Language — checked 2026-10-16
• Interview prep compared: your application, end to end · TrueInterview — checked 2026-10-16
• Medium — checked 2026-10-16
• Lesson: Concurrency (The Java™ Tutorials > Essential Java Classes) — checked 2026-10-16
• threading — Thread-based parallelism — Python 3.15.0 documentation — checked 2026-10-16

Last reviewed: 2026-10-16.