Frontend interview answer

Predict var Hoisting and Function Shadowing

HighIntermediateJavascript

By FrontendAtlas Editorial · Updated Jul 17, 2026

Output challenge

The interactive answer choices load in your browser.

Interview focus

This JavaScript interview question tests whether you can explain JavaScript var hoisting output: local shadowing and undefined, connect it to production trade-offs, and handle common follow-up questions.

JavaScript var hoisting output: local shadowing and undefined explanation without falling back to memorized definitions
Hoisting and Scope reasoning, edge cases, and production failure modes
How you would answer the most likely JavaScript interview follow-up

Practice more JavaScript interview questions

Interview answer drill

Use this JavaScript interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice more JavaScript interview questions Follow JavaScript mastery study plan Open Essential 60

Deep dive

Trace the binding before the value

The output is undefined, 20, then 10. When show begins, JavaScript has already created a local value binding for the function because var declarations are function-scoped and hoisted. That local binding shadows the global value throughout the entire function body, including the lines above the written declaration.

Only the declaration is processed early; the assignment value = 20 remains where it appears. The local binding therefore contains undefined at the first console.log. After the assignment runs, the second log reads 20 from the same local binding. Returning from show removes that function activation. Nothing in the function assigned to the global binding, so the final log outside the function still reads the global 10. This is shadowing, not a temporary read of the global followed by its replacement.

JAVASCRIPT

// A useful mental model for the original function:
function show() {
  var value; // declaration is hoisted; initial value is undefined

  console.log(value);
  value = 20; // assignment stays in its original position
  console.log(value);
}

// The global `value` is a different binding.

Execution point	Binding selected	Value logged
First log inside show	Hoisted local value shadows the global, but has not been assigned 20 yet.	undefined
Second log inside show	The same local value now contains the assigned number.	20
Log after show returns	The script reads the untouched global value binding.	10

Name lookup selects the nearest binding first; execution order then determines the value currently stored in it.

Make shadowing visible or avoid it

Prefer const by default and let when reassignment is required. Their declarations are also scoped before execution reaches them, but reading them early throws a ReferenceError because they remain in the temporal dead zone instead of quietly producing undefined. That failure is usually easier to diagnose than an accidental var read.

Different names can make intent clearer as well: a local name such as nextValue shows that the function is not updating the global value. If shadowing is deliberate, keep the scope short and declare the local binding before its first use. The reliable debugging question is not merely "where is this assignment?" but "which lexical binding does this identifier resolve to here, and has that binding received a value yet?" That two-step check explains both the initial undefined and the unchanged global value.