Question 1

How does memory allocation and garbage collection work at a high level in JavaScript?

Accepted Answer

JS allocates objects on the heap; GC reclaims values that are no longer reachable from roots (stack, globals, registered callbacks). Primitives may be handled specially, but objects/arrays/functions/closures live on the heap. Reachability from roots determines liveness — not whether you still 'think' you need the data. Engines use generational GC and techniques like mark-sweep/mark-compact and scavengers for young objects. Developers don't free memory manually, but they control reachability (nulling refs, removing listeners, closing over less). Understanding reachability is the practical skill.

Question 2

What are common memory leak patterns in browser JavaScript?

Accepted Answer

Detached DOM retained by JS refs, forgotten listeners/timers, unbounded caches, global accumulators, and closures holding large graphs. Classic leaks: store DOM nodes in arrays and remove from document without clearing refs; addEventListener without remove on teardown; setInterval forever; growing Maps/objects as caches without eviction; module-level arrays appending forever; console retaining objects in DevTools. SPAs leak across route changes when subscriptions aren't disposed. Fix with cleanup in unmount effects, WeakMap/WeakRef where appropriate, LRU caches, and heap snapshot comparisons.

Question 3

When would you use WeakMap, WeakSet, and WeakRef?

Accepted Answer

WeakMap/WeakSet allow GC of keys when no other refs exist — great for metadata; WeakRef/FinalizationRegistry are advanced and easy to misuse. WeakMap keys must be objects and are held weakly — ideal for private data or associating state with DOM elements without preventing GC. WeakSet similarly tracks object membership weakly. WeakRef gives a weak pointer to an object; FinalizationRegistry schedules cleanup callbacks after GC (not timely/guaranteed for critical logic). Avoid building caches solely on WeakRef without understanding non-determinism. Never use finalizers for resource disposal that must be prompt — use explicit dispose/AbortController.

Question 4

How do you diagnose a memory leak using browser DevTools?

Accepted Answer

Take heap snapshots over time, compare retained sizes, find retainer paths, and use allocation timelines while reproducing the leak scenario. Steps: force GC if available, snapshot baseline, reproduce navigation/actions N times, snapshot again, look for growing object counts (Detached HTMLDivElement, listeners, arrays). Inspect retainer path to see what keeps them alive (closure, module cache). Allocation instrumentation sampling helps find churn. In React, check for abandoned fibers/stores. Confirm fix with another comparison. Also monitor performance memory charts for upward trends that don't return to baseline after GC.

Question 5

How would you set and enforce a client-side memory budget for a complex SPA?

Accepted Answer

Define per-route/device budgets, measure in RUM/lab, enforce cache limits, dispose on navigation, and gate PRs that add heavy retained structures. Establish budgets (e.g. JS heap after critical flows on mid-tier mobiles). Instrument: performance.memory where available, custom metrics for cache sizes, detached node counts in tests. Architecture: virtualize long lists, paginate, evict LRU caches, prefer WeakMap for element metadata, kill workers when idle, avoid retaining entire API responses. Process: memory regression tests in CI for key journeys; review large static data imports; educate on closures/listeners. Trade-offs: aggressive eviction increases network cost — balance with offline needs. Lead responsibility includes choosing which features degrade first under pressure.

Memory Management JavaScript Interview Questions

Other JavaScript interview topics