What is the difference between var, let, and const?

Q: What is the difference between var, let, and const?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every scoping and TDZ claim below was actually run in Node — including the classic loop-closure bug. ## 1. Why This Even Matters — A Story First Imagine a shared office whiteboard (`var`) versus a sticky note stuck to one specific desk (`let`/`const`). Anyone in the whole office can read and overwrite the whiteboard from any room — that is `var`'s function-wide reach. A sticky note only exists at its own desk; step outside that desk's cubicle and the note is gone — that is `let`/`const`'s block scope. This difference is exactly what causes the classic loop-callback bug below. ## 2. The Core Idea 📌 **Interview term:** `var` is function-scoped and hoisted-with-`undefined`. `let`/`const` are block-scoped and hoisted-into-a-TDZ (uninitialized until their line

The problem

Question presented to candidate: "What's the actual difference between var, let, and const — not just 'let is block-scoped' — and can you show me a real bug that happens if you use var inside a loop with a callback?"

What a strong answer should cover:

📌 Interview term: function scope (var) — a var declared anywhere inside a function is accessible throughout the entire function, ignoring block boundaries like if or for. Verified directly: a var declared inside an if block is still readable after the block ends.
📌 Interview term: block scope (let/const) — a let/const is only accessible within the nearest enclosing block ({}). Verified directly: accessing it outside the block throws a real ReferenceError.
📌 Interview term: the Temporal Dead Zone (TDZ) — let/const are hoisted to the top of their scope like var, but remain uninitialized until their declaration line executes; accessing them before that point throws a real ReferenceError ("Cannot access before initialization"), distinct from var, which is hoisted AND initialized to undefined — verified directly, a real, observable difference.
📌 Interview term: the classic var-in-loop-closure bug — verified directly with real setTimeout callbacks: a for (var i ...) loop's callbacks all see the SAME final value of i (because var has one shared binding for the whole loop), while for (let i ...) gives each callback its OWN per-iteration binding, seeing the value at the time of its own iteration.
A precise answer names that const prevents reassignment of the binding, not mutation of the value — verified directly: reassigning a const throws, but mutating a const-bound object's properties succeeds fine.

Clarifying questions expected:

None — this is a definitional/comparison question; producing the real closure bug live is the strongest possible signal.

Code / implementation expected: Yes — reproducing the var-vs-let loop-closure bug with real setTimeout callbacks is the single most convincing demonstration of genuine understanding.

var
let
const

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every scoping and TDZ claim below was actually run in Node — including the classic loop-closure bug.

1. Why This Even Matters — A Story First

Imagine a shared office whiteboard (var) versus a sticky note stuck to one specific desk (let/const). Anyone in the whole office can read and overwrite the whiteboard from any room — that is var's function-wide reach. A sticky note only exists at its own desk; step outside that desk's cubicle and the note is gone — that is let/const's block scope. This difference is exactly what causes the classic loop-callback bug below.

2. The Core Idea

📌 Interview term: var is function-scoped and hoisted-with-undefined.

The solution is hidden so you can try first

6 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal scope, TDZ, and the classic var-vs-let loop-closure bug reproduced with setTimeout