Introduction to Modern JavaScript (ES2026)

Welcome to the foundational chapter of your JavaScript interview preparation! This section is designed to equip you with a deep understanding of JavaScript’s core mechanisms, particularly its often “weird” or unintuitive behaviors. While modern JavaScript (as of ES2026) offers many syntactic sugars and powerful features, a true mastery of the language, especially for architect-level roles, hinges on understanding how these underlying principles—like coercion, hoisting, scope, closures, prototypes, this binding, and the event loop—dictate code execution.

This chapter covers a spectrum of questions, from fundamental concepts suitable for entry and mid-level developers to intricate puzzles and real-world bug scenarios tailored for senior and architect candidates. We’ll delve into the “why” behind JavaScript’s unique behaviors, moving beyond surface-level answers to uncover the specification-driven logic. By mastering these concepts, you’ll not only ace your interviews but also write more robust, maintainable, and efficient JavaScript code.

The content herein reflects the latest ECMAScript standards and best practices as of January 2026. We will emphasize modern syntax (let, const, async/await, modules) while critically examining older constructs (var, function scope) to highlight their historical context and potential pitfalls. Prepare to challenge your assumptions and solidify your grasp on JavaScript’s powerful yet peculiar nature.

Core Interview Questions

1. Hoisting & Temporal Dead Zone

Q: Explain JavaScript hoisting for var, let, const, and function declarations. Provide a code example that demonstrates the “Temporal Dead Zone” (TDZ).

A: Hoisting is a JavaScript mechanism where variable and function declarations are moved to the top of their containing scope during the compilation phase, before code execution.

var declarations: Are hoisted to the top of their function or global scope and initialized with undefined. Accessing a var before its declaration will result in undefined.
```
console.log(myVar); // Output: undefined
var myVar = 10;
console.log(myVar); // Output: 10
```
let and const declarations: Are also hoisted to the top of their block scope but are not initialized. They remain in a “Temporal Dead Zone” (TDZ) from the start of the block until their declaration is encountered during execution. Attempting to access let or const variables within the TDZ will result in a ReferenceError.
```
console.log(myLet); // ReferenceError: Cannot access 'myLet' before initialization
let myLet = 20;
```
Function declarations: Are fully hoisted, meaning both the function name and its definition are moved to the top of their scope. You can call a function declaration before it appears in the code.
```
myFunction(); // Output: "Hello from hoisted function!"
function myFunction() {
  console.log("Hello from hoisted function!");
}
```
Function expressions (including arrow functions): Are not fully hoisted. If defined with var, only the var is hoisted (initialized to undefined). If defined with let or const, they are subject to the TDZ.

Key Points:

Hoisting moves declarations, not initializations.
var has function/global scope; let/const have block scope.
TDZ applies to let and const and prevents access before declaration.
Function declarations are fully hoisted; function expressions are not.

Common Mistakes:

Believing let/const are not hoisted at all. They are, but the TDZ prevents early access.
Confusing undefined for ReferenceError when dealing with var vs let/const.
Using var in modern JavaScript, leading to unexpected hoisting behaviors and scope issues.

Follow-up Questions:

How does hoisting interact with nested scopes?
What happens if you declare a let variable twice in the same scope?
Can you describe a scenario where understanding hoisting is critical for debugging?

2. Type Coercion & Strict Equality

Q: JavaScript is known for its “loose” typing. Explain type coercion and the difference between == (abstract equality) and === (strict equality). Provide examples of unexpected coercion results.

A: Type coercion is JavaScript’s automatic conversion of values from one data type to another. This often happens implicitly when using operators like ==, +, or logical operators, or explicitly using functions like Number(), String(), Boolean().

== (Abstract Equality Operator): Performs type coercion if the operands are of different types, attempting to convert one or both operands to a common type before comparison. This can lead to unexpected results.
=== (Strict Equality Operator): Compares values without performing any type coercion. If the operands are of different types, it immediately returns false. It checks both value and type.

Examples of Coercion Results:

// Using == (Abstract Equality)
console.log(1 == '1');     // true (string '1' is coerced to number 1)
console.log(0 == false);   // true (false is coerced to 0)
console.log(null == undefined); // true (special case, no coercion to specific type, but considered equal)
console.log('' == false);  // true (empty string coerced to 0, false coerced to 0)
console.log([] == 0);      // true (empty array coerced to '', then to 0)
console.log({} == '[object Object]'); // false ({} coerced to '[object Object]', but comparison fails)

// Using === (Strict Equality)
console.log(1 === '1');    // false (different types: number vs string)
console.log(0 === false);  // false (different types: number vs boolean)
console.log(null === undefined); // false (different types: null vs undefined)
console.log('' === false); // false (different types: string vs boolean)

Key Points:

== involves implicit type conversion; === does not.
Always prefer === to avoid unexpected behavior and improve code predictability.
Be aware of null == undefined being true, but null === undefined being false.
Falsy values (false, 0, ‘’, null, undefined, NaN) behave uniquely in coercion.

Common Mistakes:

Relying on == for comparisons, especially in security-sensitive contexts.
Not understanding how + operator behaves with strings (concatenation vs. addition).
Forgetting that NaN is not strictly equal to itself (NaN === NaN is false).

Follow-up Questions:

How does the + operator handle different types (e.g., 1 + '2')?
Explain “truthy” and “falsy” values in JavaScript.
When might implicit coercion be considered useful or acceptable?

3. Scope & Lexical Environment

Q: Describe the different types of scope in JavaScript (global, function, block) and explain what a “Lexical Environment” is. How does lexical scoping influence variable access?

A: Scope in JavaScript dictates the accessibility of variables, functions, and objects in different parts of your code.

Global Scope: Variables declared outside any function or block are in the global scope. They are accessible from anywhere in the code. In browsers, var declarations in global scope attach to the window object.
Function Scope: Variables declared with var inside a function are function-scoped. They are only accessible within that function and its nested functions, but not outside.
Block Scope (ES6+): Variables declared with let and const inside a block (e.g., if statements, for loops, {}) are block-scoped. They are only accessible within that specific block.

A Lexical Environment is a specification-internal concept used to define the association of identifiers (variables, functions) with their values based on the physical structure of the code. Every function call, block, or script creates a new Lexical Environment. Each Lexical Environment consists of:

An Environment Record: Stores variable and function declarations within that scope.
A Reference to the outer Lexical Environment: This link forms a chain, known as the scope chain.

