Free lesson · Concurrency Interview Mastery

The whole map, before we start walking

Easy6 min readconcurrencymultithreadinginterview-prep

I don't like courses that drop you into Module 1 without telling you where the road goes. Concurrency especially deserves a map, because the topics build on each other in a specific order, and if you understand why the order is what it is, each module will land better. So let me walk you through the journey - not just what's in each module, but why it's there and how it sets up the next one.

Think of this course as climbing from "what is a thread" all the way to "I can design a lock-free data structure and explain it to a skeptical interviewer." That's a long climb. Here's the path.

graph TD
    M1[1 · Mental Models] --> M2[2 · Your Language]
    M2 --> M3[3 · Synchronization Primitives]
    M3 --> M4[4 · Locking Strategies]
    M4 --> M5[5 · Lock-Free Programming]
    M3 --> M6[6 · When It Goes Wrong]
    M4 --> M6
    M6 --> M7[7 · Concurrency Patterns]
    M7 --> M8[8 · Classic Problems]
    M8 --> M9[9 · Design Problems]
    M9 --> M10[10 · Concurrent Data Structures]
    M10 --> M11[11 · Multi-threaded Algorithms]
    M11 --> M12[12 · To Distributed Systems]
    M12 --> M13[13 · Interviewing on Concurrency]

This diagram shows the learning path through the course as a flow from module one to module thirteen. It begins with mental models, then concurrency in your language, then synchronization primitives. From primitives the path branches: one way leads to locking strategies and then lock-free programming, and both primitives and locking strategies feed into the module on when concurrency goes wrong. From there the path continues through concurrency patterns, classic problems, design problems, concurrent data structures, and multi-threaded algorithms. It finishes by bridging to distributed systems and then to the final module on interviewing about concurrency.

The shape matters. The first half builds your toolbox and your understanding of how things break. The second half is almost entirely application - problems, designs, data structures, algorithms - because once you understand the tools and the failure modes, the rest of concurrency is just combining them well. Let me take you module by module.

The foundation: understanding before tools

Module 1 - Mental Models. We start with what concurrency actually is, and we clear up the confusion that trips up half of all candidates: the difference between concurrency and parallelism. We'll cover processes versus threads, the lifecycle a thread moves through, and then the big one - race conditions and critical sections, the flagship lesson with the animation that makes the whole subject finally click. We end with a couple of things competitors skip: the memory model you've been ignoring, and the question of when you shouldn't reach for concurrency at all. That last one matters more than you'd think - knowing when not to use a thread is senior-engineer judgment.

Module 2 - Concurrency in Your Language. Concepts are universal, but the tools aren't. How you spawn a thread, what memory guarantees you get, and what footguns you inherit differ a lot between Java, Python, C++, C#, and Go. This module is your reference layer for your language of choice - the GIL if you're in Python, goroutines and channels if you're in Go, the memory model and ReentrantLock if you're in Java, and so on. You can read just your language and skim the rest, or read them all to understand why interviewers sometimes ask "how would this differ in another language."

The toolbox: locks and the art of using them

Module 3 - Synchronization Primitives. This is the core toolkit. Mutexes, semaphores, condition variables, read-write locks, barriers. Each one solves a specific coordination problem, and the interview loves asking you to pick the right one. We add a lesson on monitors, the construct your language quietly built a lot of the rest on top of.

Module 4 - Locking Strategies. Having a lock is easy. Using locks well is the hard part, and it's where a lot of senior signal lives. Coarse versus fine-grained locking, reentrant locks, try-lock and timed locking, optimistic versus pessimistic concurrency, and two-phase locking - the strategy databases use. I'll bring in what I work on directly here, because the systems I build at Google live and die by these decisions. We finish with lock ordering, which is your first real defense against the topic of the very next module.

Module 5 - Lock-Free Programming. This is where concurrency gets genuinely hard and genuinely impressive. Compare-and-swap, atomic operations, the infamous ABA problem, memory ordering, and false sharing - the cache-coherence detail that makes interviewers lean forward. You don't need lock-free programming for most jobs. You absolutely need it to clear a senior bar at a top company, and to win the "now make it lock-free" follow-up.

