The JavaScript Intermediate Interview

It logs 3, 3, 3. var i is function-scoped, so all three callbacks close over the same i. The loop finishes (leaving i === 3) before any timeout fires, so each logs 3.

Fix 1, change `var` to `let`. let is block-scoped and, specially, gets a fresh binding per iteration, so each callback closes over its own i: 0, 1, 2.

Fix 2, without `let`, create a new scope per iteration with an IIFE (or by passing i as a setTimeout argument) so each callback captures its own copy:

Mechanically: a function value carries a hidden reference to the lexical environment (the scope record) it was created in. As long as that function is reachable, the whole environment it closed over stays reachable too, so the garbage collector can't reclaim those variables. That's why the counter's count survives after the outer function returns.

It becomes a leak when a long-lived closure keeps a large thing alive unnecessarily, e.g. an event handler that closes over a big DOM subtree or array, and is never removed. The fix is to null out references you no longer need, remove listeners, and avoid closing over more than you use. Engines optimise by only retaining variables the closure actually references, but you can still pin large objects by accident.

Output: A, D, C, B.

Step by step:

1. console.log('A') runs synchronously → A.
2. setTimeout(..., 0) schedules its callback on the macrotask (task) queue.
3. Promise.resolve().then(...) schedules its callback on the microtask queue.
4. console.log('D') runs synchronously → D.
5. The call stack is now empty. The event loop drains the entire microtask queue first → C.
6. Only then does it take one macrotask → B.

The rule that wins this question: after each task, the engine empties all microtasks (Promise callbacks, queueMicrotask, await continuations) before rendering or taking the next macrotask (setTimeout, I/O). Microtasks always beat timers.

An async function always returns a Promise. await x roughly means: evaluate x, wrap it with Promise.resolve, and schedule the rest of the function as a .then callback, i.e. a microtask. Everything up to the first await runs synchronously.

So the output is 0, 1, 3, 2:

1. console.log(0) → 0.
2. f() runs synchronously up to the await: console.log(1) → 1. The await suspends and queues the continuation as a microtask.
3. Control returns to the caller: console.log(3) → 3.
4. Stack empties; the microtask runs: console.log(2) → 2.

The insight: await doesn't block the thread, it yields, and the code after it is a microtask.

All four take an iterable of promises and return one promise, but they resolve differently:

• `all`, fulfils with an array of all results, but rejects as soon as any one rejects (fail-fast). Use when you need every result and any failure means abort.
• `allSettled`, never rejects; fulfils with an array of {status, value|reason} once all settle. Use when you want every outcome regardless of individual failures (e.g. fire off N independent saves and report which failed).
• `race`, settles as soon as the first promise settles, fulfilled or rejected. Use for timeouts: race a request against a setTimeout reject.
• `any`, fulfils with the first fulfilment, ignoring rejections; only rejects (with an AggregateError) if they all reject. Use for redundancy: hit three mirrors, take the first that succeeds.

The core is a closure over a timer id: each call clears the pending timer and schedules a new one, so fn only fires once activity stops. Using a regular function plus fn.apply(this, args) preserves the caller's this (important when it's a method or event handler):

Note the returned function is a regular function, not an arrow, an arrow would capture this lexically and break method calls.

Debounce waits for a quiet period, it fires once after activity stops. Throttle guarantees at most one call per interval during continuous activity, it fires on a steady cadence. Use debounce for 'search as you type after they pause'; use throttle for scroll/resize/mousemove where you want regular updates but capped frequency.

A timestamp-based throttle:

A closure over a Map keyed by the arguments. A simple, honest version keys on a serialisation of the args:

Limitations to volunteer: JSON.stringify can't key on functions or non-serialisable args, is order-sensitive for object keys, and is slow for big inputs. The cache grows unbounded (a leak for long-lived functions), a real version needs an LRU bound. And it only helps pure functions; memoising something with side effects or time-varying results is a bug.

Prints 'A', then undefined, then undefined (assuming module scope where top-level this is undefined).

• obj.regular(), called as a method, so this is obj → 'A'.
• r(), the same function, but called bare. this is undefined in strict/module mode, so this?.name short-circuits to undefined. This is the classic 'lost this' when you detach a method.
• obj.arrow(), arrow functions ignore how they're called and capture this lexically from where they were defined (module scope, where this is undefined). Making a method an arrow is a common mistake.

To keep this when detaching, use obj.regular.bind(obj).

bind returns a new function that, when called, invokes the original with a fixed this and any pre-filled arguments prepended. The subtle part interviewers probe: when the bound function is used as a constructor (new), the bound this should be ignored in favour of the freshly-created instance.

Every object has an internal link ([[Prototype]], exposed as __proto__) to another object. When you read a property, the engine checks the object itself, then its prototype, then its prototype, walking the chain until it finds the property or hits null.

So obj.toString() isn't on your object, the engine walks up to Object.prototype, finds toString there, and calls it with this bound to obj. This is how methods are shared: instances made by a constructor all point their prototype at the same Constructor.prototype object, so one copy of each method serves every instance. ES6 class is syntax over exactly this mechanism.

A shallow copy duplicates the top level but shares nested references, { ...obj } and Object.assign({}, obj) copy the outer object, but a nested object inside is still the same object, so mutating copy.nested.x also changes the original.

A deep copy recursively duplicates everything, so the copy is fully independent. Options:

• `structuredClone(obj)`, the modern built-in. Handles nested objects, arrays, Dates, Maps, Sets, and cyclic references. Can't clone functions or DOM nodes.
• `JSON.parse(JSON.stringify(obj))`, quick but lossy: drops undefined, functions, and Symbols, turns Date into a string, and throws on cycles.
• A hand-written recursive clone when you need custom handling.

Default to structuredClone for plain data.

Curry returns a function that keeps collecting arguments until it has at least as many as the original function's arity (fn.length), then invokes it. If it doesn't have enough yet, it returns another collector that remembers what's been gathered so far, a closure over accumulated args:

A Map from event name to a set of listeners. on registers, off removes, emit calls each listener with the payload. Returning an unsubscribe function from on is a nice touch interviewers like:

A generator (function*) is a function you can pause and resume. Calling it returns an iterator; each next() runs until the next yield, hands back that value, and freezes execution, state is preserved between calls. That makes them ideal for lazy or infinite sequences (you never materialise the whole thing) and for modelling streams.

Historically they also underpinned async flow before async/await (which is essentially a generator that yields promises).

CommonJS (require/module.exports, Node's legacy system) is synchronous and dynamic, you can require conditionally at runtime, and exports are resolved as values when the call runs. ES Modules (import/export) are static: imports and exports are determined by the syntax before execution, and bindings are live (an imported value reflects later changes in the exporter).

That static structure is what enables tree-shaking: because a bundler can see exactly which exports are imported without running the code, it can drop unused ones. CommonJS's dynamic require can't be analysed as reliably, so dead-code elimination is weaker. ESM also supports async import() for code-splitting.