Why are output questions asked?

They reveal whether you understand hoisting, closures, the event loop and coercion — not just syntax. They're quick and hard to fake.

How do I get better at them?

Learn the underlying models (creation phase, microtask/macrotask queues, coercion rules) rather than memorising answers.

'What does this print?' questions test whether you truly understand JavaScript. Here are the classics with the output and the reasoning.

With var, all callbacks read the final value (3 3 3) because there's one shared binding. let creates a fresh binding per iteration (0 1 2).

for (var i=0;i<3;i++) setTimeout(()=>console.log(i)); // 3 3 3
for (let j=0;j<3;j++) setTimeout(()=>console.log(j)); // 0 1 2

Sync runs first, then microtasks (promises), then macrotasks (setTimeout).

console.log(1);
setTimeout(()=>console.log(2));
Promise.resolve().then(()=>console.log(3));
console.log(4);
// 1 4 3 2

+ with a string concatenates ('12'), then - coerces to numbers (12 - 1) → 11. + prefers strings; every other operator prefers numbers.

typeof null is 'object' (a historic bug), typeof [] is 'object', typeof function(){} is 'function', typeof undeclaredVar is 'undefined'.

You can mutate a const object's properties but not reassign the binding — o.x = 2 is fine; o = {} throws. const locks the binding, not the value.

![] is false → [] == false → [] == 0 → '' == 0 → 0 == 0 → true. A perfect illustration of why == is dangerous.

Master every output trap

Hoisting, closures, event loop and coercion output questions — all explained with the reasoning in the JavaScript Interview Kit.

Why are output questions asked?: They reveal whether you understand hoisting, closures, the event loop and coercion — not just syntax. They're quick and hard to fake.
How do I get better at them?: Learn the underlying models (creation phase, microtask/macrotask queues, coercion rules) rather than memorising answers.