yoklainterview sim
ProgressHistory

Frontend Javascript Memory Performance Interview Questions

75 verified Frontend Javascript Memory Performance interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Javascript Memory PerformanceDifficulty 1
What is a 'memory leak' in JavaScript most precisely?
  • aAny time the garbage collector happens to run
  • bMemory the program no longer needs, but is still reachable and never reclaimed✓
  • cA syntax error that immediately crashes the JS engine
  • dMemory allocated on the call stack instead of the heap
Explanation:A leak isn't about the GC running — it's about objects staying reachable (via some forgotten reference) long after the program has no real use for them, so the GC has no way to know it can free them.
Javascript Memory PerformanceDifficulty 2
Which of these best describes 'mark-and-sweep', the garbage collection strategy used by modern JS engines?
  • aEvery object keeps a reference count that frees it at zero
  • bMemory is defragmented by moving objects to the start of the heap
  • cThe engine marks everything reachable from root references, then sweeps what's unmarked✓
  • dObjects that have simply existed longer than some fixed number of milliseconds get freed automatically by a background timer
Explanation:Mark-and-sweep starts from GC roots, marks everything reachable by walking references, then frees whatever wasn't marked. This is why unreachable cycles are collected fine, unlike naive reference counting.
Javascript Memory PerformanceDifficulty 2
function makeCycle() {
  let a = {};
  let b = {};
  a.other = b;
  b.other = a;
  return "done";
}
makeCycle();

After makeCycle() returns, are a, b, and the objects they point to eligible for garbage collection?
  • aYes — nothing outside the function references them, so the unreachable cycle is collected✓
  • bNo — because a and b hold mutual references to each other, the engine can never determine that they're actually unreachable
  • cOnly a is collected; b survives because it was assigned second
  • dOnly if delete a.other is called first
Explanation:Reference counting would get stuck on this cycle (count never hits zero), but mark-and-sweep doesn't care — once makeCycle returns, nothing reachable from the roots points to a or b, so both are collected together.
Javascript Memory PerformanceDifficulty 2
A single-page app starts a setInterval inside a component's 'mount' logic to poll for updates, but never calls clearInterval when the user navigates away. What is the most likely consequence?
  • aNothing — setInterval callbacks are GC'd once the DOM node is removed
  • bThe browser tab crashes right away
  • cThe interval stops itself once its DOM node becomes unreachable
  • dIt keeps running — its closure stays alive for the page's lifetime, and repeated navigations pile this up✓
Explanation:A running timer is itself a root-reachable reference held by the runtime, so its callback closure can't be collected until clearInterval is called. DOM removal alone doesn't stop it.
Javascript Memory PerformanceDifficulty 2
const detached = [];
function cacheRow(row) {
  detached.push(row);
  row.remove();
}

If cacheRow is called repeatedly with <tr> elements, what happens over time?
  • aRemoved rows are collected as soon as .remove() runs, array or not
  • bEach row stays in memory because detached still references it — a detached DOM tree leak✓
  • cThe browser auto-clears detached once a row leaves the document
  • drow.remove() throws because the element is referenced elsewhere
Explanation:.remove() only detaches an element from the visible document tree; it doesn't affect JS reachability. As long as detached holds a reference, the (now invisible) DOM subtree is retained.
Javascript Memory PerformanceDifficulty 3
A widget's constructor creates a brand-new closure function each time and attaches it to window as a resize listener, but never removes it when the widget is destroyed. The app creates and destroys this widget 50 times during a session. What's the effect?
  • a50 closures pile up on window, each keeping its own widget instance alive✓
  • bOnly the newest listener survives; duplicates get replaced automatically
  • caddEventListener deduplicates identical function references automatically
  • dNo memory impact, since resize fires only occasionally
Explanation:Each call to addEventListener with a distinct closure adds a new listener; window (a root-reachable object) then holds a live reference to every one of them, keeping every widget instance's closure — and whatever it captured — alive.

By specialization

Angular 450JavaScript 450React 450TypeScript 450Vue 450

By seniority

Frontend JuniorFrontend MidFrontend Senior

Other fields

BackendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2925-question Frontend bank.

Start interview