JS Code Review — Course Map

How the AI-era code-review interview works, and how to use this section

Read this first. It takes ten minutes. Basics such as the call stack, closures and this are in FE-10 — JavaScript Runtime Internals; this section assumes them.

The Interview Has Changed

When an AI assistant can write a working endpoint in thirty seconds, "write a function that…" tells an interviewer very little. What it cannot tell them is whether you can judge code: see that a function which works on every test will double-charge a user when two requests arrive 40 ms apart, and explain why in a way the team can act on.

So more companies now give you code you didn't write and watch you work through it. The usual tasks:

• Find the bugs. Often planted, often in async code, often invisible to the existing tests.
• Fix broken async code. A race, a missing await, a retry loop with no backoff.
• Critique the design. "This works. Would you ship it? What would you change and why?"
• Write a polyfill. Promise.all, debounce, promisify, a concurrency pool, from memory, with the edge cases.
• Explain trade-offs out loud. Mutex or atomic SQL? allSettled or all? Chunking or a worker thread?

The common formats

In all of them, talking is half the score. A correct fix with no explanation looks like luck. A clear explanation of the wrong interleaving followed by a corrected one looks like a senior engineer.

The One Idea Behind the Whole Section

JavaScript runs your code on one thread, but it is concurrent.

• Concurrency means several tasks are in progress at once and take turns on one thread. Request A starts, waits for Postgres, and while it waits, request B runs.
• Parallelism means things run at the same instant on different CPU cores. In JS that only happens with Web Workers or worker_threads (Chapter 8).

One thread does not make you safe. Every await, every callback, every event handler is a point where other code can run and change the state you just read. Your function is not one atomic step. It is a series of slices, and other requests' slices are interleaved between them:

async function spend(userId, cost) {
  const wallet = await db.getWallet(userId);   // ← slice 1 ends here; other requests run
  if (wallet.balance < cost) throw new Error('insufficient credits');
  await db.setBalance(userId, wallet.balance - cost);   // ← based on a read that may be stale
}

Two requests can both pass the check against the same balance. This is exactly the SELECT-then-UPDATE race you already know from Postgres, where two transactions both read 100 and both write 20. The fixes are the same family too: make the check and the write one atomic step (UPDATE … SET balance = balance - $1 WHERE balance >= $1), serialise with a lock, or detect the conflict with a version column. If you built a race-safe credit ledger, you have solved this problem once already; this section teaches you to see it in JS and say it out loud. Chapter 5 is all about it.

When you review async code, keep asking one question: "What else can run here, and what could it change?"

The Async Code Review Checklist

This is the one-page version. Each line is expanded in the chapter shown.

How Each Chapter Works

Every chapter from 1 to 11 has the same parts, so you know where to look:

The gym

The section has a practice repo, js-gym/, with small services that have planted bugs and tests that don't catch them. Treat each exercise as a take-home: set a timer, read the code cold, write down every bug with its interleaving, fix it, and add a test that would have caught it. Then check the answer key. Chapter 12 explains how to run it.

Suggested Study Order

If your interviews are soon, do the highest-yield chapters first. Race conditions and async/await traps are planted in almost every review exercise; concurrency control and failure handling are what turn a "found the bug" into a "senior" score.

1. Chapter 5 — Race Conditions. The core skill. Do every timeline.
2. Chapter 4 — async/await Traps. The most common planted bugs.
3. Chapter 7 — Controlling Concurrency. Pools, rate limits, retries with backoff and jitter. Your LLM failover experience maps straight onto this.
4. Chapter 8 — The Node Process Under Failure. Crashes, graceful shutdown, and real parallelism.
5. The gym: 02-credit-wallet, 03-llm-client, 04-job-runner, then review-drills/.
6. Chapter 11 — Polyfills: drill Promise.all, debounce, asyncPool and promisify until you can write them without looking.
7. Chapter 10 — Reviewing a Codebase: how to run a 30-minute review and defend your designs.
8. Then the rest in order: 1, 2, 3, 6, 9.

With more time, read 1 through 11 in order and do each gym exercise after the chapters it practises.

All Chapters

What's Next

Start with Chapter 1 — The Event Loop Under Pressure if you are going in order, or jump to Chapter 5 if your interview is this week.