JavaScript Hoisting Interview Questions

What hoisting actually is — two-phase execution

Hoisting is not a physical movement of code. JavaScript never rewrites your file. What actually happens is that the JavaScript engine processes your code in two distinct phases:

1. Creation phase (Compilation) — the engine scans your code and allocates memory for all declarations before a single line executes.
2. Execution phase — your code runs line by line, assigning values and calling functions.

The result behaves as if declarations were moved to the top. That mental model is useful, but the mechanism is memory allocation — not code movement.

Lexical Environment and where variables actually live

During the creation phase, each execution context creates a Lexical Environment — a structure that maps variable names to their values. Inside that Lexical Environment is an Environment Record, which is where the actual variable bindings are stored.

When an interviewer asks "where exactly are variables stored?", the correct answer is: in the Environment Record of the Lexical Environment belonging to the current execution context. This is what makes hoisting possible — the Environment Record is populated during the creation phase before any code runs.

var — hoisted and initialized to undefined

console.log(name)  // undefined — not a ReferenceError
var name = 'Alice'
console.log(name)  // 'Alice'

During the creation phase, name is registered in the Environment Record and set to undefined. The assignment name = 'Alice' is not hoisted — it runs in place during the execution phase.

What the engine effectively processes:

// Creation phase — var is hoisted and initialized to undefined
var name = undefined
 
// Execution phase — runs line by line
console.log(name)   // undefined
name = 'Alice'      // assignment runs here
console.log(name)   // 'Alice'

typeof is safe — even with undeclared variables

console.log(typeof notDeclaredAtAll)  // 'undefined' — not a ReferenceError
console.log(typeof varHoisted)        // 'undefined'
var varHoisted = 42

typeof is the only operator that doesn't throw for undeclared variables. This makes it the safe way to check if a variable exists. Everything else — accessing the variable directly — throws a ReferenceError for undeclared names.

let and const — hoisted but NOT initialized (Temporal Dead Zone)

console.log(age)  // ReferenceError: Cannot access 'age' before initialization
let age = 25

let and const ARE hoisted — the engine registers them in the Environment Record. But unlike var, they are placed in the Temporal Dead Zone (TDZ): registered but explicitly marked as uninitialised. Accessing any TDZ variable throws a ReferenceError.

// TDZ starts here for 'score'
console.log(score)  // ReferenceError — in TDZ
 
const score = 100   // TDZ ends here — now accessible
console.log(score)  // 100

The TDZ is not a gap in knowledge — it's a deliberate design decision. var's silent undefined masked real bugs for years in production code.

Function declarations — fully hoisted (both declaration AND body)

greet('Alice')  // 'Hello, Alice' — works perfectly before the declaration
 
function greet(name) {
  console.log(`Hello, ${name}`)
}

Function declarations are completely hoisted — the engine registers the full function body in the Environment Record during the creation phase. Calling them before their declaration in source is intentional: it lets you place main logic at the top and helper functions at the bottom.

Function expressions and arrow functions — NOT fully hoisted

greet('Alice')  // TypeError: greet is not a function
 
var greet = function(name) {
  console.log(`Hello, ${name}`)
}

Here greet is a var — it's hoisted and initialized to undefined. Calling undefined() as a function throws a TypeError. The function body stays where you wrote it.

// What the engine sees:
var greet = undefined  // hoisted
 
greet('Alice')  // TypeError: greet is not a function (it's undefined)
 
greet = function(name) {  // assignment runs here
  console.log(`Hello, ${name}`)
}

Arrow functions follow the same rules as their binding keyword (var → undefined + TypeError, const → TDZ + ReferenceError):

sayHi()  // TypeError if var, ReferenceError if const/let
 
const sayHi = () => console.log('Hi')

Named function expressions — the name is local only

var calc = function multiply(a, b) {
  return a * b
}
 
console.log(calc(3, 4))      // 12
console.log(multiply(3, 4))  // ReferenceError: multiply is not defined

In a named function expression, the name (multiply) is only accessible inside the function body (for recursion). It is not hoisted to the outer scope. Only calc (the variable) is accessible outside — and only after the assignment runs.

Function declaration vs var — who wins? (Interview classic)

When a function declaration and a var share the same name, the engine processes them in this order during hoisting:

