What they're testing
Whether you've ever debugged something that only happens under load — the kind that won't reproduce locally.
The short answer~30 seconds
A race condition is when correctness depends on an execution order you don't guarantee. The commonest shape is read-modify-write: two threads read a balance of 100, both subtract 30, both write 70 — one transaction vanishes. What makes it hard is that it usually WORKS: the window is microseconds wide, so it never appears on a dev machine, and at 1,000 requests a second in production it happens a few times a day.
The long answer
There are three remedies with different costs. Make the operation atomic — UPDATE … SET n = n - 30 WHERE n >= 30 pushes the compare and the write into one statement and lets the database handle it. Take a lock — only one thread enters the critical section, correct but slower for everyone. Or eliminate the shared state — each thread works on its own data and you merge. The third is best when available, because there's nothing left to race.
Worth stating: races aren't exclusive to multi-threaded code. Single-threaded JavaScript has them: two fetches updating one piece of state, and whichever returns last wins — so a fast typist sees results from an older query. The window here is milliseconds rather than microseconds, so it happens far more often. The fix is cancelling the stale request with AbortController, or ignoring responses that no longer match the current query.
What they'll ask next
?How is deadlock different from a race condition?
A race gives a wrong answer; a deadlock gives none — both sides wait forever. Deadlock needs four conditions to hold at once, and breaking any one is enough. The cheapest in practice is always acquiring locks in a fixed order.
These lose points
- Saying "add a
sleepto avoid the race". That narrows the window and makes the bug harder to reproduce, not gone.