Top 30 JavaScript Interview Questions, Actually Explained (2026)

This is the capstone of the JavaScript fundamentals series, not a standalone cram sheet — every question below is answered in full, with the mechanism, in an earlier post in this series. This is the condensed version an interviewer would actually respect: the reasoning, not a memorized line.

Language mechanics

• What's the difference between let, const, and var? — Block scope vs function scope, and the temporal dead zone. Full breakdown in the scoping post.
• What is a closure? — A function that retains access to its outer scope's variables after that scope has returned. The debounce example in the closures post is the real-world proof, not the toy counter.
• Explain event delegation. — Attach one listener to a parent and read event.target, instead of one listener per child — works because events bubble up the DOM tree by default.
• What is the event loop? — The mechanism that lets a single-threaded language handle async work: call stack runs first, then the microtask queue fully drains, then one macrotask runs. Full breakdown with the exact console.log ordering in the event-loop post.
• Explain prototypal inheritance. — Objects link directly to other objects via a prototype chain; class is syntax over the same mechanism, not a different one.

Async

• What's the difference between a Promise and async/await? — async/await is syntax on top of Promises for readability; both go through the same microtask mechanism underneath.
• How do you run multiple async operations in parallel? — Promise.all() for "all must succeed," Promise.allSettled() when partial failure is acceptable and you need every result.
• What happens if you don't catch a rejected Promise? — An unhandled rejection — logged as a warning in Node, and a silent failure in the browser unless you attach a window listener for it.

Type system quirks (asked to check depth, not trivia)

• Why does typeof null === 'object'? — A bug from JavaScript's original 1995 implementation, kept for backward compatibility ever since — the honest answer is "legacy bug," not a design choice.
• Explain == vs ===. — == coerces types before comparing; === never does. Default to ===; the one legitimate == is x == null to catch both null and undefined at once.
• Why is NaN !== NaN? — Per the IEEE 754 float spec, NaN is defined not to equal itself. Use Number.isNaN(), never ===, to check for it.

What actually separates a strong answer from a memorized one

Anyone can memorize "closures are functions that remember their scope." A strong answer explains why that property is exactly what makes a debounce function or a React hook possible — the mechanism connected to a reason it exists, not a fact recited in isolation. That's the difference this whole series is built around.