Lexical Scoping (also known as static scoping) means that the scope of a variable is determined at the time of code definition (where it’s written), not at the time of code execution. When a function or block tries to access a variable, it first looks in its own Lexical Environment. If not found, it traverses up the scope chain through its outer Lexical Environment references until it finds the variable or reaches the global scope.

Example:

let globalVar = 'I am global';

function outer() {
  let outerVar = 'I am outer';

  function inner() {
    let innerVar = 'I am inner';
    console.log(innerVar);  // Accesses innerVar (local)
    console.log(outerVar);  // Accesses outerVar (from outer scope)
    console.log(globalVar); // Accesses globalVar (from global scope)
    // console.log(nonExistent); // ReferenceError: nonExistent is not defined
  }
  inner();
  // console.log(innerVar); // ReferenceError: innerVar is not defined
}
outer();

Key Points:

Scope determines variable visibility.
var has function scope, let/const have block scope (modern JS standard).
Lexical Environment is a runtime concept defining variable-value mappings and linking to outer scopes.
Lexical scoping means scope is determined by where code is written, creating a static scope chain.

Common Mistakes:

Confusing dynamic scoping with lexical scoping (JavaScript is lexically scoped).
Misunderstanding that var inside a block (e.g., for loop) is not block-scoped.
Not being able to trace variable resolution through nested scopes.

Follow-up Questions:

How do modules (import/export) affect global scope?
Can you explain the difference between eval scope and regular lexical scope?
How can you simulate block scope before ES6?

4. Closures & Memory Management

Q: What is a JavaScript closure? Provide a practical example and discuss potential memory implications, particularly in long-running applications.

A: A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In simpler terms, a closure gives you access to an outer function’s scope from an inner function, even after the outer function has finished executing.

This happens because when an inner function is defined, it “remembers” its lexical environment, including any variables from its parent scope.

Practical Example (Counter):

function createCounter() {
  let count = 0; // 'count' is in the lexical environment of createCounter

  return function() { // This inner function is a closure
    count++;
    return count;
  };
}

const counter1 = createCounter();
console.log(counter1()); // Output: 1
console.log(counter1()); // Output: 2

const counter2 = createCounter(); // Creates a new independent closure
console.log(counter2()); // Output: 1 (starts fresh)

In this example, counter1 and counter2 are closures. They both “remember” their own count variable from their respective createCounter calls, even though createCounter has already returned.

Memory Implications: While closures are powerful, they can lead to memory leaks if not managed carefully, especially in long-running applications or single-page applications (SPAs).

Retained References: If a closure retains a reference to a large object or an entire outer scope, that memory cannot be garbage collected as long as the closure itself is accessible.
Event Handlers: A common scenario is attaching event listeners within a function that creates a closure. If the DOM element to which the listener is attached is removed from the DOM, but the closure (event handler) is still referenced elsewhere, the element and its associated data might not be garbage collected.
Global References: If a closure is unintentionally assigned to a global variable or remains in a global array, it will never be garbage collected, potentially holding onto large amounts of memory.

Mitigation:

Explicitly nullifying references: When a closure or the data it references is no longer needed, set its references to null.
Using WeakMap or WeakSet: For associating data with objects that can be garbage collected if no other strong references exist.
Careful event listener management: Remove event listeners when components unmount or become irrelevant.
Modular design: Encapsulate and limit the scope of closures to prevent unintended retention of large objects.

Key Points:

Closures allow inner functions to access outer function scope even after the outer function finishes.
They are fundamental for data privacy, currying, and maintaining state.
Potential for memory leaks if closures hold onto unnecessary references, especially in long-lived contexts.

Common Mistakes:

Misunderstanding that a new closure is created with each call to the outer function.
Not recognizing memory leak scenarios involving closures in event handlers or timers.
Assuming variables in the outer scope are copied, rather than referenced.

Follow-up Questions:

How do var vs let in a loop affect closures?
Can you explain how closures enable data encapsulation?
When would you use a WeakMap in relation to closures?

5. `this` Binding & Arrow Functions (ES2015+)

Q: Explain the different rules for this binding in JavaScript, including explicit, implicit, new, and global binding. How do arrow functions (ES2015+) change the this behavior, and why is this significant?

A: The this keyword in JavaScript is a source of frequent confusion because its value is determined dynamically based on how a function is called, not where it’s defined.

There are primarily five ways this can be bound:

Default/Global Binding: If none of the other rules apply, this defaults to the global object (window in browsers, global in Node.js) in non-strict mode. In strict mode, this is undefined.
```
function showThis() { console.log(this); }
showThis(); // In browser non-strict: window; In strict: undefined
```

Implicit Binding: When a function is called as a method of an object, this refers to the object itself.

const obj = {
  name: 'Alice',
  greet: function() { console.log(`Hello, ${this.name}`); }
};
obj.greet(); // Output: Hello, Alice (this is obj)

Explicit Binding: You can explicitly set the this context using call(), apply(), or bind().
- call(thisArg, arg1, arg2, ...): Immediately invokes the function with thisArg as this and arguments passed individually.
- apply(thisArg, [argsArray]): Immediately invokes the function with thisArg as this and arguments passed as an array.
- bind(thisArg, arg1, arg2, ...): Returns a new function with thisArg permanently bound as this, and optional arguments pre-filled. It does not invoke immediately.
```
function sayName() { console.log(this.name); }
const person = { name: 'Bob' };
sayName.call(person);  // Output: Bob
const boundSayName = sayName.bind(person);
boundSayName();        // Output: Bob
```
new Binding: When a function is called with the new keyword (as a constructor), a new object is created, and this inside the constructor refers to this newly created object.
```
function Person(name) {
  this.name = name;
}
const p = new Person('Charlie');
console.log(p.name); // Output: Charlie (this was the new object p)
```
Arrow Function Binding (ES2015+): Arrow functions do not have their own this binding. Instead, they lexically inherit this from their enclosing (parent) scope at the time they are defined. This behavior is not affected by how the arrow function is called.

Significance of Arrow Functions: Arrow functions resolve the common this confusion, especially in callbacks and event handlers where this often unexpectedly defaults to the global object or undefined. Before arrow functions, developers had to use const self = this; or bind() to ensure this referred to the intended context. Arrow functions simplify this by automatically preserving the this of their surrounding lexical context.

Example with Arrow Function:

