JavaScript interview questions: can you run the interpreter in your head?

The six questions below aren't really six separate topics. JavaScript has no compiler standing between you and the runtime, so almost everything senior candidates get asked is a version of the same test: can you predict what actually happens when this code runs, not what you meant it to do.

Candidates who can hold that model in their head answer all six. Candidates who memorized definitions answer the first half and then start guessing. If you'd rather work through the topic than read about it, the JavaScript track covers the same ground one idea at a time.

Question 1: what logs first, the timeout or the promise?

This is one of the oldest tricks in a JavaScript round and it still works, because most people learn 'async code runs after sync code' as a slogan rather than as a mechanism with parts you can name.

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

// logs: 1, 4, 3, 2

Worth saying without being asked: await doesn't pause the language, it desugars to a .then. Every await point is a microtask boundary, which is why a loop full of sequential await calls runs one after another even though nothing looks blocking, and why wrapping independent calls in Promise.all instead of awaiting each in turn is the fix people reach for once they've actually seen the ordering.

Question 2: fix the loop that logs the wrong number three times

This one shows up as a live task almost as often as it shows up as a question, because writing the fix proves you understand the bug better than describing it does.

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// logs 3, 3, 3

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// logs 0, 1, 2

Question 3: why is this undefined inside the callback?

A method that works fine when you call it directly and breaks the moment it's passed as a reference. This is the bug that teaches people what this actually means, usually the hard way, the first time it happens in real code.

class Counter {
  count = 0;
  increment() { this.count++; }
}

const counter = new Counter();
button.addEventListener("click", counter.increment);
// this is undefined when the handler fires

this is set by how a function is called, not by where it's written. counter.increment() and counter.increment passed to addEventListener are the same function, but only the first one calls it as counter's method. The second hands the browser a bare function, and when the click fires, nothing about that call mentions counter, so this is undefined inside a class method (or the global object outside strict mode). The fix is binding in the constructor, wrapping the call in an arrow function, or writing increment as an arrow class field in the first place.

Question 4: what does the caller see after this function runs?

A function mutates something it was handed. The question is whether the person calling it knows that, and whether the candidate does.

function addItem(cart, item) {
  cart.items.push(item);
  return cart;
}

const original = { items: [] };
const result = addItem(original, "book");
result === original; // true, and original.items now has one item too

Primitives are copied on assignment or on a function call. Objects and arrays are not, what gets copied is the reference, so the function and the caller are looking at the same underlying structure the whole time. Anyone who's surprised by that has usually only ever seen it go wrong once it's three functions deep, which is exactly why interviewers ask it directly instead of waiting for it to come up.

Question 5: where does a class method actually live?

class reads as a different language feature from everything above it, and that's the point of the question: it isn't one. It compiles down to the same prototype chain that's been there since the beginning.

Every object has an internal link to another object it falls back to when a property lookup misses, and that chain keeps going until it hits null. A method defined in a class body lives once, on the prototype, shared by every instance, which is different from an arrow class field: those get copied per instance, as question 3 covered. Looking a method up on an instance walks the chain until it finds increment on Counter.prototype, and every instance sees the same function.

• extends wires one prototype's fallback to another, so a subclass instance's lookup chain runs through the child's methods, then the parent's, then Object.prototype.
• super.method() calls the parent's version explicitly, which you need the moment you override something but still want the original behavior inside the new one.
• Modifying a built-in prototype (adding a method to Array.prototype, say) changes every array in the program, including ones from libraries that never expected it, and collides with anything the spec adds under the same name later. It's a real technique and also a real way to make a codebase unpredictable.

Two that show up before the real questions start

• == vs ===. === skips coercion entirely. == runs a set of rules first, and a couple of the results surprise people who only use it by habit: null == undefined is true, but null == 0 is false, and NaN never equals anything, including itself, which is why you check for it with Number.isNaN rather than a comparison.
• Hoisting and the temporal dead zone. var, let, const and function declarations are all hoisted, but they don't behave the same once you're inside that hoisted space. var initializes to undefined immediately, so reading it early just gives you undefined. let and const are hoisted but sit in the temporal dead zone until their declaration line actually executes, and reading them before that throws a ReferenceError. That's deliberate: it catches use-before-initialization as an error instead of letting it silently return undefined.

The live task: write a debounce

Most rounds have one small keyboard moment, and for JavaScript it's usually this one, or throttle's sibling version of it. What's being scored isn't whether the syntax lands. It's the order you build it in.

1. Say the problem before touching the keyboard: a rapid-fire event is triggering expensive work on every call, and you want it to run once, after things go quiet.
2. Reach for a closure holding a single timer id. It's the same mechanism as question 2, and saying that out loud is a good sign, not a distraction.
3. Clear the pending timer on every call, then schedule a new one. That line is the whole mechanism. Throttle is the same shape with a boolean guard and a fixed interval instead of a reset.
4. Decide what happens to this and the arguments the wrapped function was called with. Forwarding them with apply, or a rest parameter and an arrow function, is what makes the debounced version actually interchangeable with the original.
5. Say which one fits which case. A search box wants debounce, since it's waiting for a pause. A scroll handler wants throttle, since it wants steady progress rather than silence followed by a burst.

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

The implementation is a few lines. The narration is the part that's hard to rehearse alone, because the follow-up is the interview, and the follow-up here is almost always how you'd add a leading-edge option or cancel a pending call.

Question 6: what's keeping this object alive?

A closing question that sounds abstract and isn't. Every long-lived JavaScript app leaks eventually, and the question is whether a candidate can point at where.

Garbage collection is reachability-based: an object is kept as long as something reachable from a root still points to it, and reclaimed once nothing does. Setting a variable to null doesn't free anything by itself, it just removes one path to the object, and if another reference exists elsewhere, nothing changes. The usual leaks in a real app are forgotten event listeners, timers that outlive what they were scheduled for, closures retaining a large object they only needed briefly, and DOM nodes removed from the page but still referenced from JavaScript, which keeps the whole detached subtree alive.