JavaScript Interview Questions and Answers

How the JavaScript round is actually structured

In most Indian product companies and funded startups the JavaScript round comes first, lasts 45 to 60 minutes, and has three parts: rapid-fire fundamentals for the first fifteen minutes, then a few output-prediction snippets, then one small implementation such as debounce or a Promise.all polyfill. Service companies usually stop after the first part. Knowing that shape matters, because it tells you that fundamentals are the gate, you do not reach the implementation if the first fifteen minutes go badly.

The other thing worth knowing is that the question list is remarkably stable. Closures, `this`, the event loop, hoisting and equality account for the large majority of what gets asked, and they have for a decade. That is good news: this is a finite syllabus, and the way to clear it is not to memorise fifty answers but to understand six models well enough to derive an answer to a question you have not seen.

What is the difference between var, let and const?

`var` is function-scoped and hoisted with an initial value of undefined, so reading it before its line gives undefined rather than an error. `let` and `const` are block-scoped and hoisted into a temporal dead zone, so reading them early throws a ReferenceError. `const` prevents reassignment of the binding, it does not freeze the value.

The practical rule to state: default to `const`, use `let` only where you genuinely reassign, and never use `var` in new code. The follow-up is usually the loop question, a `var` loop with setTimeout printing 3 3 3 while `let` prints 0 1 2, because `let` creates a fresh binding per iteration while `var` has only one for the whole function.

What is a closure?

A function together with the variables from the scope in which it was defined, kept alive after that scope has returned. The word to be careful with is "copy", a closure holds a live reference, not a snapshot, which is exactly why the loop question behaves as it does and why two closures over the same variable see each other's changes.

Two additions turn a textbook answer into a strong one. Name a real use - module privacy, `debounce` holding its timer, `memoize` holding its cache, a React `useState` closure capturing a stale value. And name the cost: a closure keeps its entire enclosing scope reachable, so a long-lived callback that closes over a large object prevents it being collected. Very few candidates mention the second one.

How is the value of this determined?

By how the function is called, not where it was written, with arrow functions as the deliberate exception. There are four rules and they apply in priority order: `new` binding, then explicit binding with call, apply or bind, then implicit binding from the object before the dot, then the default, which is undefined in strict mode and modules.

The complete answer includes the reverse case, because it is what interviewers use to check whether you understand arrows or just prefer them. An arrow function is correct as a callback inside a method, where you want the enclosing `this`. It is wrong as the method itself, where it captures the module scope and never sees the object at all.

Explain the event loop

JavaScript runs on a single thread with one call stack, so nothing else executes while your code is running. Asynchronous work is handed to the host, the browser or Node, and when it finishes, the callback is queued. Once the stack is empty, the event loop takes work from those queues, and the order in which it does so is what the question is really about.

There are two queues. Microtasks, which is promise callbacks and `queueMicrotask`, are drained completely after the current synchronous work finishes. Macrotasks - timers, I/O, event handlers, are taken one at a time, and the entire microtask queue is drained again after each. That is why a `.then` always runs before a `setTimeout(fn, 0)` scheduled earlier, and why an infinite chain of microtasks freezes the tab: rendering is a macrotask and never gets a turn.

Line D is the one that separates real understanding from a memorised rule. Calling an async function does not defer anything: the body runs immediately up to the first `await`, and only the continuation is queued. If you can say that unprompted, most output-prediction questions become straightforward.

What is the difference between == and ===?

`===` compares type and value with no conversion. `==` converts the operands to a common type first, following a set of rules that produce results almost nobody predicts reliably. The correct professional answer is to use `===` everywhere, with one deliberate exception.

The `"" == "0"` line is worth pointing out because it proves `==` is not transitive, 0 equals both, but they do not equal each other, which is a much better argument than "it is confusing". And `x == null` as a deliberate null-or-undefined check is worth naming, because it shows you are choosing `===` rather than following a rule you cannot justify.

What is the prototype chain?

Every object has a hidden link to another object, its prototype. When you read a property that the object does not have, the engine follows that link, and the next, until it finds the property or reaches null. That chain is how inheritance works in JavaScript, and `class` is syntax over it rather than a different system underneath.

The last line is the answer to "why does this matter". Methods live once on the prototype and every instance shares them, so creating ten thousand objects does not create ten thousand copies of each function. Arrow-function class fields, by contrast, are per-instance, which is the trade-off behind the common React advice about defining handlers inside a class.

How do promises and async/await work?

A promise is an object representing a value that is not ready yet, in one of three states, pending, fulfilled or rejected, and it settles exactly once. `async`/`await` is syntax over the same machinery: an async function always returns a promise, and `await` pauses the function until the awaited promise settles, without blocking the thread.

Awaiting in a loop when the requests are independent is the single most common performance mistake in real code, and interviewers ask about it precisely because it looks correct. Naming `Promise.all` for independent work and sequential awaits only for genuine dependencies is what they are listening for.

Is JavaScript pass by value or pass by reference?

Always pass by value - but for objects, the value being passed is a reference. That is why mutating a parameter's properties is visible to the caller while reassigning the parameter itself is not. Being able to state it in that one sentence is unusual enough to be worth practising.

The default-parameter line at the end is a useful thing to have ready, because interviewers who have worked in Python often ask it as a trap. In JavaScript a default parameter expression is evaluated afresh on every call that omits the argument, so a default empty array is a new array each time and never accumulates across calls. That is the opposite of Python's famous mutable-default behaviour, and knowing the difference reads as genuine cross-language experience rather than revision.

The same rule explains the one about copying. Spreading an object into a new one copies the top level only, so nested objects are still shared between the copy and the original, a shallow copy. That is why updating nested React state needs a spread at every level that changed, and why `structuredClone` exists for the cases where you genuinely need the whole tree duplicated.

How should you prepare in the last week?

Work backwards from the round structure. Spend the first two days on the six models above until you can explain each in three sentences without notes, because that is the gate. Spend two days on output prediction, write the answer down before running it, and when you are wrong, identify which model you misread rather than memorising the case. Spend the last two days implementing the standard utilities from a blank file, timed.

What not to do: read a list of fifty questions and their answers the night before. It feels productive and it fails on the first follow-up, because every one of these questions has a "why" behind it and a list gives you only the "what". If you have one evening left, pick closures, `this` and the event loop, and go deep on those three, they generate more interview questions than everything else combined.