const user = {
  name: 'David',
  logName: function() { // Traditional function, 'this' depends on call site
    setTimeout(function() {
      console.log(`Regular func: ${this.name}`); // 'this' is window/undefined
    }, 100);
  },
  logNameArrow: function() { // Traditional function wrapping arrow
    setTimeout(() => {
      console.log(`Arrow func: ${this.name}`); // 'this' is user (lexically inherited)
    }, 100);
  }
};

user.logName();       // Output: Regular func: undefined (or empty string in non-strict browser)
user.logNameArrow();  // Output: Arrow func: David

Key Points:

this is dynamically determined by the call site (except for arrow functions).
Four main binding rules: default, implicit, explicit (call/apply/bind), new.
Arrow functions have lexical this binding; they inherit this from their enclosing scope.
Arrow functions are crucial for writing cleaner asynchronous code and event handlers.

Common Mistakes:

Assuming this in a callback function will always refer to the object it was defined within.
Not understanding the difference between call, apply, and bind.
Using this in an arrow function defined in the global scope, which then refers to the global this.

Follow-up Questions:

When would you not want to use an arrow function for this binding?
How does this behave inside a class constructor and methods?
What is the precedence if multiple this binding rules could apply?

6. Prototype Chain & ES6 Classes

Q: Explain JavaScript’s prototype chain and how it enables inheritance. How do ES6 class syntax (ES2015+) and extends keyword relate to the prototype chain?

A: JavaScript is a prototype-based language, meaning it uses prototypes for inheritance rather than traditional class-based inheritance. Every object in JavaScript has an internal property called [[Prototype]] (exposed via __proto__ or Object.getPrototypeOf()) which is either null or references another object, its “prototype.”

The prototype chain is a series of linked objects. When you try to access a property or method on an object, and that property isn’t found directly on the object itself, JavaScript looks for it on the object’s prototype. If still not found, it looks on the prototype’s prototype, and so on, until it finds the property or reaches the end of the chain (null). This mechanism allows objects to inherit properties and methods from other objects.

Example (Pre-ES6):

const animal = {
  eats: true,
  walk() {
    console.log("Animal walks.");
  }
};

const rabbit = {
  jumps: true,
  __proto__: animal // rabbit inherits from animal
};

rabbit.walk(); // Output: Animal walks. (walk is found on animal)
console.log(rabbit.eats); // Output: true

ES6 Classes & extends: ES6 introduced class syntax as syntactic sugar over JavaScript’s existing prototype-based inheritance. It does not introduce a new inheritance model but provides a cleaner, more familiar object-oriented syntax for creating constructor functions and managing prototypes.

class keyword: Defines a constructor function and its associated prototype methods.
extends keyword: Used to set up the prototype chain between classes. When class Child extends Parent is used:
1. Child.prototype inherits from Parent.prototype.
2. The Child class itself (the constructor function) inherits from the Parent class (constructor function). This is crucial for static methods and ensures super() works correctly in the constructor.

Example (ES6 Classes):

class Animal {
  constructor(name) {
    this.name = name;
  }
  eats() {
    console.log(`${this.name} eats food.`);
  }
}

class Rabbit extends Animal {
  constructor(name, type) {
    super(name); // Calls the parent Animal's constructor
    this.type = type;
  }
  jumps() {
    console.log(`${this.name} (${this.type}) jumps.`);
  }
}

const bunny = new Rabbit('Bugs', 'Cartoon');
bunny.eats();   // Output: Bugs eats food. (inherited from Animal.prototype)
bunny.jumps();  // Output: Bugs (Cartoon) jumps. (defined on Rabbit.prototype)
console.log(Object.getPrototypeOf(Rabbit.prototype) === Animal.prototype); // true
console.log(Object.getPrototypeOf(Rabbit) === Animal); // true

Key Points:

JavaScript uses prototype-based inheritance via the [[Prototype]] link.
The prototype chain is traversed to find properties/methods not found directly on an object.
ES6 class syntax is syntactic sugar for constructor functions and prototype inheritance.
extends sets up the prototype chain between class prototypes and between class constructors themselves.

Common Mistakes:

Thinking class introduces classical inheritance. It’s still prototype-based.
Forgetting to call super() in a subclass constructor when extends is used.
Confusing prototype (a property on constructor functions) with [[Prototype]] (the internal link between objects).

Follow-up Questions:

What is Object.create() used for in relation to prototypes?
How can you detect if an object is an instance of a particular class or constructor function?
Explain the difference between Object.prototype and Function.prototype.

7. Event Loop & Asynchronous JavaScript

Q: Explain the JavaScript Event Loop, its components (Call Stack, Web APIs, Callback Queue, Microtask Queue), and how it enables asynchronous operations like setTimeout, Promises, and async/await. Demonstrate the execution order with a code example.

A: JavaScript is single-threaded, meaning it can only execute one task at a time. However, it handles asynchronous operations (like network requests, timers, user events) without blocking the main thread using the Event Loop.

Components:

Call Stack: A LIFO (Last In, First Out) stack that keeps track of the currently executing functions. When a function is called, it’s pushed onto the stack; when it returns, it’s popped off.
Web APIs (or Node.js APIs): Browser/runtime-provided functionalities (e.g., setTimeout, fetch, DOM events, Promise resolution) that JavaScript doesn’t handle directly. When these are called, they are passed to the Web APIs to be handled in the background.
Callback Queue (Task Queue/Macrotask Queue): A FIFO (First In, First Out) queue where callbacks from Web APIs (like setTimeout callbacks, DOM event handlers) are placed once their asynchronous operation is complete.
Microtask Queue: A higher-priority FIFO queue for callbacks from Promises (.then(), .catch(), .finally()) and queueMicrotask(). Microtasks are processed before macrotasks in each iteration of the event loop.
Event Loop: The continuous process that monitors the Call Stack and the queues. When the Call Stack is empty, it first checks the Microtask Queue and pushes any pending microtasks onto the Call Stack. Once the Microtask Queue is empty, it then checks the Callback Queue and pushes the oldest macrotask’s callback onto the Call Stack. This cycle repeats indefinitely.

Execution Order with setTimeout, Promise, async/await:

async/await is syntactic sugar built on Promises. An async function returns a Promise. await pauses the execution of the async function until the awaited Promise settles (resolves or rejects).

Code Example:

console.log('1. Start'); // Synchronous

setTimeout(() => {
  console.log('4. setTimeout callback (Macrotask)');
}, 0);

Promise.resolve().then(() => {
  console.log('3. Promise.resolve (Microtask)');
});

