Question 1

What is hoisting in JavaScript?

Accepted Answer

Hoisting is the behavior where declarations are processed during the creation phase of an execution context before code runs, so bindings exist before their line in source. During context creation, the engine registers declarations: function declarations are initialized fully; var is registered and set to undefined; let/const/class are registered but left in the TDZ. People summarize this as 'declarations are moved to the top,' but nothing is rewritten — it is environment setup. Understanding hoisting prevents bugs with use-before-define and explains differences between declaration kinds.

Question 2

How does hoisting differ between function declarations and function expressions?

Accepted Answer

Function declarations are fully hoisted and callable before their line; function expressions only hoist the variable binding (var → undefined, let → TDZ). A function foo() {} declaration is instantiated during creation, so foo() works anywhere in that scope. A function expression like var foo = function() {} only hoists foo as undefined until the assignment runs — calling early throws TypeError. With const foo = () => {}, the binding is in TDZ until initialization — calling early throws ReferenceError. Named function expressions expose the name only inside the function for recursion/debugging.

Question 3

What is logged and why?

Accepted Answer

First log prints undefined; second throws ReferenceError due to TDZ on b. var a is created and initialized to undefined during the creation phase, so reading a before assignment yields undefined. let b is also created during creation but remains uninitialized until the let b = 2 line executes, so accessing b earlier is a TDZ ReferenceError. The first console.log does run; the second statement throws and stops further execution.

Question 4

Are ES6 classes hoisted? Can you use a class before its declaration?

Accepted Answer

Class declarations are hoisted into the scope but remain in the TDZ until initialized — using them early throws ReferenceError. Unlike function declarations, class Foo {} cannot be invoked before the declaration line even though the binding is registered. Until initialization, Foo is in the TDZ. Class expressions follow the same rules as other let/const bindings depending on how they are declared. Extending a class also requires the superclass to be already initialized. This design avoids partially-constructed constructors and matches let/const temporal semantics.

Question 5

In non-strict sloppy mode, what happens if two function declarations share the same name in one scope? How should a team prevent related bugs?

Accepted Answer

Later function declarations overwrite earlier ones during instantiation; enforce modules/strict mode and lint rules to ban duplicates. In a single function or global sloppy script, duplicate function declarations are allowed; the last one wins when declarations are instantiated. That can silently change behavior if two helpers share a name after a merge. Strict mode and ES modules still disallow some duplicate binding forms and make errors louder. At team level: use ESLint no-redeclare / no-func-assign, prefer const function expressions or exports with unique names, and keep one source of truth per symbol. Block-level function declaration rules also vary historically across browsers — another reason to avoid relying on them.

Hoisting JavaScript Interview Questions

Other JavaScript interview topics