The dark side: every way it breaks

Module 6 - When Concurrency Goes Wrong. Deadlock, livelock, starvation, lost wakeups, spurious wakeups, thread leakage, priority inversion. Every one of these is a real production incident waiting to happen, and every one is a favorite interview question. We add a practical lesson on debugging these in production - reading thread dumps, detecting deadlocks - because the interview question "how would you debug a deadlock in production" is one almost no one prepares for.

Interview: Modules 4, 5, and 6 are the heart of the senior-level concurrency interview. If you can fluently discuss why you'd choose optimistic over pessimistic locking, sketch a lock-free counter, and explain how you'd diagnose a deadlock from a thread dump, you are already ahead of most candidates. These three modules are where I'd spend the most time.

The application: patterns, problems, and design

Module 7 - Concurrency Patterns. The reusable shapes: thread pools, producer-consumer, reader-writer, future/promise, fork-join, double-checked locking, plus pipeline and scatter-gather. Patterns are the vocabulary of design rounds - naming the right pattern signals that you've seen the problem before.

Module 8 - Classic Synchronization Problems. The canon. Print FooBar, Zero-Even-Odd, FizzBuzz multithreaded, building H2O, readers-writers, the unisex bathroom, the sleeping barber, dining philosophers, cigarette smokers, Santa Claus. These get asked directly, constantly. We don't just solve them - we walk the reasoning so you can solve the variant the interviewer invents on the spot.

Module 9 - Design Problems. Now we build real things under contention: a thread-safe cache with TTL, a rate limiter, a deferred callback executor, a ticket booking system, a multithreaded web crawler, a pub-sub system, a task scheduler with dependencies. These are low-level design rounds. They reward everything from the earlier modules at once.

Module 10 - Concurrent Data Structures. A concurrent hash map, a blocking queue, a concurrent bloom filter, a lock-free queue, a concurrent priority queue, a thread-safe trie. Designing a data structure that stays correct under concurrent access is a top-tier interview question, and it ties primitives, locking strategy, and lock-free thinking into one artifact.

Module 11 - Multi-threaded Algorithms. Taking algorithms you know - merge sort, word frequency counting, graph traversal - and parallelizing them correctly. This is where you prove you can make code faster with threads without making it wrong.

The horizon: distributed systems and the meta-skill

Module 12 - From Threads to Distributed Systems. This is the bridge no competitor builds. Every concept you learned on one machine has a cousin across many machines: a mutex becomes a distributed lock, compare-and-swap becomes consensus, a barrier becomes a coordination service. I'll show you the map, because once you see it, distributed systems stop being a separate scary subject and become "concurrency, but the threads are computers." We also cover testing concurrent code, which almost nobody teaches and which instantly signals seniority.

Module 13 - Interviewing on Concurrency. The finale, and in some ways the reason I built the whole course. How to talk about concurrency without freezing - my own story, turned into a method. How to reason about thread-safety out loud. And how to survive the follow-up gauntlet, where the interviewer keeps escalating "now make it lock-free, now make it distributed" until they find your floor. This module is where everything you learned becomes something you can say.

Tip: You don't have to go strictly in order, but I'd strongly recommend doing Modules 1 through 6 in sequence before jumping around. The application modules assume you're fluent in the toolbox and the failure modes. Skip ahead to dining philosophers before you understand condition variables and you'll be memorizing a solution instead of understanding one - which is exactly the trap that fails people on the follow-up.

One promise about the road ahead

This is a long climb, and I won't pretend otherwise. But here's what I can promise: by the end, the thing that felt like a fog - threads, locks, races, all of it - will feel like a set of moving pictures you can see clearly in your head and describe out loud without hesitating. That's not a small thing. That's the exact difference between the interview I failed and the one I passed.

Let's get to it. Module 1 starts with the simplest and most misunderstood question in the whole subject: what does it actually mean for two things to happen "at the same time"?

Back to Concurrency Interview Mastery