async function asyncFunc() {
  console.log('2a. Inside asyncFunc before await'); // Synchronous part of async func
  await Promise.resolve(); // This yields control; the rest becomes a microtask
  console.log('3a. Inside asyncFunc after await (Microtask)');
}
asyncFunc();

console.log('2. End'); // Synchronous

Expected Output (ES2026):

1. Start
2a. Inside asyncFunc before await
2. End
3. Promise.resolve (Microtask)
3a. Inside asyncFunc after await (Microtask)
4. setTimeout callback (Macrotask)

Explanation of Output:

'1. Start' is logged immediately (Call Stack).
setTimeout callback is sent to Web APIs. After 0ms, it moves to the Callback Queue (Macrotask).
Promise.resolve().then() callback is sent to the Microtask Queue.
asyncFunc() is called. Its synchronous part '2a. Inside asyncFunc before await' executes.
await Promise.resolve() causes the rest of asyncFunc to be scheduled as a microtask (specifically, the then handler for the awaited promise).
'2. End' is logged (Call Stack).
Call Stack is now empty. The Event Loop checks the Microtask Queue.
'3. Promise.resolve (Microtask)' is pushed to Call Stack and executed.
'3a. Inside asyncFunc after await (Microtask)' is pushed to Call Stack and executed.
Microtask Queue is now empty. The Event Loop checks the Callback Queue.
'4. setTimeout callback (Macrotask)' is pushed to Call Stack and executed.

Key Points:

JavaScript is single-threaded, but non-blocking due to the Event Loop.
Call Stack, Web APIs, Callback Queue (macrotasks), and Microtask Queue are core components.
Microtasks (Promises, async/await continuations) have higher priority than macrotasks (setTimeout, setInterval, DOM events).
The Event Loop continuously checks if the Call Stack is empty, then processes microtasks, then one macrotask.

Common Mistakes:

Assuming setTimeout(0) executes immediately after synchronous code.
Not understanding the priority difference between microtasks and macrotasks.
Believing async/await makes JavaScript multi-threaded.

Follow-up Questions:

What is requestAnimationFrame and where does it fit into the event loop?
Explain queueMicrotask() and its use cases.
How would you handle errors in async/await?

8. Memory Management & Garbage Collection

Q: How does JavaScript handle memory management, specifically garbage collection? Describe the “Mark-and-Sweep” algorithm and common scenarios that can lead to memory leaks in JavaScript applications, even with automatic garbage collection.

A: JavaScript uses automatic memory management, meaning developers don’t explicitly allocate or deallocate memory. The JavaScript engine (e.g., V8 in Chrome and Node.js) handles this through a Garbage Collector (GC).

Garbage Collection (GC): The process of identifying and reclaiming memory that is no longer reachable or “needed” by the application. In JavaScript, this is primarily done using the Mark-and-Sweep algorithm.

Mark-and-Sweep Algorithm:

Mark Phase: The garbage collector starts from a set of “roots” (e.g., global objects like window or global, the current call stack, active event listeners). It then traverses the object graph, marking all objects that are reachable from these roots. Any object that can be reached by following references from a root is considered “live.”
Sweep Phase: After marking, the garbage collector iterates through the entire heap and “sweeps” (deletes) all unmarked objects, reclaiming their memory.

Common Scenarios Leading to Memory Leaks: Even with automatic GC, memory leaks can occur when objects are unintentionally kept reachable, preventing them from being collected.

Accidental Global Variables: Variables declared without var, let, or const in non-strict mode become global properties (e.g., window.myVariable = ...). These are roots and are never garbage collected until the page unloads.

Forgotten Timers or Callbacks: setTimeout or setInterval callbacks that are never cleared can keep references to objects they enclose, preventing those objects from being collected. Similarly, event listeners that are attached but never removed can hold onto DOM elements and their associated data.

let element = document.getElementById('myButton');
element.addEventListener('click', () => {
  // This closure captures 'element' and other variables from its scope.
  // If 'element' is later removed from DOM, this listener might still be active,
  // preventing 'element' from GC if the listener is still referenced.
});
// To prevent leak: element.removeEventListener('click', handlerFunction);

Out-of-DOM References: If you store references to DOM elements in JavaScript data structures (e.g., an array or object), and then remove those elements from the DOM, the JavaScript reference might still exist. The element and its subtree will not be garbage collected until the JavaScript reference is also removed.

const detachedNodes = [];
const createAndDetach = () => {
  let div = document.createElement('div');
  document.body.appendChild(div);
  detachedNodes.push(div); // Storing reference
  document.body.removeChild(div); // Removed from DOM, but still referenced
};
createAndDetach(); // The div is still in memory via detachedNodes

Closures: As discussed earlier, closures can inadvertently retain references to large scopes or objects if they are long-lived and not properly managed.
WeakMap and WeakSet Misunderstanding: While WeakMap and WeakSet are designed to prevent memory leaks by holding “weak” references (which don’t prevent GC if no other strong references exist), incorrect usage or failure to use them when appropriate can still lead to leaks.

Key Points:

JavaScript uses automatic garbage collection, primarily Mark-and-Sweep.
GC identifies and reclaims memory for objects no longer reachable from “roots.”
Common leaks: global variables, uncleared timers/event listeners, out-of-DOM references, and long-lived closures.
Proactive memory management (nullifying references, removing listeners) is crucial.

Common Mistakes:

Believing that once an element is removed from the DOM, its memory is immediately reclaimed.
Ignoring the need to clean up event listeners or timers.
Underestimating the memory impact of closures holding onto large outer scopes.

Follow-up Questions:

What is the role of WeakMap and WeakSet in preventing memory leaks?
How can developer tools help identify memory leaks?
What are some performance considerations related to garbage collection?

9. Tricky Puzzle: `var` in a Loop with `setTimeout`

Q: Analyze the output of the following code snippet and explain why it behaves that way. How would you fix it to get the expected output?

for (var i = 0; i < 3; i++) {
  setTimeout(function() {
    console.log(i);
  }, 100);
}

A: Output:

3
3
3

Explanation: This is a classic JavaScript puzzle that demonstrates the interplay of var’s function scope, hoisting, and the asynchronous nature of setTimeout.

