Eye Training — Start Here

Part 2 of Bug Hunt: hundreds of short plain-JavaScript snippets, sorted by the kind of code you're looking at.

Read this first. It takes four minutes.

Why a second part

Part 1 taught the map (the bug catalogue), the method (reading in passes) and the levels. Its drills are realistic files with several bugs each.

Part 2 trains something narrower and more important in a live round: the reflex. When a senior engineer's eye lands on socket.on(, it has already asked "where's the off? what if this runs twice? what happens on reconnect?" before they've finished reading the line. Nobody is born with that. It comes from seeing each kind of mistake a few times, in short snippets, until it jumps out.

So this part is organised by surface: the API or construct your eye is looking at. In a real review you never see a label saying "race condition". You see a setInterval with an await inside it.

How these drills differ from Part 1

	Part 1 drills	Part 2 drills
Size	One or more files, 20–60 lines	One snippet, 5–15 lines
Bug count	Shown up front	Hidden until you check
Clean snippets	Never	Some snippets have no bug
Grouped by	Level (L1–L6)	Surface (try/catch, timers, sockets…)
Language	TypeScript	Plain JavaScript

Why some snippets are clean. If every snippet has a bug, you learn to invent one. In an interview, saying "this is fine, and here's why" with confidence is worth as much as finding a bug. A clean snippet is scored right when you flag nothing.

Grades. Each snippet's title starts with J, M or S, the same marks as the catalogue: a junior should catch it, an engineer with about three years' experience should catch it, or it's expected of a senior. Chapters go J → M → S, so each one runs from basics to advanced. If you're at about three years, every J and M is the bar; S is where you stand out.

What to do with each snippet

Name the surfaces. Before you read the logic, list what's on screen: a try, an await, a timer, a listener, a cache.
Run that surface's checks. Every chapter ends with "What your eye checks": five to eight questions to ask whenever you see that surface. That list is the trained eye, written down.
Imagine three things: the call that fails, the call that runs twice (or at the same time), and the call that's slow.
Flag lines, or flag nothing. Then check.
For every miss, find the tell. Each chapter's Tells table lists the visual cue that should have caught your eye. Learn the cue, not the snippet.

Do the drills before reading a chapter's checklist for an honest test. Redo your misses a week later.

The surfaces

#	Surface	Status
11	try / catch / finally	written
12	Promises and async/await	written
13	Timers	written
14	Events, listeners and sockets	written
15	Streams and streaming data	written
16	fetch and the network	written
17	Caching and memoization	written
18	Shared state and races	written
19	Values, equality and numbers	written
20	Objects and arrays	written
21	Loops and iteration	written
22	Functions, `this` and closures	written
23	Time and dates	written
24	Resources and cleanup	written
25	Node servers	idea
26	AI app code	idea
27	Mixed rounds (no labels)	idea

The order follows interview yield: async, timers, events, streaming, network calls, caches and races come up in almost every full-stack round, so they're first. Any order works.

The last chapter matters most. Once a chapter title tells you the topic, you're half-way to the answer. Mixed rounds shuffle every surface together, with no hint, which is what a real review feels like.

Where the depth lives

These chapters are for reps, not explanations. When a bug surprises you, the full story is elsewhere:

JS Code Review: the event loop, promises, races, cancellation and streams, with simulations
The Bug Catalogue: every bug kind, with its level and grade
Casebook V: React and React Native: the same bugs as they show up in a UI