JavaScript var, let, and const Interview Questions

var — the original, the problematic one

var has three behaviours that regularly cause bugs:

1. var is function-scoped, not block-scoped

function example() {
  if (true) {
    var x = 10   // you'd expect this to stay in the if block
  }
  console.log(x)  // 10 — var leaked out of the block
}

// With let:
function example2() {
  if (true) {
    let x = 10
  }
  console.log(x)  // ReferenceError — stayed in the block ✓
}

2. var is hoisted and initialized to undefined

console.log(name)  // undefined — not an error
var name = 'Alice'
console.log(name)  // 'Alice'

// The engine sees this:
var name = undefined  // hoisted
console.log(name)     // undefined
name = 'Alice'        // assignment stays in place
console.log(name)     // 'Alice'

3. var can be re-declared in the same scope

var user = 'Alice'
var user = 'Bob'   // no error — silently overwrites
console.log(user)  // 'Bob'

// let throws:
let score = 10
let score = 20     // SyntaxError: Identifier 'score' has already been declared

let — the modern variable

let fixes all three var problems:

• Block-scoped — stays in the { } it was declared in
• Hoisted but NOT initialized — accessing before declaration throws ReferenceError (Temporal Dead Zone)
• Cannot be re-declared in the same scope

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100)
}
// Prints: 0, 1, 2 — each iteration has its own i

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100)
}
// Prints: 3, 3, 3 — all share the same i

This is the most important practical difference. let creates a fresh binding on every loop iteration. var has one binding shared across all iterations.

const — the immutable binding

const creates a binding that cannot be reassigned. Same scoping and TDZ as let.

const PI = 3.14159
PI = 3  // TypeError: Assignment to constant variable

const name = 'Alice'
name = 'Bob'  // TypeError

Critical nuance: const does NOT make objects immutable.

const user = { name: 'Alice', age: 30 }
user.name = 'Bob'    // ✓ — modifying a property is allowed
user.age = 31        // ✓ — still fine
user = { name: 'Charlie' }  // ✗ TypeError — can't reassign the binding

const arr = [1, 2, 3]
arr.push(4)     // ✓ — allowed, arr is still [1,2,3,4]
arr = [5, 6]    // ✗ TypeError — can't reassign

const says "this binding will always point to this object." It says nothing about what's inside the object. To make an object truly immutable, use Object.freeze().

The Temporal Dead Zone (TDZ)

Both let and const are hoisted but not initialized. The gap between the start of their scope and their declaration line is the TDZ. Accessing in the TDZ throws ReferenceError.

function example() {
  // TDZ for 'value' starts here
  console.log(value)  // ReferenceError: Cannot access 'value' before initialization
  let value = 42      // TDZ ends here
  console.log(value)  // 42
}

The TDZ exists by design — it catches the class of bugs that var's silent undefined was hiding.

When to use each — the practical rule

Use	When
const	Default. Use for everything that doesn't need to be reassigned.
let	When you know the value will change: loop counters, accumulated values, conditionally set variables.
var	Almost never in modern code. Only when intentionally targeting pre-ES6 environments without a transpiler.

Common patterns

// const for objects and arrays — you'll mutate contents, not rebind
const config = { debug: false, version: '2.0' }
const items = []
items.push('first')  // fine — not reassigning items

// let for values that change
let count = 0
for (let i = 0; i < 10; i++) {
  count += i
}

// const for functions (most common in modern JS)
const add = (a, b) => a + b
const fetchUser = async (id) => { /* ... */ }

// Destructuring — const is fine even though it "looks like" you're creating multiple
const { name, age } = user
const [first, ...rest] = array

var vs let in for loops — the deep reason

// With var — one variable, all closures share it
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0)
}
// Output: 3, 3, 3

// With let — new binding created per iteration
for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0)
}
// Output: 0, 1, 2

Why does let in a loop create a new binding each iteration? The spec mandates it: for each iteration of a for loop with let, a new lexical environment is created and the loop variable is re-bound. Each closure captures a different i. This is not magic — it's the spec explicitly designed to fix the var loop bug.