var’s Function Scope: The variable i is declared with var, which means it has function scope (or global scope, in this case, as it’s outside any function). It is not block-scoped to the for loop.
Hoisting: The declaration var i is hoisted to the top of the script.
Asynchronous Execution: setTimeout schedules its callback function to run after the current execution stack clears and a minimum delay has passed (100ms in this case).
Loop Completion: The for loop executes completely and synchronously. By the time the loop finishes, i has incremented to 3 (0, 1, 2, then i++ makes it 3, which fails the i < 3 condition).
Closure Over i: Each setTimeout callback forms a closure over the variable i. However, since i is a single variable in the outer (global) scope, all three closures reference the same i.
Delayed Execution: When the setTimeout callbacks finally execute after 100ms, they all look up the value of i in their shared outer scope, which by then has already settled at 3.

Fixes:

Method 1: Using let (ES6+ - Recommended) Using let instead of var introduces block-scoping. In each iteration of the loop, a new block-scoped i is created, and the closure captures that specific i for that iteration.

for (let i = 0; i < 3; i++) {
  setTimeout(function() {
    console.log(i); // Output: 0, 1, 2
  }, 100);
}

Method 2: Using an IIFE (Immediately Invoked Function Expression - Pre-ES6 solution) An IIFE creates a new function scope for each iteration. The current value of i is passed as an argument to the IIFE, which then captures that value in its own scope.

for (var i = 0; i < 3; i++) {
  (function(j) { // 'j' is a new variable for each iteration, capturing the current 'i'
    setTimeout(function() {
      console.log(j); // Output: 0, 1, 2
    }, 100);
  })(i); // Pass current 'i' into the IIFE
}

Key Points:

var creates function/global scope, leading to a single i variable shared by all closures.
setTimeout callbacks execute after the loop completes.
let creates a new block-scoped variable for each iteration, correctly capturing the intended value.
IIFEs can simulate block scope for var variables.

Common Mistakes:

Expecting the output to be 0, 1, 2 with var.
Not understanding why var causes this behavior.
Forgetting that setTimeout is asynchronous.

Follow-up Questions:

What if you used const instead of let in the loop?
Can you explain another scenario where var’s scoping can lead to unexpected bugs?
How would you achieve a similar effect using Array.prototype.forEach?

10. Architect Level: Real-World Bug - “Zombie Closures”

Q: As a JavaScript architect, you’re tasked with debugging a long-running SPA that experiences gradual memory growth. You suspect “zombie closures.” Describe what a “zombie closure” is, how it typically forms in a real-world application, and propose strategies for identifying and mitigating such issues.

A: A “zombie closure” (or more generally, an “uncollected closure” or “retained closure”) is a closure that remains in memory longer than intended, often holding onto references to its outer scope and potentially large objects within that scope, even when the functionality it provides is no longer needed. It’s a common cause of memory leaks in JavaScript SPAs.

How it Typically Forms in Real-World Applications:

Zombie closures often arise from a combination of:

Long-Lived Objects Referencing Short-Lived Contexts:
- Event Listeners: A common culprit. An event listener (which is a closure) is attached to a DOM element. If the DOM element is later removed from the document, but the listener function itself is still referenced by a global variable, an array, or another long-lived object, the listener (and the DOM element it closes over) cannot be garbage collected.
- Timers (setTimeout, setInterval): A timer callback (a closure) is scheduled, but never cleared. If this callback references variables from its creation scope, those variables (and potentially large objects) will remain in memory as long as the timer is active.
- Global Caches/Stores: If a component-specific closure is added to a global state management store (e.g., Redux, Vuex) or a global cache, and not removed when the component unmounts, it becomes a zombie.
Capturing Large Scopes: The closure might only need a small piece of data, but due to how JavaScript closures capture their entire lexical environment, it inadvertently holds onto a much larger scope, including references to entire component instances, large data structures, or even the window object.

Example Scenario (Simplified): Imagine a modal component in an SPA.

let globalListeners = []; // Architect's nightmare: a global array of listeners

function createModal() {
  const modalEl = document.createElement('div');
  const largeData = new Array(1000000).fill('some-data'); // Large object

  const clickHandler = () => {
    console.log('Modal clicked!', largeData.length);
    // This closure captures 'modalEl' and 'largeData'
  };

  modalEl.addEventListener('click', clickHandler);
  globalListeners.push(clickHandler); // Storing the listener globally

  document.body.appendChild(modalEl);

  return function destroyModal() {
    // This function is supposed to clean up, but it's incomplete
    document.body.removeChild(modalEl);
    // What's missing? Removing the listener from modalEl and globalListeners
    // If not removed, clickHandler is still referenced by globalListeners,
    // keeping modalEl and largeData in memory.
  };
}

const destroyCurrentModal = createModal();
// ... user interacts ...
destroyCurrentModal(); // Modal removed from DOM, but the leak persists!
// globalListeners still holds clickHandler, which holds modalEl and largeData.

Strategies for Identification and Mitigation:

Identification:

Browser Developer Tools (Performance/Memory Tab):
- Heap Snapshots: Take heap snapshots before and after a suspect action (e.g., opening and closing a modal, navigating to and from a page). Compare snapshots to identify objects that should have been garbage collected but are still present (“retained size”). Look for detached DOM elements, lingering event listeners, or unexpected array growth.
- Allocation Timeline: Record memory allocations over time. Look for increasing memory usage that doesn’t stabilize after operations.
- Retainers View: For identified leaky objects, inspect their “Retainers” to see what objects are still holding references to them, tracing back to the root causing the leak.
Code Reviews: Focus on patterns known to cause leaks:
- Event listener additions without corresponding removals.
- setTimeout/setInterval calls without clearTimeout/clearInterval.
- Global arrays or caches that grow indefinitely with local object references.
- Closures that capture entire component instances or large data structures.
Automated Testing: Integrate memory profiling into CI/CD pipelines for critical user flows to detect regressions.

Mitigation:

Strict Cleanup:
- Event Listeners: Always pair addEventListener with removeEventListener when a component unmounts or becomes irrelevant. Use AbortController for easier management of multiple event listeners.
- Timers: Always clear setTimeout with clearTimeout and setInterval with clearInterval when they are no longer needed.
Use WeakMap and WeakSet: For associating metadata with objects without preventing their garbage collection. If the primary reference to an object is removed, WeakMap/WeakSet entries referring to it will automatically be cleaned up.
Avoid Accidental Globals: Always declare variables with let, const, or var. Use strict mode ('use strict';) to catch undeclared variables.
Careful Closure Design:
- Limit the scope of variables captured by closures to only what’s strictly necessary.
- Consider passing data as arguments to callbacks instead of relying on closure over large outer scopes.
Component Lifecycle Management: Frameworks like React, Vue, Angular provide lifecycle hooks (e.g., componentWillUnmount, useEffect cleanup, ngOnDestroy) where cleanup logic (removing listeners, clearing timers) should be rigorously implemented.
Modular Design & Scoping: Encapsulate features within modules or classes to limit the reach of closures and promote better cleanup practices.
Nullifying References: Explicitly set variables to null when their associated objects are no longer needed, especially for long-lived references to large objects.

