JavaScript Scope Interview Questions

How scope is created — Execution Context and Lexical Environments

Scope is not magic. It is created by the JavaScript engine in a predictable, mechanical way:

1. Every time JavaScript runs a piece of code (global code, a function call, an eval), it creates an Execution Context.
2. Each Execution Context contains a Lexical Environment — a data structure that stores the variable bindings for that context.
3. Each Lexical Environment has an Environment Record (the actual key-value store of variable names and values) and a pointer called outer that references the Lexical Environment of the enclosing scope.

The scope chain is literally a linked list of Lexical Environments, connected by those outer pointers. Looking up a variable means walking that linked list outward until you find the binding or hit null (global scope has no outer).

function outer() {
  const x = 'outer'           // stored in outer's Environment Record
  function inner() {
    const y = 'inner'         // stored in inner's Environment Record
    console.log(x)            // x not found in inner → follow outer pointer → found in outer's record
  }
  inner()
}

The five types of scope

1. Global scope

Variables declared outside any function or block. The global scope differs by environment:

// Browser: top-level var becomes a property of window
var appName = 'JSPrep'
console.log(window.appName)  // 'JSPrep'
 
// let/const do NOT become window properties even at global scope
let version = '2.0'
console.log(window.version)  // undefined
 
// Node.js: global object, not window
// global.something = 'value'
 
// Universal: globalThis — works in browser, Node, and Web Workers
console.log(globalThis === window)   // true in browser
console.log(globalThis === global)   // true in Node.js

ES modules change global scope: top-level variables in a type="module" file are module-scoped, not global. They do not attach to window. This is why modules don't pollute the global namespace.

2. Function scope

Variables declared inside a function exist only within that function. Both var, let, and const respect function boundaries.

function makeGreeting() {
  var msg    = 'Hello'    // function-scoped
  let name   = 'Alice'    // function-scoped
  const punc = '!'        // function-scoped
  console.log(msg + ', ' + name + punc)  // 'Hello, Alice!'
}
 
makeGreeting()
console.log(msg)   // ReferenceError — all three are gone

3. Block scope

let and const are scoped to the nearest enclosing { } block. var ignores all blocks except function boundaries.

if (true) {
  var funcScoped  = 'leaks out'   // var ignores the if-block
  let blockScoped = 'stays in'    // let respects the block
  const alsoBlock = 'stays in'    // const respects the block
}
 
console.log(funcScoped)   // 'leaks out'  — var crossed the block
console.log(blockScoped)  // ReferenceError
console.log(alsoBlock)    // ReferenceError

4. Module scope

Every ES module (import/export) has its own scope. Top-level declarations are module-private unless explicitly exported.

// math.js
const PI = 3.14159             // module-private — cannot be accessed from outside
export function area(r) {      // exported — accessible to importers
  return PI * r * r            // PI is visible inside the module
}
 
// main.js
import { area } from './math.js'
console.log(area(5))           // 78.53975 ✓
console.log(PI)                // ReferenceError — PI was never exported

5. Eval scope (know it, avoid it)

eval() executes a string as code in the current scope. In non-strict mode, it can introduce new variable bindings into the current scope at runtime — making static analysis impossible.

function dangerous() {
  eval('var surprise = 42')   // injects 'surprise' into function scope at runtime
  console.log(surprise)       // 42 — appeared from nowhere
}
 
// In strict mode, eval gets its own scope and cannot inject bindings
'use strict'
function safe() {
  eval('var surprise = 42')
  console.log(typeof surprise)  // 'undefined' — eval's var stayed in eval's scope
}

Never use eval in production. It disables engine optimisations, creates security vulnerabilities (XSS), and makes scope unpredictable. Asked in interviews to test scope depth knowledge, not as a recommendation.

Lexical scope vs dynamic scope — the fundamental design choice

JavaScript uses lexical scope (also called static scope): scope is determined by where a function is written in the source code. This decision is made at parse time and never changes at runtime.

const x = 'global'
 
function readX() {
  console.log(x)   // always reads from where readX was DEFINED
}
 
function other() {
  const x = 'local x'
  readX()           // LEXICAL: prints 'global', ignores 'local x' in other()
}
 
other()  // 'global'

