Interview Deep Dive: Scope, Closures, this and Hoisting

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Execution context

The environment the engine creates to run a script or a function call: its variables, scope chain and this.

Hoisting

Declarations being set up at the start of their scope, before any line of it runs.

Temporal dead zone (TDZ)

The time between the start of a scope and the line declaring a let/const, when using the name throws an error.

Lexical scope

The rule that a name's meaning depends on where the code is written, not where it is called.

Scope chain

The list of scopes the engine searches, from the inside outwards, to find a name.

Shadowing

An inner variable with the same name as an outer one, hiding the outer one inside its scope.

Closure

A function together with the variables it remembers from the scope where it was created.

this

A special value set by how a function is called: the object before the dot, a new object, an explicit choice, or undefined/window.

Sloppy mode

The older, non-strict way JavaScript runs classic scripts, with some forgiving and confusing rules.

1. 1

   Swap var for let

   In the first example, change var a = 1; to let a = 1;. Predict the first console line now, then run. Which error message appears?

2. 2

   Fix the var loop without let

   In the second example, change only the var k loop so it prints 0 1 2, without using let. Hint: setTimeout passes extra arguments to the callback: setTimeout(fn, 0, k).

3. 3

   Make the script strict

   In the third example, add "use strict"; as the first line. Predict which lines change (look for every place window was the answer).

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

1. 1

   Execution context and hoisting. Before running a script or function, the engine does a creation phase: it finds every declaration in that scope and creates its binding. var names are created and set to undefined; function declarations are created with the whole function, so you can call them before the line they're written on; let, const and class names are created but uninitialised. Reading them before their line throws ReferenceError: Cannot access 'x' before initialization. That gap between the start of the scope and the declaration is the temporal dead zone (TDZ). Function expressions (var f = function () {}) follow their variable's rule: var f is undefined, so calling it early gives TypeError: f is not a function.

2. 2

   Lexical scope. A scope is the region where a name is visible. JavaScript uses lexical (static) scope: what a name refers to depends on where the code is written, not where it is called from. The engine looks the name up in the current scope, then the enclosing one, outward to the global scope: the scope chain. var is scoped to the whole function (blocks like if and for don't contain it); let and const are scoped to the nearest block { }. A local declaration shadows (hides) an outer one with the same name for its whole scope, including the lines before it, which is why console.log(x); var x = 1; inside a function prints undefined even when a global x exists.

3. 3

   Closures. A closure is a function plus the scope it was created in. When an inner function is returned or passed somewhere, it keeps a live link to the outer variables (not a copy of their values). Each call of the outer function creates a new scope, so two counters made by makeCounter() don't share a count. The famous loop question: with for (var i ...), all callbacks share one i, which is 3 by the time they run; with for (let i ...), the spec creates a fresh binding per iteration, so each callback sees its own value. The pre-2015 fix was an IIFE that passes i in as a parameter.

4. 4

   **this is decided by the call, not the definition** (except arrows). The rules, from strongest to weakest: (1) new Fn() sets this to the new object; (2) explicit: fn.call(obj), fn.apply(obj), or a function made with fn.bind(obj) (bound functions ignore later call/apply); (3) implicit: obj.fn() sets this to obj, the thing before the dot at call time; (4) default: a plain call fn() gives undefined in strict mode (modules, classes, "use strict") and the global object window in sloppy scripts. Arrow functions have no this of their own: they use the this of the scope where they were written, and call/bind can't change it.

5. 5

   **Losing this** is the classic bug: const f = user.greet; f() or setTimeout(user.greet, 100) or button.addEventListener("click", obj.handle) all call the function without the dot, so rule 4 applies (and for listeners, this becomes the element). Fixes: wrap it in an arrow (() => user.greet()), use bind, or define the method as an arrow class field (handle = () => {...}). An arrow used as an object-literal method is the opposite mistake: this comes from outside the object, not the object.

6. 6

   How to answer output questions. Read the code twice. First pass: run the creation phase yourself, writing down each name and its starting value (undefined, TDZ, or function). Second pass: run line by line, and for every function call ask "which scope is this name from?" and "how is this function called?" Say your reasoning out loud; interviewers value the rules more than the answer. Phase 3 (functions and closures) and Phase 7 (this) cover each rule in depth.

• ↔

  Arrow class fields keep this bound for callbacks, but each instance gets its own copy of the function instead of sharing one on the prototype, and subclasses can't call them with super.

• ↔

  Closures give cheap private state, but long-lived closures (listeners, timers, caches) keep everything they reference alive; forgetting to remove them is a common memory leak (Topic 14.8).

• I can predict the result of using var, let, const and functions before their declarations.

• I can trace a name through the scope chain, including shadowing.

• I can explain and fix the var loop closure bug three ways.

• I can determine this for any call using the four rules plus arrows.

• I can explain my reasoning out loud for an output question.