Key Points:

Zombie closures are closures that persist in memory, retaining references to objects/scopes, beyond their useful lifespan.
Common causes: un-removed event listeners/timers, global references to local objects, closures capturing large scopes.
Identification: Heap snapshots, allocation timelines, code reviews.
Mitigation: Rigorous cleanup (remove listeners, clear timers), WeakMap/WeakSet, careful closure design, framework lifecycle hooks, avoiding accidental globals.

Common Mistakes:

Assuming the browser automatically cleans up everything when an element is removed from the DOM.
Neglecting cleanup functions in component lifecycle methods.
Not regularly profiling memory in long-running applications.

Follow-up Questions:

How can requestAnimationFrame contribute to memory leaks if not handled correctly?
Describe a scenario where a WeakRef (ES2021) might be a useful tool.
What is the difference between shallow size and retained size in a heap snapshot?

MCQ Section

Choose the best answer for each question.

1. What will be the output of the following code?

console.log(typeof null);

A) "null" B) "object" C) "undefined" D) "number"

Correct Answer: B) "object"

Explanation:

A) "null": Incorrect. While null represents the intentional absence of any object value, typeof null specifically returns "object".
B) "object": Correct. This is a long-standing bug or historical quirk in JavaScript that typeof null returns "object". It’s not an actual object, but the typeof operator behaves this way.
C) "undefined": Incorrect. undefined is a distinct primitive type.
D) "number": Incorrect. This is not related to numbers.

2. Which of the following statements about let and var hoisting is true? A) Both let and var declarations are fully hoisted and initialized to undefined. B) var declarations are hoisted and initialized to undefined, while let declarations are not hoisted. C) var declarations are hoisted and initialized to undefined, while let declarations are hoisted but remain in the Temporal Dead Zone until initialized. D) Neither let nor var declarations are hoisted.

Correct Answer: C) var declarations are hoisted and initialized to undefined, while let declarations are hoisted but remain in the Temporal Dead Zone until initialized.

Explanation:

A) Incorrect: let is hoisted but not initialized, leading to the TDZ.
B) Incorrect: let is hoisted, but its behavior in the TDZ is different from var.
C) Correct: This accurately describes the hoisting behavior for both keywords. var is hoisted and initialized, let is hoisted but uninitialized within the TDZ.
D) Incorrect: Both are hoisted, but with different effects.

3. What will be the output of the following code?

const obj = {
  value: 42,
  getValue: function() {
    return this.value;
  }
};

const retrieveValue = obj.getValue;
console.log(retrieveValue());

A) 42 B) undefined C) ReferenceError D) TypeError

Correct Answer: B) undefined

Explanation:

A) 42: Incorrect. This would be the output if this correctly referred to obj.
B) undefined: Correct. When obj.getValue is assigned to retrieveValue, the function is detached from obj. When retrieveValue() is called, it’s a plain function call. In non-strict mode, this defaults to the global object (window or global), which doesn’t have a value property, so this.value evaluates to undefined. In strict mode, this would be undefined, leading to undefined.value which would cause a TypeError. However, without 'use strict', undefined is the typical output.
C) ReferenceError: Incorrect. The variable retrieveValue is defined.
D) TypeError: Incorrect in non-strict mode. A TypeError would occur if this were undefined (strict mode) and you tried to access a property on it.

4. Considering the JavaScript Event Loop, what is the correct order of execution for the console logs?

console.log('A');
Promise.resolve().then(() => console.log('B'));
setTimeout(() => console.log('C'), 0);
console.log('D');

A) A, B, C, D B) A, D, B, C C) A, D, C, B D) A, B, D, C

Correct Answer: B) A, D, B, C

Explanation:

A) Incorrect: Does not follow microtask/macrotask priority.
B) Correct:
1. 'A' (synchronous)
2. Promise.resolve().then() schedules 'B' as a microtask.
3. setTimeout() schedules 'C' as a macrotask.
4. 'D' (synchronous)
5. Call Stack empty, Event Loop processes Microtask Queue: 'B'.
6. Microtask Queue empty, Event Loop processes Callback Queue (Macrotask Queue): 'C'.
C) Incorrect: Swaps B and C.
D) Incorrect: Incorrect synchronous and asynchronous order.

5. Which of the following will create a block-scoped variable in JavaScript? A) var myVar = 10; B) function myFunc() { var x = 5; } C) if (true) { let y = 20; } D) myGlobal = 30;

Correct Answer: C) if (true) { let y = 20; }

Explanation:

A) var myVar = 10;: Creates a function-scoped or global-scoped variable, not block-scoped.
B) function myFunc() { var x = 5; }: Creates a function-scoped variable x, not block-scoped.
C) if (true) { let y = 20; }: Correct. let declarations are block-scoped. The y variable is only accessible within the if block.
D) myGlobal = 30;: Creates an accidental global variable (in non-strict mode) or a ReferenceError (in strict mode), but it’s not block-scoped.

Mock Interview Scenario: Debugging a UI Interaction Leak

Scenario Setup: You are interviewing for a Senior Frontend Engineer role. The interviewer presents you with a common problem in a legacy web application (using vanilla JavaScript) where a “tooltip” component is causing memory leaks. The tooltip is supposed to show information when a user hovers over certain elements and disappear when they move the mouse away or click outside. However, after navigating through several pages and interacting with many tooltips, the application’s memory usage steadily climbs.

Interviewer: “Okay, let’s say you’re debugging a memory leak in an old JavaScript application. You’ve narrowed it down to a tooltip component. Here’s a simplified version of how it’s implemented. Walk me through how you’d debug this, identify the leak, and then propose a robust solution.”

(Interviewer provides the following code snippet, possibly in a shared editor):

// Global scope / some module where tooltips are managed
const activeTooltips = []; // A list of currently active tooltip instances