Dynamic scope would work the opposite way: scope is determined by where a function is called from. In a dynamically scoped language, readX() called inside other() would see other()'s x = 'local x'. JavaScript does not work this way — but this does (it is the one dynamically-scoped thing in JavaScript, bound at call time, not definition time).

The with statement was JavaScript's attempt at dynamic scope-like behaviour. It adds an object's properties to the scope chain, making with (obj) { x } look up x in obj first. It's banned in strict mode, obsolete, and a scope chain nightmare — but you may be asked about it:

const obj = { x: 42 }
with (obj) {
  console.log(x)  // 42 — obj's properties injected into scope chain
}
// Strict mode: SyntaxError — with is forbidden

Variable shadowing — same name, different variable

let score = 100
 
function game() {
  let score = 50        // completely new variable — shadows outer 'score'
  console.log(score)    // 50 — reads the inner one
}
 
game()
console.log(score)      // 100 — outer is untouched

Shadowing creates an entirely separate variable that shares a name. The outer variable continues to exist — it is simply unreachable from within the inner scope for the duration of that scope. The most dangerous shadowing bug: you intend to modify an outer variable, but accidentally declare a new inner one with the same name. Use ESLint's no-shadow rule.

// Dangerous shadow bug
let count = 0
 
function increment() {
  let count = count + 1    // ReferenceError: 'count' accessed before initialization
  // The let creates a new 'count' in TDZ — the right side reads the TDZ 'count', not the outer one
}

The var-in-loop closure trap — the most asked scope interview question

// Classic bug — what does this print?
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0)
}
// Prints: 3, 3, 3 (NOT 0, 1, 2)

Why: var is function-scoped (or global here). All three setTimeout callbacks share the same i variable — there is only one i in the scope, not three. By the time the callbacks run (after the loop ends), i is already 3.

Fix 1 — use let:

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

let creates a new binding per iteration. The JavaScript engine creates a new Lexical Environment for each loop iteration, copies the current value of i into it, and the callback captures that iteration's specific i. This is a spec-level guarantee for let in for loops.

Fix 2 — IIFE (pre-ES6 solution):

for (var i = 0; i < 3; i++) {
  (function(capturedI) {
    setTimeout(() => console.log(capturedI), 0)
  })(i)
}
// Prints: 0, 1, 2

The IIFE creates a new function scope per iteration, and capturedI is a new binding each time. Each callback closes over its own capturedI.

Fix 3 — bind:

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

let/const in every type of for loop

// for — new binding per iteration ✓
for (let i = 0; i < 3; i++) { /* i is fresh each iteration */ }
 
// for...of — new binding per iteration ✓
const arr = ['a', 'b', 'c']
for (let item of arr) { /* item is a new binding each iteration */ }
 
// for...in — new binding per iteration ✓
const obj = { x: 1, y: 2 }
for (let key in obj) { /* key is a new binding each iteration */ }
 
// But: the initializer of for(let i...) is in an OUTER block scope
// The body of for gets a COPY of i, which is updated each iteration
// This means: mutations to i inside the body are propagated back — engine handles this

Block scope in switch — the invisible bug

switch (action) {
  case 'increment':
    let count = state.count + 1    // let is scoped to the SWITCH BLOCK, not this case
    break
  case 'decrement':
    let count = state.count - 1    // SyntaxError: Identifier 'count' has already been declared
    break
}

The entire switch statement is one block. All let/const declarations inside it share the same scope — even across different case branches. The fix: wrap each case in its own block:

switch (action) {
  case 'increment': {          // explicit block — creates its own scope
    let count = state.count + 1
    break
  }
  case 'decrement': {          // separate block — no conflict
    let count = state.count - 1
    break
  }
}

catch block scope — the exception to the rule

try {
  throw new Error('oops')
} catch (err) {
  console.log(err.message)   // 'oops' — err is scoped to catch block
}
 
console.log(err)   // ReferenceError — err does not exist outside catch
 
// But: var inside catch leaks (var ignores catch block boundaries)
try {
  // ...
} catch (e) {
  var leaked = 'I escaped'
}
console.log(leaked)   // 'I escaped' — var leaked out of catch

The catch binding (err, e, etc.) is always block-scoped to the catch clause, even in pre-ES6 environments. This was one of the first block-scoped bindings in JavaScript.

