The Output Questions (What Does This Log?)

"It is a capital mistake to theorize before one has data." — Arthur Conan Doyle, A Scandal in Bohemia

Somewhere in almost every JavaScript interview, the whiteboard clears and a small, innocent-looking snippet appears with one question underneath: what does this log? No API to memorise, no algorithm to invent — just five or six lines and a promise that they hide a trap. This is the interviewer's favourite move because it cannot be faked. You either understand how the language actually executes — hoisting, closures, this, coercion, the event loop — or you guess. This chapter opens Part VIII by turning the whole Volume into interview readiness: we collect the classic "what does this log?" puzzles and, for each, give the answer and the precise mechanical reason — cross-referenced back to the chapter that taught it.

Core Concepts

Output questions are diagnostic tools. Each one is engineered to fail if you hold a common misconception. Get the answer right for the wrong reason and a good interviewer will find you out with a follow-up. So the goal is never to memorise outputs — it is to see the machine. We will walk through six families of trap, and for each the rule that makes the output inevitable.

1. var in a loop with setTimeout

The most famous trap in the language. Predict the output, then run it:

Why (Part II — closures & scope). var is function-scoped: there is exactly one i shared by all three callbacks. The loop finishes — driving i to 3 — long before any setTimeout callback runs (they are deferred to a later tick). So all three closures read the same, now-final i. let is block-scoped: the loop creates a fresh binding of j per iteration, and each callback closes over its own copy — frozen at 0, 1, 2. The classic pre-let fix was an IIFE per iteration to manually capture the value; let bakes that fix into the language.

2. Hoisting and the Temporal Dead Zone

console.log(foo());   // "early!"  — function declarations are fully hoisted
function foo() { return "early!"; }

console.log(v);       // undefined — the *declaration* hoists, not the value
var v = 5;

console.log(x);       // ReferenceError: Cannot access 'x' before initialization
let x = 1;

Why (Part II — hoisting & the TDZ). All declarations are processed before any line runs. A function declaration is hoisted whole, so it is callable at the very top. A var is hoisted but initialised to undefined until its assignment line executes — hence reading it early yields undefined, not an error. A let/const is also hoisted, but into the Temporal Dead Zone: it exists yet cannot be touched until its declaration runs, so an early read throws ReferenceError. The TDZ is a feature — it turns a silent undefined bug into a loud crash.

3. this surprises

this is decided by how a function is called, not where it is defined — except for arrow functions, which have no this of their own. Run this:

Why (Part II — the this keyword). obj.regular() uses the call-site rule: the thing left of the dot becomes this, so this === obj. Assign the same function to a bare variable and call it, and there is no object left of a dot — this is undefined (strict) or the global object (sloppy), so this === obj is false. The arrow inside Box never gets its own this; it permanently captures the this that was in scope when it was created — the new instance — so detaching and re-calling it changes nothing. This is exactly why arrows are the right tool for callbacks that must remember their surrounding this.

4. Coercion traps

JavaScript's + operator is overloaded (concatenate or add) and == performs type coercion. That produces some legendary outputs:

Why (Part I — types & coercion). When either operand of + is a string, + concatenates; otherwise it adds. Objects and arrays reduce to primitives first via toString: [] becomes "", {} becomes "[object Object]". The - operator has no string mode, so it always coerces to number — which is why 1 + "2" - 1 swings from string back to number and lands on 11, not 2. And 0.1 + 0.2 is not a JavaScript quirk but an IEEE-754 one shared by nearly every language: those decimals are infinite in binary, so they round. Never compare floats with ===; compare within a small epsilon.

5. Event-loop ordering: sync, microtask, macrotask

The single most common async output question. Predict the order, then run it:

Why (Part III — the event loop). Synchronous code runs first, to completion — so A and D log immediately, in order. Then the loop drains the microtask queue (resolved promises) entirely before touching the macrotask queue (timers). So the promise callback C runs before the setTimeout callback B, even though setTimeout(…, 0) looks "immediate." The mantra: sync → all microtasks → one macrotask → all microtasks → …. setTimeout(0) does not mean "now"; it means "after the current work and every pending microtask."

Now the harder cousin — async/await ordering. await splits a function: everything after it becomes a microtask.

Why (Part III — async/await). An async function runs synchronously up to its first await — so 1 logs during the f() call. await then suspends f and queues its continuation as a microtask, returning control so 2 logs. The .then on line below queues its callback as a microtask too — but f's continuation was queued first, so 3 runs before 4. await is not magic; it is "wrap the rest of this function in .then."

6. Reference vs value

Why (Part I — primitives vs references). Objects are held by reference: b = a copies the reference, not the object, so both names address one object and a mutation through either is visible through the other — including through a function parameter, since arguments are the same references. Primitives (number, string, boolean, …) are held by value: reassigning the parameter n rebinds a local copy and cannot reach the caller's x. Note the subtlety: reassigning a parameter never affects the caller, but mutating an object a parameter points to does.

Common Mistakes

• Assuming setTimeout(fn, 0) runs "immediately." It runs after all synchronous code and every queued microtask. Promises always beat timers.
• Thinking let "fixes closures." Closures were never broken — let just gives each iteration its own binding to close over. Know the real mechanism, not the slogan.
• Reading this from where a function is written. For regular functions this is set at the call site. Only arrow functions use lexical this.
• Trusting ==. null == undefined is true, but 0 == "", [] == ![], and friends are minefields. Use === and coerce deliberately.
• Comparing floats with ===. 0.1 + 0.2 !== 0.3. Compare with an epsilon or work in integers (e.g. cents, not naira).
• Confusing reassignment with mutation. Reassigning a parameter never touches the caller; mutating the object it points to does.

Interview Corner

Chapter Summary

• Output questions test your mental model, not your memory — the goal is to see the machine, then narrate it.
• var in a loop shares one binding (all callbacks read the final value); let gives a fresh binding per iteration.
• var hoists to undefined; let/const hoist into the TDZ (early read throws); function declarations are callable early.
• this is set at the call site for regular functions; arrows capture lexical this and ignore the call site.
• + concatenates if either side is a string; -/*// always go numeric; 0.1 + 0.2 !== 0.3 (IEEE-754).
• Execution order is: all sync → all microtasks (promises, await continuations) → one macrotask (timers) → repeat.
• Objects pass by reference (mutations leak); primitives pass by value (reassignment doesn't).

Editorial reflection — the "what does this log?" question feels like a gotcha, and junior engineers resent it. But it is the most honest question in the interview: it cannot be bluffed, it rewards understanding over recall, and every trap in it is a real bug someone once shipped. You have now walked the whole Volume — types, scope, closures, this, the event loop — and these puzzles are simply those chapters wearing disguises. Learn to see through the disguise, narrate the mechanism out loud, and the finale of your interview becomes the easiest part.