function createTooltip(targetElement, message) {
  const tooltipElement = document.createElement('div');
  tooltipElement.className = 'tooltip';
  tooltipElement.textContent = message;
  document.body.appendChild(tooltipElement);

  // Positioning logic (simplified)
  tooltipElement.style.position = 'absolute';
  tooltipElement.style.left = `${targetElement.offsetLeft + 10}px`;
  tooltipElement.style.top = `${targetElement.offsetTop + 10}px`;

  // Event listeners for closing the tooltip
  const handleMouseLeave = () => {
    console.log('Mouse leave, removing tooltip');
    document.body.removeChild(tooltipElement);
    // Potential leak point 1: Is the listener itself removed?
    // Potential leak point 2: Is tooltipElement still referenced elsewhere?
  };

  const handleClickOutside = (event) => {
    if (!tooltipElement.contains(event.target) && event.target !== targetElement) {
      console.log('Click outside, removing tooltip');
      document.body.removeChild(tooltipElement);
      // Potential leak point 3: Is this listener removed?
    }
  };

  targetElement.addEventListener('mouseleave', handleMouseLeave);
  document.addEventListener('click', handleClickOutside);

  // Add to global management array (potential leak)
  activeTooltips.push({ targetElement, tooltipElement, handleMouseLeave, handleClickOutside });

  console.log('Tooltip created for:', targetElement.id);

  // Return a cleanup function
  return () => {
    console.log('Cleanup requested for tooltip on:', targetElement.id);
    // This is where cleanup should happen, but it's currently missing.
    // How would you ensure everything is truly released?
  };
}

// --- Usage Example (on a hypothetical page) ---
document.addEventListener('DOMContentLoaded', () => {
  const item1 = document.getElementById('item1'); // Assume these exist in HTML
  const item2 = document.getElementById('item2');

  if (item1) {
    item1.addEventListener('mouseenter', () => {
      const cleanup1 = createTooltip(item1, 'Details for Item 1');
      // In a real app, cleanup1 would be called when the tooltip is hidden
      // or when the component containing item1 unmounts.
      // For now, assume it's not explicitly called.
    });
  }
  if (item2) {
    item2.addEventListener('mouseenter', () => {
      const cleanup2 = createTooltip(item2, 'More info for Item 2');
    });
  }
});

Sequential Questions & Expected Flow:

Initial Assessment:
- Interviewer: “Based on this code, where do you immediately see potential memory leak points?”
- Candidate Response: “The most obvious leak points are related to event listeners and the activeTooltips array.
  1. handleMouseLeave and handleClickOutside are closures that capture tooltipElement and targetElement. When document.body.removeChild(tooltipElement) is called, the DOM element is removed, but the handleMouseLeave listener on targetElement and handleClickOutside listener on document are not removed. These listeners still exist, and since they’re closures, they retain references to tooltipElement and targetElement, preventing them from being garbage collected.
  2. The activeTooltips array is a global reference. Every time createTooltip is called, an object containing targetElement, tooltipElement, and the listener functions is pushed into this array. Even if the tooltip is removed from the DOM, this global array still holds strong references to all these objects, effectively creating a permanent leak.”
Debugging Strategy:
- Interviewer: “How would you confirm these suspicions using browser developer tools?”
- Candidate Response: “I’d use Chrome DevTools’ Memory tab:
  1. Baseline Heap Snapshot: Load the page, take a heap snapshot.
  2. Reproduce Leak: Hover over item1 to create a tooltip, then move the mouse away to ‘close’ it. Repeat this process several times (e.g., 5-10 times) for different items.
  3. Second Heap Snapshot: Take another heap snapshot.
  4. Compare Snapshots: Select the second snapshot and compare it against the first. Filter by ‘Objects allocated between snapshots’. I’d expect to see a growing number of HTMLDivElement (for tooltipElement), Array (if largeData was present), and EventListener entries that are not being cleaned up.
  5. Analyze Retainers: For a leaky HTMLDivElement or EventListener, I’d drill down into its ‘Retainers’ tree. This would show me what object is still holding a reference to it. I’d expect to see the activeTooltips array, or the document object (for the handleClickOutside listener), or the targetElement (for handleMouseLeave) as retainers.”

Proposing a Solution (Fixing the createTooltip function):

Interviewer: “Excellent. Now, how would you modify the createTooltip function to prevent these leaks and ensure proper cleanup?”
Candidate Response: “The key is to ensure all references are released when the tooltip is no longer needed. I would modify the returned cleanup function to actively remove all event listeners and remove the tooltip’s entry from the activeTooltips array.

// Global scope / some module where tooltips are managed
const activeTooltips = []; // A list of currently active tooltip instances

function createTooltip(targetElement, message) {
  const tooltipElement = document.createElement('div');
  tooltipElement.className = 'tooltip';
  tooltipElement.textContent = message;
  document.body.appendChild(tooltipElement);

  tooltipElement.style.position = 'absolute';
  tooltipElement.style.left = `${targetElement.offsetLeft + 10}px`;
  tooltipElement.style.top = `${targetElement.offsetTop + 10}px`;

  const handleMouseLeave = () => {
    console.log('Mouse leave, removing tooltip');
    // Call the cleanup function here to ensure full deallocation
    cleanup();
  };

  const handleClickOutside = (event) => {
    if (!tooltipElement.contains(event.target) && event.target !== targetElement) {
      console.log('Click outside, removing tooltip');
      // Call the cleanup function here
      cleanup();
    }
  };

  targetElement.addEventListener('mouseleave', handleMouseLeave);
  document.addEventListener('click', handleClickOutside);

  // Store a reference to the entry in activeTooltips for removal
  const tooltipInstance = {
    targetElement,
    tooltipElement,
    handleMouseLeave,
    handleClickOutside
  };
  activeTooltips.push(tooltipInstance);

  console.log('Tooltip created for:', targetElement.id);

  // --- The improved cleanup function ---
  const cleanup = () => {
    console.log('Executing full cleanup for tooltip on:', targetElement.id);

    // 1. Remove event listeners
    targetElement.removeEventListener('mouseleave', handleMouseLeave);
    document.removeEventListener('click', handleClickOutside);

    // 2. Remove tooltip element from DOM (if still present)
    if (document.body.contains(tooltipElement)) {
      document.body.removeChild(tooltipElement);
    }

    // 3. Remove reference from the global activeTooltips array
    const index = activeTooltips.indexOf(tooltipInstance);
    if (index > -1) {
      activeTooltips.splice(index, 1);
    }

    // 4. Optionally, nullify local references if they were large
    // (though removing from activeTooltips should be enough for GC)
    // targetElement = null;
    // tooltipElement = null;
    // handleMouseLeave = null;
    // handleClickOutside = null;
  };

  return cleanup; // Return the full cleanup function
}

