yoklainterview sim
ProgressHistory

Backend Concurrency Interview Questions

75 verified Backend Concurrency interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

ConcurrencyDifficulty 1
What is the key memory difference between a process and a thread?
  • aThreads in the same process share its memory; separate processes normally have their own address spaces✓
  • bProcesses share memory by default, while each thread gets an isolated address space
  • cBoth threads and processes always get fully isolated memory
  • dThreads share memory only when they happen to run on the same CPU core
Explanation:A process owns an address space; its threads live inside it and share that memory. That sharing is what makes threads cheap to communicate with — and what makes shared-state bugs possible. Sharing is not tied to CPU cores (d): threads share memory no matter where they are scheduled.
ConcurrencyDifficulty 1
What is the difference between concurrency and parallelism?
  • aThey mean exactly the same thing — the two words are interchangeable names for one concept
  • bConcurrency is managing multiple overlapping tasks; parallelism is executing more than one at the same physical instant✓
  • cParallelism can happen even on a single core, while concurrency always requires multiple cores
  • dConcurrency applies only to I/O-bound work and parallelism only to CPU-bound work
Explanation:Concurrency is about structure — juggling tasks whose lifetimes overlap, even on one core. Parallelism is about execution — tasks literally running at the same instant, which requires multiple cores. A single-core machine can be concurrent but never truly parallel, which is why (c) is exactly inverted.
ConcurrencyDifficulty 2
A server keeps a shared counter in memory.
counter = 0

function handle_request():
    counter = counter + 1

Two threads each call handle_request() 1000 times. What is the final value of counter?
  • aAlways exactly 2000 — the increment is a single line, so it cannot be interrupted
  • bAlways exactly 1000 — the second thread's writes overwrite the first thread's writes
  • cAt most 2000, but possibly less — concurrent increments can be lost to a race condition✓
  • dThe program crashes, because two threads may not write the same variable
Explanation:counter = counter + 1 is a read-modify-write sequence. When two threads interleave between the read and the write, one increment overwrites the other and is lost, so the result can fall below 2000. Being a single line of source (a) means nothing — it compiles to multiple steps — and concurrent writes do not crash a program by themselves (d).
ConcurrencyDifficulty 1
In concurrent programming, what is a critical section?
  • aThe most performance-critical hot path of the program, which should be optimized before anything else
  • bCode that accesses a shared resource and must run in only one thread at a time✓
  • cThe code that runs during application startup, before any threads exist
  • dA block whose uncaught exceptions bring down the whole process
Explanation:A critical section is the region that touches shared state, so its execution must be made mutually exclusive (typically with a mutex). The name says nothing about performance (a) — that confusion comes from reading 'critical' as 'performance-critical'.
ConcurrencyDifficulty 2
What does holding a mutex actually guarantee?
  • aAt most one thread holds it at a time, so the code between lock and unlock never runs concurrently✓
  • bThe code it protects is pinned to a single CPU core, making it faster
  • cThe OS scheduler will not preempt the thread while it holds the lock
  • dConflicting writes are detected and rolled back automatically
Explanation:A mutex provides mutual exclusion and nothing more: one holder at a time. It does not stop preemption (c) — the holder can be paused mid-section; other threads simply cannot enter until it releases. Rollback semantics (d) belong to transactions, not locks.
ConcurrencyDifficulty 2
thread 1:        thread 2:
lock(A)          lock(B)
lock(B)          lock(A)
# ... work ...   # ... work ...
unlock(B)        unlock(A)
unlock(A)        unlock(B)

What can happen when these two threads run at the same time?
  • aThey always complete, because lock requests are granted in first-come-first-served order
  • bA runtime error is raised: the same mutex cannot be requested from two different threads
  • cLivelock: both threads endlessly acquire and release the locks without doing work
  • dDeadlock is possible: each thread may hold one lock while waiting forever for the other✓
Explanation:If thread 1 acquires A and thread 2 acquires B before either takes its second lock, each waits on a lock the other holds — forever. FIFO granting (a) is not a general guarantee and would not help, since the threads wait on different locks. Livelock (c) involves active retrying, which plain blocking locks do not do.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview