JavaScript Output-Based Interview Questions

How to answer an output question

Read the snippet and name the family before you predict anything. Almost every output question is deliberately built to test exactly one of the six above, and once you have identified which, you are applying a rule rather than simulating the whole program in your head. That is also what protects you when the interviewer changes one line and asks again.

Then say the answer and the rule together. "Three, three, three, because var has one binding for the whole function and all three callbacks read it after the loop finished" is a complete answer that pre-empts the follow-up. Just saying "3 3 3" invites it, and a correct answer with no reasoning behind it is worth surprisingly little, because the interviewer cannot tell it from a memorised one.

Hoisting and the temporal dead zone

Declarations are processed before any code runs. `var` bindings are created and initialised to undefined; `let` and `const` bindings are created but left uninitialised, so touching them throws. Function declarations are hoisted whole and callable before their line; function expressions are not.

The last one is the version interviewers actually use, because it looks like it should print 1. The inner `var x` is hoisted to the top of the function, which shadows the outer binding for the whole function body, so the read happens against a variable that exists but has not been assigned yet. Swap `var` for `let` and it throws instead, which is the follow-up.

Scope and closures

A closure captures a live reference to a binding, not a copy of its value. The whole family of loop questions reduces to counting how many bindings exist: one for the entire function with `var`, one per iteration with `let`.

The third snippet is the one to have ready, because it removes `setTimeout` entirely and proves the behaviour has nothing to do with asynchrony. The fourth is the reverse question, two independent closures, and it catches people who have over-learnt "closures share state" from the loop example without noticing that each invocation creates its own scope.

Event loop ordering

Synchronous code runs to completion first. Then the entire microtask queue drains, promise callbacks and `queueMicrotask`, and only then does one macrotask run, such as a timer. After each macrotask the microtask queue drains again.

The second snippet is where most people lose the mark. Calling an async function does not defer anything, the body executes immediately up to the first `await`, so "A" prints before "end". The third shows the rule that follows from it: the microtask queue is emptied between every pair of macrotasks, not just once at the start.

this binding

In a normal function, `this` is whatever precedes the dot at the call site, nothing else. Detaching a method loses it. Arrow functions have no `this` of their own and use the enclosing scope's, which fixes callbacks and breaks methods.

The last snippet is the one that produces the most wrong answers, because the inner function is written inside a method and people assume it inherits from it. It does not - `inner()` is a plain call with nothing before the dot, so it gets the default binding. Making `inner` an arrow function is the fix, and being able to say why in one sentence is the whole point of the question.

Coercion and equality

`+` prefers string concatenation whenever either operand is a string; every other arithmetic operator forces both sides to numbers. `==` converts before comparing, following rules that produce results almost nobody predicts, which is exactly why these appear in interviews.

The `1 + 2 + "3"` versus `"1" + 2 + 3` pair is worth memorising as a unit, because it demonstrates the only thing that actually matters here: operators evaluate left to right, so where the string appears changes everything. And the right way to close any of these is to say you would use `===` and never write code that depends on the coercion rules.

References, copies and object keys

Objects are held by reference, `const` locks the binding rather than the value, and spreading copies only the top level. Together those three facts generate a large share of output questions and an even larger share of real bugs.

The shallow-freeze result surprises almost everyone, and it is the same rule as the shallow spread one line above. If the follow-up asks how to fix it, the answer is a recursive freeze or a deep clone with `structuredClone`, and noting that both are shallow for the same reason ties the whole section together.

Array traps

Arrays are objects with a length, which explains most of what looks strange about them: holes are missing properties rather than undefined values, `delete` does not shorten anything, and the default sort compares strings.

`[1, 2, 3].map(parseInt)` is the single most-asked array output question and the one people most often get wrong for the wrong reason. It is not about `parseInt` being strange, it is that `map` passes three arguments and `parseInt` accepts two, so the index arrives as the radix. `map(Number)` gives the expected result because `Number` takes only one argument.

Prototypes, classes and error handling

A smaller family, but it appears at product companies. The two rules that generate most of it: properties are looked up along the prototype chain, and `finally` runs even when the `try` block returns.

The shadowing example is worth dwelling on, because it explains something people find arbitrary. Assigning to `a.greet` creates an own property on the instance, which is found first during lookup and therefore hides the prototype's version, but it does not replace it, so a new instance still gets the original. That is the whole prototype chain in one snippet, and it is the reason methods defined in a class are shared while instance fields are not.

The `finally` pair is the other one to have ready. `finally` always runs before the function actually hands back a value, so the log appears before the returned string, and a `return` inside `finally` replaces whatever `try` was about to return, silently discarding it. It is legal and it is always a bug, which is why linters flag it and interviewers like it.

Numbers, strings and a few one-liners

A last group that does not fit the six families cleanly but shows up often enough to prepare. Most of it comes from two facts: every number is a 64-bit float, and strings are indexed by UTF-16 code unit rather than by character.

The string length results are the genuinely useful ones here, because they affect real products rather than just interviews. A character counter built on `.length` miscounts every emoji and most Indic script, so a 280-character limit rejects text a user can see is shorter. Spreading the string or using `Intl.Segmenter` counts what a reader would call characters, and mentioning that turns a trivia answer into a product observation, which is a considerably better note to end an output round on.

How to practise these properly

Cover the output before you read it, write your prediction down, then run the snippet. The writing matters - an answer you thought about is easy to convince yourself you knew once you have seen the right one, and that self-deception is why reading lists of these does almost nothing. Ten snippets predicted in writing are worth more than a hundred read.

Run them somewhere the output is honest. A browser console is fine for most of these, but be aware that it evaluates each entry as an expression rather than a statement, which is exactly why `{} + []` behaves differently there than at the top of a script. Node, or a snippet inside a real file, avoids that distinction. And when a result surprises you, change one line and predict again, flipping `var` to `let`, or moving a `console.log` above an `await`, is how you check that you learnt the rule rather than the sentence.

When you are wrong, do not note the answer. Identify which of the six families you misread, then go and re-read that model properly, the companion page on tricky JavaScript questions linked below explains each one. A model handles snippets you have never seen; a memorised answer handles exactly one snippet and collapses the moment the interviewer changes a line, which they will, because that is how they check.