Hoisting

Running a script happens in two phases, and every hoisting question lives in the gap between them.

Hoisting is just phase 1 being invisible. The declarations already exist by the time line 1 executes — only the values wait their turn.

The keyword decides what phase 1 leaves behind:

Read that last row twice — it's the interview question. The variable hoists as a var; the function on the right is just a value, and values are assigned in phase 2.

greet();            // ✅ "hello" — the whole function exists already

function greet() {
  console.log('hello');
}

Output:

hello

Now the same code with an expression:

greet();            // 💥 TypeError: greet is not a function

var greet = function () {
  console.log('hello');
};

The error message is the tell. greet exists — that's why it isn't a ReferenceError — it's just undefined, and you tried to call undefined.

Swap var for const and the message changes again, to Cannot access 'greet' before initialization. Three keywords, three different failures, one shape of code.

console.log(typeof declaration);   // ?
console.log(typeof expression);    // ?
console.log(hoistedVar);           // ?

function declaration() {}
var expression = function () {};
var hoistedVar = 'assigned later';

Output:

function
undefined
undefined

When a var and a function declaration share a name, the function wins during creation — and execution can still overwrite it afterwards:

console.log(typeof thing);   // "function"  ← the declaration won phase 1

var thing = 'a string';

console.log(typeof thing);   // "string"    ← phase 2 reassigned it

function thing() {}          // declared last, available first

Two declarations of the same name with let would simply be a SyntaxError. That's the better outcome, and the reason this whole category of confusion is a legacy problem.

{ function blocked() {} }
blocked();   // 💥 ReferenceError in a module

Each function gets its own creation phase, so a variable declared inside one is registered there and nowhere else:

var value = 'outer';

function show() {
  console.log(value);   // undefined — not 'outer'
  var value = 'inner';
}

show();

Output:

undefined

This catches almost everyone. show has its own value, registered during its creation phase, so the lookup never reaches the outer scope. The declaration shadows the outer one for the entire function, including the lines above it.

Q1. What is hoisting?

The engine registers every declaration in a scope before executing any of it, so the bindings exist from the first line even though assignments haven't happened yet.

I'd avoid "moved to the top" — nothing moves, and that description can't explain why let throws instead of giving undefined.

Q2. Are let and const hoisted?

Yes, and the Temporal Dead Zone is the evidence. If they weren't registered, reading one early would say x is not defined. Instead you get Cannot access 'x' before initialization, which means the engine already knows about the binding — it just has no value yet.

Q3. Why can you call a function declaration before it appears?

Because a declaration is initialised with the whole function during the creation phase, not with undefined. It's the only form that's fully usable before its line.

A function expression isn't — the variable hoists under its own keyword's rules and the function is just a value assigned later.

Q4. What error do you get calling a hoisted var function expression, and why that one?

TypeError: x is not a function, not a ReferenceError. The variable exists and holds undefined, and calling undefined is a type error. The difference in message is a reliable way to tell which mistake you actually made.

Q5. What happens when a var and a function declaration share a name?

The function declaration wins the creation phase, so typeof reports function before either line runs. Execution can then reassign it like any variable. With let it would be a SyntaxError — a duplicate declaration in the same scope.

Senior follow-up: Why does a function log undefined for a variable that has a value outside it?

Because the inner var is registered in that function's own scope during its creation phase, so it shadows the outer one for the entire body — including the lines above the declaration. The lookup finds the local binding immediately and never walks the chain.

It's the strongest argument for let: same code, immediate error instead of a plausible-looking undefined.

✅ Declare before you use. Hoisting is a fact to understand, not a feature to rely on

✅ Use const and let — the TDZ turns this whole class of bug into an instant error

✅ Prefer const fn = () => {} over function declarations if you want consistent rules

❌ Don't declare functions inside if blocks — assign a const instead

❌ Don't reuse a name across a var and a function declaration

Predict every line before running.

console.log(a);
console.log(typeof b);
console.log(typeof c);

var a = 1;
function b() {}
var c = function () {};

undefined
function
undefined

Now the harder one:

var name = 'outer';

function print() {
  console.log(name);
  var name = 'inner';
}

print();

Write a short snippet that produces, in this order:

1. A value printed as undefined because of var hoisting
2. A successful call to a function declared below the call
3. A TypeError from calling a function expression too early

Then rewrite all three with const and explain what each failure becomes.

Lesson 4 — The Temporal Dead Zone. The window where a variable exists but can't be read, why the language designers chose an error over undefined, and the one place typeof stops being safe.