1. Function declarations are hoisted first and fully initialized
2. var declarations are then processed — but if the name already exists, the var declaration is silently ignored
3. Assignments (var foo = value) still run during the execution phase and overwrite whatever was there

function test() {
  console.log(typeof foo)  // 'function' — function wins during hoisting
 
  var foo = 'bar'          // var declaration ignored (foo already exists); assignment runs later
 
  function foo() {
    return 'I am a function'
  }
 
  console.log(typeof foo)  // 'string' — assignment overwrote function
}
 
test()

🔥 Interview gold — the hardest hoisting trap

This is one of the most commonly asked tricky questions at top companies:

console.log(a)      // What prints?
var a = 1
function a() {}
console.log(a)      // What prints?

Output:

function a() {}    // NOT undefined — function declaration wins hoisting
1                  // assignment var a = 1 runs and overwrites the function

Step by step in the creation phase:

1. Function declaration function a() {} is hoisted first → a is the function
2. var a is processed — but a already exists, so the declaration is ignored
3. Execution starts: console.log(a) → prints the function
4. a = 1 runs → overwrites the function with 1
5. console.log(a) → prints 1

Most candidates say undefined for the first log. The correct answer is the function body.

Hoisting is per-scope — not just global

var x = 1
 
function example() {
  console.log(x)  // undefined — NOT 1
  var x = 2
  console.log(x)  // 2
}
 
example()

The var x inside example is hoisted to the top of that function's scope — completely separate from the global x. The function creates a new Environment Record, and x is registered there as undefined. This shadows the global x for the entire function body.

Block-scoped functions — strict mode vs sloppy mode

if (true) {
  function test() { return 'block' }
}
 
console.log(typeof test)  // In sloppy mode: 'function' — hoisted to outer scope
                          // In strict mode: 'undefined' — block scoped

This is an edge case interviewers occasionally ask about. The behaviour differs between modes:

• Sloppy mode: functions declared inside blocks are hoisted to the enclosing function/global scope (legacy behaviour)
• Strict mode ('use strict' or ES modules): functions declared inside blocks are block-scoped — they don't leak out

In modern JavaScript (ES modules are always strict), a function declared inside an if block is not accessible outside it.

Import statements — module instantiation, not hoisting

// This works:
console.log(add(2, 3))    // 5
import { add } from './math.js'

ES module imports appear to be hoisted, but the mechanism is different from variable or function hoisting. Imports are processed during module instantiation — a separate phase that runs before any module code executes. The entire dependency graph is resolved and linked before execution begins. This is not the same as "hoisted like a function declaration." Safer phrasing: imports are resolved during module instantiation, before any code runs.

Class declarations — hoisted but in TDZ (same as let/const)

const p = new Person('Alice')  // ReferenceError: Cannot access 'Person' before initialization
class Person {
  constructor(name) { this.name = name }
}

Class declarations are hoisted but remain in the TDZ. You cannot use a class before its declaration. This is consistent with let/const semantics.

Class expressions follow their binding keyword:

// var class expression
var Animal = class {}       // var is undefined until assignment
// const class expression
const Animal = class {}     // TDZ until assignment line

The complete hoisting reference table

Declaration	Hoisted?	Initialized to	Accessing before declaration
var x	✓ Yes	undefined	undefined
let x	✓ Yes	TDZ (uninitialised)	ReferenceError
const x	✓ Yes	TDZ (uninitialised)	ReferenceError
function f(){}	✓ Yes	Full function body	Works ✓
var f = function(){}	✓ Yes (var only)	undefined	TypeError
const f = () => {}	✓ Yes (const only)	TDZ	ReferenceError
class C {}	✓ Yes	TDZ	ReferenceError
var C = class {}	✓ Yes (var only)	undefined	TypeError
import { x }	Module instantiation	Fully resolved	Works ✓

Hoisting priority — the four rules in order

1. Function declarations are hoisted first — highest priority, fully initialized
2. var declarations are processed next — if name already exists (from a function declaration), the var declaration is silently ignored
3. Assignments (var x = value) are NOT hoisted — they run during the execution phase in order
4. let/const/class are hoisted into TDZ — registered but inaccessible until their line

When in doubt: ask yourself "what phase is this?". Creation phase = declarations only. Execution phase = assignments, calls, everything else.