Default parameter scope — the hidden extra scope

This is one of the most obscure scope questions interviewers ask at senior level:

// Default parameters have their OWN scope — separate from the function body
function outer(a, b = () => a) {  // parameters create a scope
  let a = 'inner'                 // body creates a different scope
  console.log(b())                // What does b() see?
}
 
outer('outer')  // 'outer' — b() captures parameter 'a', not body's 'a'

When a function has default parameters, JavaScript creates two scopes:

1. A parameter scope containing the parameter bindings
2. A body scope nested inside it for the function body

Default parameters are evaluated in the parameter scope, not the body scope. Redeclaring a parameter name with let/const inside the body creates a new binding in the body scope, shadowing the parameter. Default parameter expressions can reference earlier parameters:

function greet(name, greeting = `Hello, ${name}`) {
  console.log(greeting)
}
greet('Alice')   // 'Hello, Alice' — greeting default references name

The arguments object and scope

function regular() {
  console.log(arguments[0])   // works — arguments is in function scope
}
 
const arrow = () => {
  console.log(arguments)      // ReferenceError (or outer arguments if in a function)
}
 
// Arrow functions do not have their own 'arguments' object
// They inherit 'arguments' from the nearest enclosing regular function

arguments is a function-scoped object in regular functions only. Arrow functions don't have it. This matters for variadic functions — use rest parameters (...args) instead of arguments in modern code.

Implicit globals — the worst scope bug

function setName() {
  name = 'Alice'   // No var/let/const — NOT a local variable
}
 
setName()
console.log(name)  // 'Alice' — accidentally created a global!

In non-strict mode, assigning to an undeclared variable creates a property on the global object. This is one of the most dangerous bugs because it's silent and produces hard-to-trace cross-function contamination. Strict mode converts this into a ReferenceError:

'use strict'
function setName() {
  name = 'Alice'   // ReferenceError: name is not defined
}

IIFE — scope isolation before modules

// Named IIFE — the name is only visible INSIDE the IIFE
(function myModule() {
  console.log(myModule)    // ƒ myModule() — visible inside
})()

console.log(myModule)     // ReferenceError — not visible outside

IIFEs were the primary pattern for scope isolation before ES modules. The function creates a new scope; anything declared inside stays private. Named IIFEs allow self-reference for recursion, but the name is local to the IIFE only.

Scope chain lookup cost

Each variable lookup walks the scope chain from the current Environment Record outward. Variables in the current scope are found immediately. Variables from outer scopes require traversing more links. In tight loops, this matters:

// Slower — looks up 'document' through scope chain on every iteration
for (let i = 0; i < 10000; i++) {
  document.getElementById('box').style.left = i + 'px'  // scope chain lookup + DOM access
}
 
// Faster — cache the reference in local scope
const box = document.getElementById('box')   // one lookup
for (let i = 0; i < 10000; i++) {
  box.style.left = i + 'px'   // local variable, found immediately
}

Modern V8 optimises most of this, but the pattern of caching global/outer references in local variables is still a best practice in performance-critical code.

Scope vs closure — the key distinction

These terms are often confused. They are related but distinct:

• Scope is a static structure — it describes which variables are accessible where in the source code. It is determined at parse time and doesn't change.
• Closure is a runtime phenomenon — it is what happens when a function is executed and retains access to its outer scope's variables even after that outer scope has returned.

function outer() {
  let x = 10              // x is in outer's scope (static structure)
  return function inner() {
    console.log(x)        // inner closes over outer's scope at RUNTIME (closure)
  }
}
 
const fn = outer()   // outer's scope is "gone" — but the closure keeps x alive
fn()                 // 10 — this is closure in action

Every function in JavaScript is technically a closure — it closes over the scope in which it was defined. But we typically only call it a "closure" when the function outlives its outer scope — when it's returned, stored, or passed as a callback.

The four scope rules — memorise this order for interviews

1. Lexical: scope is determined by where the function is written, not called
2. Nested: inner scopes can access outer scopes; outer cannot access inner
3. Shadowing: inner declarations with the same name hide (shadow) outer ones
4. var vs let/const: var respects function boundaries; let/const respect block boundaries