JavaScript interview questions

What a strong answer covers

• var is function-scoped and hoisted with an initial value of undefined; let and const are block-scoped ({ } bounded).
• let and const are hoisted too but not initialized, so accessing them before their declaration throws a ReferenceError. That gap is the temporal dead zone.
• const forbids reassignment of the binding, but the value can still be mutated (a const object's properties can change); it is not deep immutability.
• Practical guidance: default to const, use let when reassignment is needed, avoid var in new code.

Where people lose the point

• ×Claiming let and const are not hoisted at all, rather than hoisted-but-uninitialized.
• ×Saying const makes an object immutable instead of just preventing rebinding.
• ×Confusing block scope with function scope, e.g. expecting a var inside an if to be block-local.

What a strong answer covers

• A closure is a function bundled with references to the lexical scope in which it was defined, so it retains access to those variables even after the outer function returns.
• Useful cases: data privacy / module pattern (a counter with a private count), partial application / currying, and memoization caches.
• Classic bug: a for loop with var capturing the same shared binding, so all callbacks log the final value. Fixing it with let gives each iteration its own binding.
• Notes that closures keep referenced variables alive in memory, which can cause leaks if long-lived closures capture large objects.

Where people lose the point

• ×Describing a closure as just a nested function, missing that it captures and retains its enclosing scope.
• ×Not being able to explain why var breaks the loop while let fixes it (shared vs per-iteration binding).
• ×Overlooking the memory implication that captured variables cannot be garbage collected while the closure lives.

What a strong answer covers

• For regular functions `this` is set by the call site: method call binds to the object before the dot, plain call is undefined in strict mode (or the global object otherwise), new binds to the fresh instance.
• call, apply, and bind explicitly set `this`; bind returns a permanently bound copy.
• Arrow functions have no own `this`; they capture `this` lexically from the enclosing scope, which is why they are ideal for callbacks inside methods.
• A strong answer names the precedence order: new > explicit bind/call/apply > implicit method call > default.

Where people lose the point

• ×Saying `this` is determined by where a function is defined rather than how it is called (true only for arrow functions).
• ×Using an arrow function as an object method and expecting `this` to point at the object.
• ×Forgetting that a detached method (const f = obj.method) loses its implicit binding when called alone.

What a strong answer covers

• JavaScript is single-threaded with a call stack; the event loop runs queued work only when the stack is empty.
• Synchronous code runs first. Then the microtask queue (Promise .then/.catch, queueMicrotask, await continuations) is fully drained before any macrotask.
• setTimeout/setInterval callbacks are macrotasks and run after all pending microtasks, so a resolved Promise's .then fires before a setTimeout(0).
• The loop drains all microtasks after each macrotask, so a correct trace is: sync -> microtasks -> one macrotask -> its microtasks -> next macrotask.

Where people lose the point

• ×Treating setTimeout(fn, 0) as immediate and ordering it before Promise callbacks.
• ×Not distinguishing the microtask queue from the macrotask queue at all.
• ×Forgetting that await pauses the async function and schedules the rest as a microtask, changing ordering.

What a strong answer covers

• Kick off the promises before awaiting so they run concurrently, then await the combinator, rather than awaiting each in sequence.
• Promise.all resolves with an array of results once all succeed, but rejects immediately on the first rejection (fail-fast), discarding the other results.
• Promise.allSettled always resolves with a status/value-or-reason object per promise, so you can inspect partial success; use it when one failure should not sink the batch.
• Mentions Promise.race and Promise.any, and that async/await is syntactic sugar over promises so try/catch wraps awaited rejections.

Where people lose the point

• ×Awaiting promises one at a time in a loop and calling it parallel, when it is actually sequential.
• ×Reaching for Promise.all when partial failure must be tolerated (allSettled is the right tool).
• ×Forgetting that a rejected promise without a catch produces an unhandled rejection.

What a strong answer covers

• Every object has an internal link to a prototype object; property lookups walk this chain until found or until it reaches null.
• A function's prototype property becomes the [[Prototype]] of instances created with new, so shared methods live once on the prototype rather than per instance.
• ES6 class is syntactic sugar over this: methods go on Class.prototype, extends sets up the chain, and super calls the parent constructor.
• Distinguishes own properties from inherited ones (hasOwnProperty) and knows Object.create makes a new object with a chosen prototype.

Where people lose the point

• ×Believing JavaScript classes introduce classical inheritance rather than wrapping prototypes.
• ×Confusing the instance-facing __proto__ / [[Prototype]] with the function's prototype property.
• ×Assuming inherited properties show up as own properties, breaking for...in or hasOwnProperty reasoning.