JavaScript interviews concentrate on a small number of things the language does differently from everything else: closures, `this`, prototypes and the event loop. Get those right and most other questions follow. Below are the ones asked most often, each with a model answer. Middle: deeper understanding, optimization, and real-world situations.
Practical: a counter or a cache where the state must not be reachable from outside, a function factory, or anything that has to remember one value between calls. The classic bug is for (var i = 0; ...) setTimeout(() => console.log(i)) printing the final value every time, because all callbacks close over one binding. let creates a fresh binding per iteration and fixes it.
Four rules, in order of precedence: new, then explicit call/apply/bind, then a method call where this is the object before the dot, then the default — undefined in strict mode. It breaks when a method is passed as a callback, because the dot is gone by the time it is called. Fixes are bind at the point of passing, an arrow wrapper, or defining the method as a class field.
Almost none at runtime — class is syntax over the same prototype mechanism. The differences that matter: class bodies are always strict mode, class declarations are not hoisted for use, methods are non-enumerable, and calling a class without new throws instead of silently doing the wrong thing. extends and super are genuinely easier than wiring prototypes by hand.
Given a setTimeout(fn, 0) and a resolved Promise.then scheduled in the same tick, the promise callback runs first. The reason is that after the current script finishes, the engine drains the whole microtask queue before taking a single macrotask from the timer queue. It follows that a microtask which schedules another microtask can block rendering indefinitely, while a setTimeout cannot.
await inside a loop is sequential — each iteration waits for the previous one. To run in parallel you start all the promises first and then await them together with Promise.all. Reach for allSettled when partial failure is acceptable, race for a timeout, any for the first success. Getting this wrong turns a 200 ms request into 20 requests of 200 ms each.
Detached DOM nodes still referenced by JavaScript, listeners never removed, timers never cleared, and closures holding on to large objects — plus caches that only ever grow. You find them by taking heap snapshots in DevTools before and after a repeated action and comparing what survived. WeakMap and WeakSet hold keys weakly, which is why they are the right structure for attaching data to DOM nodes.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle JavaScript interview →