A candidate can rattle off "mutex versus semaphore" from memory in about four seconds. Ask what breaks if a semaphore gets signaled by a thread that never called wait on it in the first place, and the confident tone drops fast. That's not a trick question. It's the actual difference between the two, and it's also the exact spot where most concurrency answers stop being memorized and start being real.
This post covers the multithreading interview questions that come up most across the SDE-1 and SDE-2 loops candidates reach through tools like LastRoundAI's auto-apply: thread vs process, the thread lifecycle, race conditions and critical sections, mutex vs semaphore vs monitor, deadlock vs livelock vs starvation, synchronized and locks, volatile and memory visibility, atomicity, thread pools, and the producer-consumer pattern. Twelve real sample answers, not a glossary you've already read three times this week, the kind of prep that matters once a strong resume has already gotten you into the room.
The multithreading interview question that trips people up first: concurrency vs parallelism
What's the difference between concurrency and parallelism?
Concurrency is structuring a program so multiple tasks can make progress during overlapping time periods, even on one core, by interleaving execution. Parallelism is actually running multiple tasks at the exact same instant, which requires more than one core to do it. A single-core laptop running a busy web server can be extremely concurrent (juggling thousands of connections through fast context switches) while never once being parallel.
I'd argue this question trips up mid-level candidates more than junior ones, not less, because junior candidates haven't yet built the reflex of assuming multi-core hardware everywhere. Once you've worked with a thread pool sized to core count for months, it's easy to forget that concurrency doesn't require any of that. It just requires not blocking.
Thread vs process, and the six states in between
What's the difference between a thread and a process?
A process is an independent unit of execution with its own address space: its own code, heap, stack, and file descriptors. A thread is a lighter unit of execution that lives inside a process and shares that process's address space and open files with every other thread in it. Creating a thread is cheap precisely because the kernel skips the part where it sets up a fresh address space; two threads can already see the same memory, so passing data between them doesn't need pipes or sockets, just a shared reference and some discipline about who's allowed to touch it when.
What are the six states in a thread's lifecycle?
New (created but not started), Runnable (eligible to run, whether or not it's actually running right now), Blocked (waiting to acquire a lock held by another thread), Waiting (paused indefinitely until another thread notifies it), Timed Waiting (paused for a bounded amount of time), and Terminated (finished, for good or for bad). Candidates usually get New, Runnable, and Terminated without prompting. The part that separates a strong answer is the Blocked vs Waiting distinction: Blocked means you want a lock somebody else has, Waiting means nobody's holding anything, you're just sitting there until told to move.
Race conditions and critical sections: where the real questions live
What's a race condition, and what makes a critical section correct?
A race condition happens when two or more threads touch shared data at the same time, at least one of them writes, and the final result depends on the order the operations happen to interleave in. A critical section is the piece of code that touches that shared data, and a correct solution for protecting it needs three things: mutual exclusion (only one thread in there at a time), progress (a thread outside the section can't block one that wants to enter), and bounded waiting (a limit on how many times other threads cut in line before a waiting thread finally gets its turn).
That last property is the one candidates forget exists. A lock that satisfies mutual exclusion but lets one thread starve forever "works" in the sense that it never corrupts data. It's still wrong.
Mutex vs semaphore vs monitor: three tools, one job, different rules
Mutex vs semaphore vs monitor: what's actually different?
A mutex is a lock with ownership. Whoever locks it is the only thread allowed to unlock it, and it's strictly binary: locked or unlocked. A semaphore is a signaling mechanism built around a counter that can go above one, has no concept of ownership, and can be signaled (incremented) by a thread that never waited (decremented) on it at all. That ownership gap is exactly why the semaphore-signal question at the top of this post has a real answer instead of a gotcha: a producer thread signaling "slot available" was never the thread that consumed the slot, and that's fine, that's the whole design.
A monitor is a higher-level construct that bundles a mutex with condition variables, so a thread can wait inside the lock and get woken up once a specific condition changes, instead of manually re-checking a flag in a loop. Java's synchronized keyword plus wait/notify is a monitor. Here's the shape of it, protecting a shared counter:
synchronized (lock) {
while (queue.isEmpty()) {
lock.wait(); // releases the lock while waiting
}
int item = queue.poll();
lock.notifyAll(); // wakes any thread blocked on wait()
}Notice the while loop, not an if. Spurious wakeups are real, and a thread that woke up needs to re-check the condition before trusting it.
Deadlock, livelock, and starvation aren't three names for the same bug
| Failure mode | What's actually happening | Classic fix |
|---|---|---|
| Deadlock | Two or more threads each hold a resource the other needs, and neither will let go | Break one of the four Coffman conditions, usually via lock ordering |
| Livelock | Threads keep changing state in response to each other, but nobody makes forward progress | Add randomized backoff so the threads stop stepping on each other in lockstep |
| Starvation | One thread is repeatedly denied a resource it needs, even though the system as a whole is running fine | Aging: gradually raise the priority of a thread the longer it waits |
What are the four conditions required for a deadlock?
Mutual exclusion (a resource can only be held by one thread at a time), hold and wait (a thread holding one resource is waiting on another), no preemption (a resource can't be forcibly taken away), and circular wait (a cycle of threads, each waiting on a resource the next one holds). Break any single one of the four and deadlock becomes impossible. Most production teams don't implement formal deadlock detection; they just enforce a global lock-acquisition order and move on, which is a slightly boring answer but the honest one.
How is livelock actually different from deadlock, and where does starvation fit in?
In a deadlock, nothing moves. In a livelock, everything moves, constantly, and none of it counts. Picture two threads that each detect a conflict and both politely back off at the same time, then both retry at the same time, forever, like two people in a hallway who keep stepping the same direction to avoid each other. Starvation is a different animal: it's not about two threads colliding, it's about one thread consistently losing a fairness fight it never actually deadlocks or livelocks in. A strict priority scheduler with no aging can starve a low-priority thread indefinitely while the rest of the system hums along, which is why interviewers who ask about priority scheduling almost always follow up with "what stops starvation."
synchronized, Lock, and volatile solve three different problems
What does synchronized actually lock, and what does a Lock object give you that synchronized doesn't?
A synchronized instance method locks on the object's own monitor (its intrinsic lock, tied to this); a synchronized static method locks on the class object instead, which is a distinction that trips people up because both look identical at the syntax level. A synchronized block lets you pick the lock object explicitly, which is usually the better choice once a class has more than one thing worth protecting separately.
An explicit Lock (from java.util.concurrent.locks) gives you things synchronized simply can't: tryLock() to attempt acquisition without blocking forever, a timed variant, interruptible acquisition so a stuck thread can actually be cancelled, and optional fairness so the longest-waiting thread gets priority instead of whichever thread the JVM happens to favor. The cost is that you now own the bookkeeping. Forget the matching unlock() in a finally block and you've built a permanent deadlock generator, something synchronized's automatic release on block exit protects you from by construction.
What does volatile guarantee, and what doesn't it guarantee?
Using a volatile variable establishes a happens-before relationship: any write to it is guaranteed visible to any thread that reads it afterward, and that thread also sees the side effects of whatever code led up to the write, per the Oracle Java Tutorials' page on atomic access. What it doesn't give you is atomicity for compound operations. Reading a volatile int, incrementing it, and writing it back is still three separate steps, and two threads can still interleave those steps and lose an update, volatile or not. People treat volatile as "the lightweight lock" and it isn't a lock at all. It's a visibility guarantee, full stop.
Is counter++ atomic in Java?
No, and this is one of the more reliable ways to filter candidates who've actually debugged a race condition from ones who've only read about them. counter++ compiles down to a read, an increment, and a write, three separate steps, and Oracle's own atomic-access documentation is explicit that "reads and writes are atomic for reference variables and for most primitive variables (all types except long and double)," but a compound action like increment-then-store is a different thing entirely, per the same page. If two threads both read the counter at 5 before either writes back, you get 6 instead of 7, and the bug won't show up in a unit test running on one core with no contention. It shows up three weeks later in production under load, which is exactly the kind of thing this question is trying to surface.
Thread pools, executors, and the producer-consumer pattern
Why use a thread pool instead of spawning a thread per task?
Because thread objects aren't free. Oracle's concurrency tutorial puts it plainly: "thread objects use a significant amount of memory, and in a large-scale application, allocating and deallocating many thread objects creates a significant memory management overhead," which is why most executor implementations in java.util.concurrent hand work to a fixed pool of reusable worker threads instead, per Oracle's page on thread pools. The same documentation makes a point that's easy to miss: a fixed pool degrades gracefully under load, queuing extra work instead of collapsing, while a naive thread-per-request server can stop responding to everything at once once thread overhead eats the machine alive. That's the actual interview answer instead of the two-word shortcut "it's efficient."
What's the producer-consumer pattern, and why does the queue between them need to be bounded?
One or more producer threads generate work and push it onto a shared queue; one or more consumer threads pull work off that same queue and process it, and a monitor (or a blocking queue that hides the monitor for you) coordinates so producers block when the queue is full and consumers block when it's empty instead of spinning. An unbounded queue looks safer on paper because nothing ever blocks, but a slow consumer paired with a fast producer just turns an unbounded queue into an unbounded memory leak with extra steps. Bounding it forces backpressure, which is the actual fix, not a compromise you settle for.
The pattern underneath all of it
The mixup we see most often in LastRoundAI mock interview sessions isn't mutex vs semaphore. It's synchronized vs Lock: candidates can define both correctly, then freeze the moment the follow-up becomes "which one would you reach for if a thread might need to give up waiting after 200 milliseconds." That's not a memorization gap. It's the same gap every section in this post keeps circling back to: a clean definition is step one, and the interviewer already assumes you have it.
Rehearsing that follow-up out loud, the way LastRoundAI's mock interviews let you do before it actually counts, is a different skill than reading about it, which is also part of why LastRoundAI built an AI interview copilot that listens to the live question and surfaces the next likely angle in real time, so "what's a deadlock" turning into "how would you detect one in a running system" doesn't catch you flat-footed. If you're prepping a specific company loop rather than concurrency questions in the abstract, our Amazon SDE-2 interview questions breakdown covers the systems and threading questions candidates have actually reported, and our operating system interview questions guide picks up right where this one leaves off, on scheduling, paging, and context switches.
Know the four Coffman conditions cold if you want. Just don't stop there. The interviewer won't.
How this list was built
Worth being straight about where these questions come from, because plenty of pages in this category are not. The set was compiled from a research pass across official documentation, vendor release notes, published engineering writing and public discussion of hiring processes, then cross-checked against the current version of each technology so nothing here describes behaviour that has since changed.
What that means in practice: these are the questions the material supports as reasonable and current for this role, not a transcript of any one company's loop. We have not sat in on your interview and we are not going to claim we have. Treat the list as well-sourced preparation rather than a leaked question bank, and expect your panel to phrase things their own way.
If you spot something out of date, tell us at contact@lastroundai.com and we will fix it.
Frequently asked questions
Should I memorise concurrency syntax for the interview?
Rarely worth it. Most interviewers care that you know what to reach for and why, and will not fail you for forgetting an exact flag. Being confidently wrong about behaviour costs far more than admitting you would check the documentation.
What is the most common mistake in concurrency interviews?
Answering the question that was asked and stopping there. The strongest candidates add the trade-off or the failure mode without being prompted, which is what signals real use rather than revision.
How long does it take to prepare for a concurrency interview?
If you already work with concurrency day to day, a focused week on the areas you avoid in practice is usually enough. Coming in cold, expect three to four weeks. The gap is rarely knowledge; it is being able to explain something you normally just use.
What concurrency topics come up most often?
Interviewers concentrate on the parts that cause production incidents rather than the parts that are pleasant to learn. Expect the fundamentals to be assumed and the follow-up questions to sit one layer below what a tutorial covers.