// --- Modified Usage Example ---
// In a real application, the cleanup function would be stored and called
// when the tooltip is supposed to be fully gone.
// For instance, if the tooltip is temporary:
document.addEventListener('DOMContentLoaded', () => {
  const item1 = document.getElementById('item1');
  if (item1) {
    let currentTooltipCleanup = null; // Store cleanup for current tooltip
    item1.addEventListener('mouseenter', () => {
      if (currentTooltipCleanup) {
        currentTooltipCleanup(); // Clean up any existing tooltip
      }
      currentTooltipCleanup = createTooltip(item1, 'Details for Item 1');
    });
    // You might also need a way to call currentTooltipCleanup when item1 is removed from DOM.
  }
});

“This revised cleanup function ensures that all strong references (DOM, event listeners, and the global activeTooltips array) are removed, allowing the garbage collector to reclaim the memory associated with the tooltip and its captured scope.”

Red Flags to Avoid:

Ignoring the activeTooltips array: Forgetting to clear references from global data structures.
Only removing DOM elements: Not addressing event listener cleanup.
Assuming automatic cleanup: Believing JavaScript will magically handle everything without explicit removeEventListener calls.
Proposing overly complex solutions: Starting with WeakMap before addressing fundamental listener/reference cleanup.

Practical Tips

Master the Fundamentals: JavaScript’s “weird parts” (coercion, hoisting, this, closures, event loop) are often the most difficult to grasp but are fundamental. Invest time in understanding them deeply. Use online visualizers for the event loop (e.g., loupe by Philip Roberts) and this binding.
Prioritize ES2015+ Syntax: While understanding var is important for legacy code, always write modern code using let, const, arrow functions, classes, and async/await. This naturally avoids many common pitfalls related to var and this binding.
Practice Tricky Puzzles: Actively seek out and solve JavaScript code puzzles that test your understanding of these concepts. Websites like JavaScript.info, LeetCode (for specific JS algorithm questions), and advanced interview prep blogs often feature these.
Understand the “Why”: Don’t just memorize answers. For each concept, ask “why does JavaScript behave this way?” This often leads to understanding the ECMAScript specification or historical design decisions, which impresses interviewers.
Be Ready for Debugging Scenarios: Many interviews, especially for senior roles, involve debugging. Practice identifying common anti-patterns that lead to memory leaks, unexpected this behavior, or race conditions. Know how to use browser developer tools effectively (Memory tab, Performance tab, Debugger).
Explain Your Thought Process: When solving a problem or answering a question, articulate your reasoning. Explain your initial assumptions, how you’d test them, and why you chose a particular solution. This demonstrates problem-solving skills, not just knowledge.
Stay Current (as of 2026-01-14): Keep up with the latest ECMAScript features and proposals. While the core “weird parts” remain, knowing about recent additions like at() for arrays, Object.groupBy, import.meta, WeakRef, or new RegExp features shows your commitment to modern JavaScript development.

Summary

This chapter has laid the groundwork for excelling in JavaScript interviews by focusing on the language’s often counter-intuitive but crucial core mechanisms. We’ve explored:

Hoisting & Temporal Dead Zone: Understanding the distinct behaviors of var, let, and const declarations.
Type Coercion & Strict Equality: Navigating JavaScript’s type conversion rules and the importance of ===.
Scope & Lexical Environment: Differentiating global, function, and block scopes, and how lexical environments determine variable access.
Closures & Memory Management: Unpacking the power of closures and their potential for memory leaks.
this Binding & Arrow Functions: Demystifying the this keyword and the lexical this behavior of arrow functions.
Prototype Chain & ES6 Classes: Grasping JavaScript’s inheritance model and how ES6 classes build upon it.
Event Loop & Asynchronous JavaScript: Comprehending how JavaScript handles concurrency without blocking, including the priority of microtasks over macrotasks.
Memory Management & Garbage Collection: Learning about Mark-and-Sweep and identifying common memory leak scenarios.

By deeply understanding these topics, practicing with tricky puzzles, and applying structured debugging techniques, you’re building a robust foundation for any JavaScript role, from entry-level to architect.

Next Steps in Preparation:

Continue to Chapter 2: Advanced Asynchronous Patterns & Error Handling.
Work through more code puzzles on platforms like LeetCode or HackerRank.
Build small projects that intentionally incorporate these “weird parts” to solidify your understanding.
Regularly review official ECMAScript specifications for detailed insights.

References

MDN Web Docs (Mozilla Developer Network): The most authoritative and up-to-date resource for JavaScript language features and Web APIs.
- https://developer.mozilla.org/en-US/docs/Web/JavaScript
JavaScript.info: A comprehensive and modern JavaScript tutorial covering everything from basics to advanced topics with clear explanations and examples.
- https://javascript.info/
“You Don’t Know JS Yet” (Book Series by Kyle Simpson): Deep dives into JavaScript’s core mechanisms, highly recommended for understanding the “weird parts.” While the original series is older, the concepts are timeless.
- https://github.com/getify/You-Dont-Know-JS
Philip Roberts’ “What the heck is the event loop anyway?”: An excellent visual and conceptual explanation of the Event Loop.
- https://www.youtube.com/watch?v=8aGhZQcJLcg
Google Developers - Memory Leaks in JavaScript Applications: Practical guide on identifying and fixing memory leaks using Chrome DevTools.
- https://developer.chrome.com/docs/devtools/memory-problems/

This interview preparation guide is AI-assisted and reviewed. It references official documentation and recognized interview preparation resources.

Introduction to Modern JavaScript (ES2026)

Table of Contents

Core Interview Questions

1. Hoisting & Temporal Dead Zone

2. Type Coercion & Strict Equality

3. Scope & Lexical Environment

4. Closures & Memory Management

5. this Binding & Arrow Functions (ES2015+)

6. Prototype Chain & ES6 Classes

7. Event Loop & Asynchronous JavaScript

8. Memory Management & Garbage Collection

9. Tricky Puzzle: var in a Loop with setTimeout

10. Architect Level: Real-World Bug - “Zombie Closures”

MCQ Section

Mock Interview Scenario: Debugging a UI Interaction Leak

Practical Tips

Summary

References

5. `this` Binding & Arrow Functions (ES2015+)

9. Tricky Puzzle: `var` in a Loop with `setTimeout`