Question 1

What is a closure in JavaScript?

Accepted Answer

A closure is a function bundled with its lexical environment, so it can access outer-scope variables even after the outer function has returned. When a function is created, it retains a reference to the lexical environment where it was defined. If it references outer variables, those bindings stay reachable as long as the function (or anything holding it) lives — that pairing is a closure. Closures enable data privacy (factory functions), partial application, callbacks that remember state, and module patterns. They are not a special syntax; they are a consequence of lexical scoping.

Question 2

How can closures create private state, and when is that useful?

Accepted Answer

Hide variables in an outer function and expose only methods that close over them — encapsulation without classes. Variables in the outer function are not accessible from outside unless returned or attached to an exported API. Returned methods share that environment, so they can read/write private state while callers cannot reach the raw bindings. This pattern underpins revealing module patterns, store factories, and many library APIs. Compared with #private class fields, closure privacy works on plain functions and does not appear on the instance as enumerable properties. Trade-off: each factory call creates new function objects, which can matter at huge scale.

Question 3

Why does this print 3 3 3 instead of 0 1 2, and how do you fix it?

Accepted Answer

All callbacks close over the same function-scoped var i, which is 3 when they run. Use let, a factory, or bind to capture per-iteration values. var i is one binding for the loop. Each arrow closes over that binding. After the loop, i === 3, and the timers fire later, so all log 3. With let i, each iteration gets a new binding (per ES2015 per-iteration semantics), so callbacks see 0, 1, 2. Alternatives: IIFE/function(i){...}(i) to copy the value, or setTimeout(console.log, 0, i). This is one of the most common closure interview traps.

Question 4

How can closures cause memory retention problems?

Accepted Answer

A long-lived function keeps its closed-over environment alive, so large objects referenced there cannot be garbage-collected. If a callback, event listener, or exported function closes over a large object (DOM nodes, caches, buffers), that object stays reachable. Detached DOM trees retained via closures are a classic leak pattern. Fixes: null out references when done, remove listeners, close over only needed primitives/ids, use WeakMap for associated data, and avoid capturing entire component instances when a small subset suffices. DevTools heap snapshots showing retainer paths through context objects help confirm the issue.

Question 5

Implement a simple partial or multiplyBy using closures. What interview signal does this show?

Accepted Answer

Return an inner function that remembers preset arguments from the outer scope — demonstrates closures and functional patterns. Partial application fixes some arguments and returns a function awaiting the rest. Closures store the preset args without needing a class. This differs slightly from currying (unary chain), but both rely on closures. In interviews, a clean implementation shows you can design APIs that configure behavior once and reuse it. Discuss trade-offs: readability vs. bind, and when explicit objects are clearer than nested closures.

Question 6

What is a stale closure, and how would you diagnose it in an async UI callback?

Accepted Answer

A callback closes over an old snapshot of state; later renders/updates change state, but the callback still sees the captured values. Classic example: an event handler or setInterval created in a render/effect closes over count from that moment. If count updates, the timer still logs the old value unless it reads from a ref, re-subscribes when deps change, or uses functional updates. Diagnosis: log values inside the callback vs current store/ref; check effect dependency arrays; inspect whether the listener was recreated. Fixes depend on framework — refs, store subscriptions, or keying effects correctly. The underlying JS issue is immutable capture of binding values at creation time for const/let (the binding is live, but React state identity is a new value each render and the old closure kept the old one).

Question 7

When designing a library API, when would you prefer closure-based factories over class instances with prototype methods?

Accepted Answer

Prefer closures for true privacy and simple captured config; prefer classes/prototypes for shared methods, instanceof, subclassing, and lower per-instance function cost. Closure factories excel when: you want hard privacy, a small surface area, and configuration captured once (createClient(options)). They compose well with functional style. Classes/prototypes excel when: you need shared methods on a prototype (memory), inheritance, instanceof, decorators, or framework integration that expects constructables. Mixed approach is common: class with private fields (#) for privacy plus shared methods. At lead level, decide based on allocation profiles, testability, serialization (toJSON), and whether consumers need to extend types. Document lifecycle: closures that register listeners must expose dispose.

Closures JavaScript Interview Questions

Other JavaScript interview topics