What is the difference between var, let, and const? | Interview Question

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

01

Understand 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.

varletconst

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the 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-clo

Solution ready — 2 min read

Classified // press E to declassify

04

Run the code

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

Practice

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.