Every JavaScript developer preparing for interviews eventually memorizes the same canon: closures, the event loop, == versus ===, prototypes, var versus let. What far fewer candidates understand is why these questions survive year after year while frameworks come and go.
The answer is simple: each of these questions is a proxy. The interviewer is rarely testing whether you can recite a definition. They are testing whether you have debugged real code, because certain misunderstandings only get corrected by production pain. Here is what four of the most common JavaScript interview questions are really probing, and what separates a memorized answer from a convincing one.
"Explain closures" is really "have you ever debugged a stale value"
The textbook answer says a closure is a function that retains access to its lexical scope after the outer function has returned. Correct, and completely unconvincing on its own, because every candidate says exactly that.
What interviewers listen for is whether you can connect the concept to a failure mode. The classic one:
for (var i = 0; i < 3; i++) {
setTimeout(function () {
console.log(i);
}, 100);
}
// Prints: 3, 3, 3A candidate who merely memorized closures is often surprised by this output. A candidate who has debugged it explains it in one sentence: all three callbacks close over the same i, because var creates one function-scoped binding, and by the time the timers fire the loop has finished. Then they give the fix (let creates a fresh binding per iteration) and, ideally, mention that this exact pattern is why let behaves the way it does in for loops.
The follow-up that filters senior candidates: where else do closures hold onto memory? If you can talk about event listeners retaining large objects, or a memoization cache that never evicts, you have demonstrated production experience rather than tutorial knowledge.
"Explain the event loop" is really "will your code block the UI"
Nobody asks about the event loop because they need you to draw the diagram. They ask because the practical consequences show up constantly: a spinner that never renders, an API response handled out of expected order, a "why does this log before that" bug.
The minimum credible answer distinguishes the call stack, the task queue, and the microtask queue. The convincing answer predicts output:
console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
// Prints: 1, 4, 3, 2Microtasks (promise callbacks) drain completely before the next macrotask (the timeout), even at zero delay. If you can state that and then explain a consequence, for example that an infinite chain of resolved promises can starve rendering while a chain of setTimeout calls cannot, the interviewer stops probing. You have clearly been on the wrong end of this behavior before.
"== or ===?" is really "do you understand coercion or just fear it"
Every candidate knows to say "always use strict equality." That answer is table stakes and tells the interviewer nothing. The differentiating layer is being able to say what == actually does, because coercion does not disappear just because you avoid one operator. It lives in if conditions, template literals, and the + operator whether you like it or not.
A strong answer covers one or two concrete rules rather than hand-waving: null == undefined is true and neither equals anything else; a string compared to a number gets converted to a number first; and NaN equals nothing, including itself, which is why Number.isNaN() exists. Bonus credibility for knowing why Object.is(NaN, NaN) returns true while NaN === NaN returns false.
"How does prototypal inheritance work" is really "can you read code you did not write"
Almost no one hand-rolls prototype chains in application code anymore; class syntax has covered that since ES6. The question persists because the prototype chain is still how the language resolves every property access, and developers who do not understand it get lost the moment they step into a library, a polyfill, or a debugging session where class sugar is absent.
The convincing answer is short: property lookup walks the chain until it finds the name or hits null; class is syntax over the same mechanism; and methods defined in a class live on the prototype, shared across instances, rather than being copied onto each object. If you can explain why that last point matters for memory, and when an arrow function assigned as a class field breaks that sharing, you are answering like someone who has profiled an application.
The pattern behind the pattern
Notice what all four questions have in common. The definition is worth maybe twenty percent of the credit. The rest comes from predicting behavior of a code snippet, naming the bug the concept produces in the wild, and knowing the boundary cases where the simple rule bends.
That has a direct implication for how you should prepare. Passive reading produces definitions. What produces the other eighty percent is retrieval practice: seeing a question, forcing yourself to produce the full answer including the code behavior, and only then checking. This is exactly the mechanism spaced-repetition flashcards exploit, and it is why they work noticeably better for interview prep than rereading tutorials. If you want a ready-made set to drill against, IT Flashcards app maintains 170 JavaScript interview questions with answers, including code examples, covering everything discussed here plus the deeper cuts: WeakMap semantics, the Temporal Dead Zone, custom iterators, and event delegation.
However you drill, hold every answer you practice to the standard above. Can you state the definition, predict the snippet, and name the production bug? When all three come out fluently, the classic questions stop being a filter that catches you and start being the easiest part of the interview.
