JavaScript Scope, Closures and Context Questions

Comprehensive mastery of JavaScript scoping rules, closure mechanics, and execution context including the this binding. Candidates should understand lexical scope and the scope chain, differences between function scope and block scope, and the behaviors and hoisting implications of var, let, and const. Know how closures capture and retain variables from outer scopes, how closures enable function factories and data privacy, and common closure patterns such as module patterns, factory functions, immediately invoked function expressions, currying, and decorators. Be able to apply closures safely in asynchronous code including timers, callbacks, and promises, and reason about pitfalls such as closures in loops, accidental retention of large objects, memory and garbage collection consequences, hoisting related bugs, and performance tradeoffs. Understand execution context and the this binding, including how call site determines this in global calls, method calls, constructor calls, and event handlers, how arrow functions use lexical this, and how to use call, apply, and bind to control context. Interview tasks typically include reading and explaining existing closures, identifying and fixing closure related bugs, implementing small patterns or utilities that rely on closures and context, and discussing debugging and optimization strategies. This also covers framework relevant patterns such as custom hooks in component based frameworks where closures and context interact with lifecycle and state.

HardTechnical

28 practiced

Implement a simple EventEmitter class in JavaScript with on(event, listener, ctx), once(event, listener, ctx), off(event, listener, ctx) and emit(event, ...args). Requirements:1) Call listeners with ctx as this when provided, otherwise with the emitter as this.2) Allow removing listeners added with a ctx.3) Ensure once listeners are removed after first successful emit.Provide code and explain how closures store listener metadata and enable off to remove exactly the right handler.

Sample Answer

**Approach (brief)** I'll implement an EventEmitter that keeps an internal map of event -> array of handler objects. Each handler stores the original listener, a wrapper function (for once), and the ctx. Closures capture metadata so off can match and remove the correct wrapper.

javascript

class EventEmitter {
  constructor() {
    this._events = new Map(); // event -> [ { listener, wrapper, ctx } ]
  }

  on(event, listener, ctx = this) {
    const record = { listener, wrapper: listener, ctx };
    if (!this._events.has(event)) this._events.set(event, []);
    this._events.get(event).push(record);
    return this;
  }

  once(event, listener, ctx = this) {
    // wrapper closes over record so we can remove exactly this handler after first call
    let record;
    const wrapper = (...args) => {
      try {
        listener.apply(ctx === undefined ? this : ctx, args);
      } finally {
        // remove this specific record
        this.off(event, listener, ctx);
      }
    };
    record = { listener, wrapper, ctx };
    if (!this._events.has(event)) this._events.set(event, []);
    this._events.get(event).push(record);
    return this;
  }

  off(event, listener, ctx = this) {
    const list = this._events.get(event);
    if (!list) return this;
    // remove records matching both listener and ctx
    for (let i = list.length - 1; i >= 0; i--) {
      const r = list[i];
      if (r.listener === listener && r.ctx === ctx) list.splice(i, 1);
    }
    if (list.length === 0) this._events.delete(event);
    return this;
  }

  emit(event, ...args) {
    const list = this._events.get(event);
    if (!list || list.length === 0) return false;
    // iterate over a shallow copy to allow modifications during emit
    for (const { wrapper, ctx } of [...list]) {
      wrapper.apply(ctx === undefined ? this : ctx, args);
    }
    return true;
  }
}

**Key concepts / why closures matter** - Each record stores both the original listener and the wrapper used for once semantics. The wrapper closes over the listener and ctx so it can call the listener with the correct this and then trigger removal. - off compares the original listener and ctx against stored record.listener and record.ctx. Because the wrapper and original listener are both stored in the same record (via closure when created), off can reliably remove the exact handler even for once-wrapped listeners. - Using a shallow copy when emitting lets handlers call off/on safely during iteration.

**Complexity & notes** - Emitting iterates current listeners O(n). Adding/removing is O(n) per event due to array splice. This is fine for typical frontend use. - I default ctx to the emitter (this) to satisfy requirement (1).

EasyTechnical

28 practiced

What is a closure in JavaScript and when is it created? Provide a minimal JavaScript example where an inner function preserves private state across multiple invocations. Explain why the outer variable remains alive even after the outer function has returned.

Sample Answer

**Definition & when it's created**

A closure is the combination of a function and the lexical environment in which it was declared. In JavaScript a closure is created whenever an inner function references variables from an outer function — and that inner function can be called after the outer function has returned.

**Minimal example (private state preserved)**

javascript

// returns a counter function that preserves `count`
function createCounter() {
  let count = 0; // private state
  return function() {
    count += 1;
    return count;
  };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2

**Why the outer variable remains alive**

The returned inner function retains a reference to the outer function’s lexical environment (its scope chain). Because the inner function can still access `count`, the JavaScript engine keeps that environment alive on the heap instead of garbage-collecting it. This enables data privacy and persistent state across invocations — a common pattern for encapsulation in frontend code (e.g., component internals, event handlers).

MediumTechnical

28 practiced

Explain why arrow functions cannot be used as constructors in JavaScript and describe what happens to their prototype property. Provide a short code sample that attempts new on an arrow function and explain the resulting error. Then show the correct way to create a simple constructor-like function or class.

Sample Answer

**Why arrow functions can't be constructors**

- Arrow functions lack the internal [[Construct]] method and therefore cannot be used with new.- They also do not have a meaningful prototype property (engines don't create a prototype object for arrow functions), so you can't attach instance methods via prototype.

**Example: attempting new on an arrow function**

javascript

const Person = (name) => {
  this.name = name;
};

const p = new Person('Alice'); // TypeError

This throws: "TypeError: Person is not a constructor" (or "Person is not a constructor" / "Person is not constructable"), because the engine refuses to treat the arrow function as constructible.

**What happens to prototype**- Arrow functions do not have the usual Function.prototype-backed "prototype" object created for constructor functions. Accessing Person.prototype typically yields undefined.

**Correct ways to create a constructor-like object**

1) Function constructor:

javascript

function PersonFunc(name) {
  this.name = name;
}
PersonFunc.prototype.greet = function() { return `Hi, ${this.name}`; };
const a = new PersonFunc('Alice');

2) ES6 class (recommended for frontend code):

