Concurrency & Thread-Safety

Most of the coding loop, you can prep with a stack of LeetCode mediums. This part you cannot, and that is why it earns a lesson of its own. You build the order book or the counter or the cache, the tests go green, and the interviewer leans in: now two threads call this at once. Where is the race, and what do you lock? At most companies that question is a bonus round. At Robinhood it is the round. The reason is practical. At a brokerage, two threads touching the same buying-power balance is the steady state of a market open. Code that silently lets both spend the same dollar is a real-money bug that ships.

So the bar is this: look at a piece of shared mutable state, see the exact interleaving that corrupts it, and reach for the smallest synchronization that makes it correct without strangling throughput. Reciting that locks exist is the easy part. The real skill is learnable and has a tight structure under it, and this lesson is the authoritative pass on it for the whole guide. The heaps lesson teased the thread-safe order book. This one owns it.

The Robinhood angle

The follow-up is graded on reasoning. Nobody checks whether you memorized a lock-free queue. What earns the round is a clean three-beat answer: state the invariant the data structure must preserve, name the exact interleaving that breaks it, then justify the cheapest synchronization that restores it. "Two reserves both read the available balance as ten thousand before either writes, so both pass a check only one could afford: I take a lock around the read-and-debit." A candidate who says that has already passed. A candidate who jumps straight to "I'd use a lock-free ring buffer" without naming the race sounds like they are reciting. Correctness first, contention second, fanciness only if asked.