Tricky JavaScript Interview Questions

How to answer a trick question without memorising it

Trick questions have a shape. Almost every one of them sits on top of one of five models, IEEE-754 floating point, type coercion, the event loop, closures and scope, or this-binding, and once you can name the model, the answer falls out of it instead of out of recall. That matters more than it sounds, because interviewers very rarely stop at the answer. They ask why, and a memorised answer has nowhere to go from there.

So the move in the room is always the same three sentences: give the answer, name the model, then give the practical consequence. "False. Both operands are 64-bit doubles and 0.1 has no exact binary representation, so in real code I'd compare within an epsilon, or store money in paise as integers." That is the whole answer, it takes ten seconds, and it demonstrates considerably more than the question asked for.

Why is 0.1 + 0.2 not equal to 0.3?

Every number in JavaScript is a 64-bit IEEE-754 double, including the ones that look like integers. Binary fractions can only represent sums of powers of two, and 0.1 is not one, it is a repeating fraction in binary, exactly the way one third is in decimal. It gets rounded on the way in, the rounding errors add up, and the result is a hair above 0.3.

The follow-up almost every interviewer asks is what you would do about it in a real application, and the answer they want is about money. Never store currency as a float, store paise, or cents, as integers and divide only at the point of display. Say that and the question is finished; stop at "binary can't represent 0.1" and you have answered a computer-science question rather than an engineering one.

Why is NaN not equal to itself?

NaN means the result of a numeric operation that has no numeric answer, and two operations that both failed have not necessarily failed in the same way, so the IEEE-754 spec defines every comparison involving NaN as false, including equality with itself. It is the only value in the language with that property, which makes it a neat identity test and a genuine nuisance in array methods.

The `indexOf` versus `includes` pair is the part worth volunteering, because it is the only place the distinction bites in day-to-day code. It also gives you the vocabulary the interviewer is listening for: `includes` uses SameValueZero, which treats NaN as equal to NaN but still treats +0 and -0 as the same, while `Object.is` separates those two as well.

Why does typeof null return "object"?

Because of a bug in the very first JavaScript implementation that can no longer be fixed. Values were tagged with a small type tag in their low bits, objects used the tag 000, and the null pointer was all zeros, so it read as an object. Correcting it in ES4 was proposed and rejected because it would silently break code across the web.

The genuinely useful half of this answer is that `typeof` is safe on an undeclared identifier where a bare reference would throw a ReferenceError, which is why old feature-detection code is written that way. Mentioning that turns a piece of trivia into something you have clearly used.

What do closures in a loop actually print?

This is the most-asked closure question there is, and the answer is 3 3 3 rather than 0 1 2 when the loop variable is declared with `var`. There is one binding of `i` for the entire function, every deferred callback closes over that same binding, and by the time any of them run the loop has finished and left `i` at 3.

The last example is the follow-up to have ready, because it removes `setTimeout` entirely and proves the problem was never about timers. If you can say "this has nothing to do with asynchrony, it is about how many bindings exist", you have answered the question and the follow-up in one move. The per-iteration binding that `let` creates is specified behaviour, not an optimisation, and the loop's update expression copies the value forward into each new binding.

Why does a promise always beat setTimeout(0)?

Because they queue in different places. Promise callbacks are microtasks and timer callbacks are macrotasks, and the event loop drains the entire microtask queue after the current synchronous work finishes but before it takes a single macrotask. A zero-millisecond timeout is not immediate; it is "after everything already waiting, and after every microtask those produce".

The line that catches people is number five. An async function is not deferred when you call it, its body runs synchronously right up to the first `await`, and only the continuation after the await becomes a microtask. Getting that one right is what separates a candidate who has learnt "promises before timeouts" from one who understands where the boundary actually is.

Why do [] + {} and {} + [] give different answers?

This one is not about coercion at all, which is why it catches people who understand coercion perfectly well. It is about parsing. At the start of a statement, a leading brace is read as a block, not an object literal, so `{} + []` is an empty block followed by unary plus applied to an empty array, which is 0.

The right way to close this answer is to say that you would never write any of it, and that the rule worth carrying is narrower and genuinely useful: `+` is the only arithmetic operator that prefers string concatenation when either side is a string, and every other operator coerces to number. That single sentence explains `1 + "2"` giving "12" while `1 - "2"` gives -1, which is the version of this question that shows up in real bugs.

Why does [1, 10, 9].sort() come out in the wrong order?

Because the default sort converts every element to a string and compares those, so "10" sorts before "9" for the same reason "apple" sorts before "banana". It surprises people badly because the array in the example is already almost sorted, so the bug looks intermittent.

Two things earn extra credit here. The first is naming the mutation, `sort` sorts in place and returns the same array reference, which is why sorting a prop in React can mutate state and produce a component that will not re-render. The second is `toSorted`, along with `toReversed`, `toSpliced` and `with`, the ES2023 non-mutating pairs that exist precisely because of that class of bug.

Why is `this` undefined inside my callback?

Because in a normal function `this` is decided by how the function is called, not where it was written. Pull a method off its object and pass it as a callback and the receiver is gone, in a module or in strict mode, `this` becomes undefined rather than the global object, which is why the error is usually a TypeError about reading a property of undefined.

The half of this question people forget is the reverse trap: an arrow function as an object method is almost always wrong, because it captures `this` from where it was defined rather than from the call. Arrows are the right choice inside a method, a callback in a `map` or a `setTimeout` that needs the enclosing `this`, and the wrong choice as the method itself. Being able to state both directions is what makes the answer complete.

What is the temporal dead zone?

The window between the top of a block and the line where a `let` or `const` is declared. The binding is hoisted - the engine knows it exists, but it is uninitialised, and touching it throws a ReferenceError. This is the precise reason "let and const are not hoisted" is a wrong answer that sounds right.

The shadowing example is the version that appears in interviews, because it looks like it should read the outer variable and instead throws. And the `const` distinction at the end is worth adding unprompted: `const` freezes the binding, not the value, so a const object is fully mutable and only reassignment is blocked. `Object.freeze` is the shallow answer to that follow-up.

Why do object keys collapse to [object Object]?

Because a plain object can only have string or symbol keys. Use an object as a key and it is stringified first, and almost every object stringifies to the same thing, so two different objects overwrite each other in a cache that looked correct in testing with primitive keys.

This is the practical one on the list, it turns up in real memoisation code, which is why it pairs naturally with the memoize question in a coding round. The full answer names the fix and its cost: `Map` compares keys by reference and holds them strongly, so a long-lived Map of DOM nodes or component instances is a memory leak. `WeakMap` is the version that lets the garbage collector reclaim the key.