javascript

class Person {
  constructor(name) { this.name = name; }
  greet() { return `Hi, ${this.name}`; }
}
const b = new Person('Bob');

Use arrow functions for short callbacks and lexical this, not for constructors.

HardTechnical

22 practiced

Explain what happens when Function.prototype.bind is used on a constructor and then the bound function is invoked with new. Provide a concrete example demonstrating which prototype is used for the newly constructed object, and explain the ECMAScript behavior. Finally, show a practical workaround to create a bound-like constructor that preserves prototype behavior for instances.

Sample Answer

**Answer (Frontend dev perspective)**

Short answer: When you bind a constructor, calling the bound function with new still constructs using the original target constructor and the created object's [[Prototype]] comes from the original target.prototype (not the bound function’s prototype). ECMAScript makes bound functions forward construction to the target; the bound thisArg is ignored for new calls.

Example showing prototype used:

javascript

function Person(name) { this.name = name; }
Person.prototype.greet = function(){ return 'hi ' + this.name; };

const Bound = Person.bind({}); // bind a thisArg (ignored when used with new)
const p = new Bound('Alice');

console.log(p instanceof Person); // true
console.log(Object.getPrototypeOf(p) === Person.prototype); // true
console.log(typeof Bound.prototype); // "object" but not used for instances

ECMAScript behavior (why): A bound function has internal slots linking to the target function and bound args. Its [[Construct]] operation delegates to the target's constructor, so the created object's internal prototype is set from target.prototype. The bound thisArg is only used for normal calls, not for construct calls.

Practical workaround: create a "bound-like" constructor that preserves prototype semantics and supports both new and normal calls using Reflect.construct and new.target:

javascript

function bindConstructor(Target, ...boundArgs){
  function Boundish(...args){
    if (new.target) {
      // preserve correct prototype chain and instanceof behavior
      return Reflect.construct(Target, [...boundArgs, ...args], new.target);
    }
    return Target.apply(this, [...boundArgs, ...args]);
  }
  // optionally copy static properties
  Object.setPrototypeOf(Boundish, Target);
  return Boundish;
}

// Usage
const PersonWithDefault = bindConstructor(Person, 'DefaultName');
const p2 = new PersonWithDefault();
console.log(p2 instanceof Person); // true
console.log(p2.greet()); // "hi DefaultName"

Notes:- Use Reflect.construct(Target, args, newTarget) so instanceof and prototype are correct.- Copying static members (Object.assign) may be necessary for parity.- This pattern is useful in frontend code when you need partially-applied constructors (e.g., preconfigured components) without breaking prototype chains.

MediumTechnical

26 practiced

You observe steadily increasing memory usage in a single-page app. One suspect is a module that registers event listeners and stores large DOM nodes or data structures inside a closure that lives for the app lifetime. Describe how you would inspect and confirm this leak using browser devtools, show an example of problematic code, and explain two concrete fixes that would allow GC to reclaim the memory.

Sample Answer

**Inspecting & confirming the leak (DevTools steps)**

- Open Chrome DevTools → Performance and Memory.- In Memory: take a "Heap snapshot" → interact with the app (navigate, open/close components) → take another snapshot.- Compare snapshots: look for retained objects, Detached DOM tree, or growing Closures/Objects. Use "Containment" and "Retainers" to find what keeps a large DOM node alive.- In Performance: record allocation timeline while repeating the interaction; watch for increasing Detached DOM nodes and uncollected memory.- Use Event Listener breakpoints (Sources → Event Listener Breakpoints) to find where listeners are registered.

**Problematic example**

javascript

// module.js
const bigNode = document.querySelector('#chart'); // large DOM subtree
const cachedData = new Map(); // large dataset

(function register() {
  window.addEventListener('resize', () => {
    // closure captures bigNode and cachedData
    renderChart(bigNode, cachedData);
  });
})();

This keeps bigNode and cachedData reachable for app lifetime via the anonymous listener closure.

**Two concrete fixes**

1) Unregister the listener when no longer needed- Store the handler so you can remove it.

javascript

function onResize() { renderChart(bigNode, cachedData); }
window.addEventListener('resize', onResize);
// when component unmounts:
window.removeEventListener('resize', onResize);

Reason: removing the listener drops the closure retainers so GC can reclaim bigNode and cachedData.

2) Avoid capturing large DOM/data; use weak refs or query on demand- Don't store large nodes in module scope; query when needed or store IDs.

javascript

function onResize() {
  const node = document.getElementById('chart'); // temporary ref
  const data = fetchCachedData(); // returns lightweight copy or lazily loads
  renderChart(node, data);
}
window.addEventListener('resize', onResize);
// no long-lived closure to big objects

- For caches, consider WeakMap for element-keyed metadata so GC can collect entries when elements are gone.

**Why these work**Removing listeners or avoiding strong references breaks the retention path shown in heap snapshots; with no retainers, the GC can reclaim memory. After applying fixes, re-run heap snapshots to confirm the retained size no longer grows.

Unlock Full Question Bank

Get access to hundreds of JavaScript Scope, Closures and Context interview questions and detailed answers.

Join thousands of developers preparing for their dream job.