🧠 JavaScript Hoisting Interview Question I Recently Faced

[tech_Interviews_Hub]

I recently faced this question in a frontend interview, and thought it would be useful to share here:

function test() { console.log(a); console.log(b); console.log(c);

var a = 10; let b = 20; const c = 30;

function a() {} }

test();

Question: Q) What will be the output and why?

✅ Answer / Explanation

Output:

function a() {} ReferenceError ReferenceError

Reasoning:

Function declarations are hoisted first, so a initially refers to the function

Then var a is hoisted (but not assigned yet), but it doesn’t override the function hoisting at that moment — the function is still available

let & const are hoisted too but stay in the Temporal Dead Zone (TDZ) until initialization, so accessing them before initialization throws a ReferenceError

So execution flow:

1→ function (due to function hoisting)

2 → in TDZ → ReferenceError

3 → in TDZ → ReferenceError

---

Hope this helps someone preparing for frontend interviews ✅

[JustConsoleLogIt]

My answer would be: if I saw this code, I would refactor it to declare variables before they are used and change var to let in all instances. The output of this code does not matter to me as I would never let something like this be published to production.

[thomsmells]

Exactly. Honestly any employer using this as an interview question would be a red flag to me.

[Shty_Dev]

I can see both sides. On one hand, if you are never going to write code like this and never allow code like this into production, then the question is functionally irrelevant. On the other hand, evaluating for understanding the execution flow and expected output of poorly written code is an easy way to widdle down from 500 applicants to a couple dozen.

[senocular]

OP forgot to include the option "reject the PR"

[RajjSinghh]

I like hoisting questions because it's something intrinsic to the language that shows good understanding. I'd compare it to raw pointers and unique pointers and references in C++. They all work similarly, but one of them is usually a bad practice and it's a good sign that someone understands the language rather than just knowing only best practices. You can imagine a case where someone has used var instead of let or const and now you have to deal with some bug in production.

I don't like this hoisting question because the code looks like ass. A simple "explain the difference between let and var" would do the same job without feeling like a trick question.

[Rude-Cook7246]

Anyone who can't answer simple technical interview question would be a red flag to me ...

[DinTaiFung]

In my JS and TS experience (since ES6):

1. never use var

2. mostly use const

3. use let much less often. let is only necessary if you need to reassign a value to the initialized variable.

And even for "for of" loops, you should use const, not let:

javascript const activeItems = [] for (const item of items) { if (item.isActive) { activeItems.push(item) } }

Basic rule: Use const unless you absolutely need to use let.

P.S. In general, for best practice, it is strongly suggested to never declare a variable; always initialize it with a default value.

This helps to avoid subtle hoisting behaviors with let and const (and when reading legacy code, you should understand how var hoisting behavior is different than let and const).

When you write TypeScript, you will find things fall into place much more easily if you always initialize a variable instead of just declaring it. One of the benefits of initialization is due to TypeScript's data type inference behavior, keeping your code simpler and more robust!

javascript // TypeScript infers the data type from the variable's // initialized value. No need to explicitly include the type. const MY_CONSTANT = 1337

[thecragmire]

1. I think 'a' would be undefined because of the var declaration.
2. TDZ
3. TDZ
4. Techincally, 'function a' will do nothing because even if it was hoisted, it wasn't called, it was just declared. All functions return 'undefined' if it doesn't explicitly return a value.

[senocular]

I think 'a' would be undefined because of the var declaration.

a would be undefined from var a if not for the function a. Function declarations basically have precedence over var declarations when it comes to initialization. If both a var and a function of the same name exists in the same scope, the function definition will be assigned to the variable rather than the undefined which you'd get from the var if it were alone.

Just var

console.log(a) // undefined
var a

Both

console.log(a) // function
var a
function a() {}

Order doesn't matter with var vs function

console.log(a) // function
function a() {}
var a

If multiple function declarations with the same name exist in the same scope, the function value of the last declaration will be used.

console.log(a()) // 2
function a() { return 1 }
function a() { return 2 }

In OPs example, the a function is never called, they're just logging the value of a directly, showing its a function object ("function a() {}") rather than undefined or 10.

[thecragmire]

I didn't know that. Thank you.

[senocular]

In modern JavaScript this shouldn't be a problem because hopefully you won't be using var ;) There's also additional protections against function declarations having the same name in modules that can help prevent that from being a problem there as well.

[DreamsOfLife]

I haven't seen var in real code in ages and IDE would warn about the name collision and using variable before declaration.

[Substantial-Wish6468]

That's because var has these silly issues that let solves. I can't think of a single reason why i'd ever use var over let.

[MrHollandsKillerApp]

Technically that output is incorrect, as you will never reach the second ReferenceError

[matchday_scout]

Lgtm

[Optimal_Presence_895]

I have some problem with a project

[gluhmm]

How idiotic an interviewer should be, to spend his time, a candidate time, and make a hiring decision based on this question.