JavaScript Interview Questions for AI Training Work

JavaScript runs on a single thread with a call stack, a microtask queue, and a macrotask queue. Promise callbacks go into the microtask queue, which is fully drained after the current synchronous code finishes and before the next macrotask runs. `setTimeout` callbacks go into the macrotask queue, so even with a 0ms delay, a `Promise.resolve().then()` callback always runs before it once the current script finishes executing.

A closure is a function that retains access to variables from its enclosing scope even after that outer function has returned. A practical use is a counter factory: a function that declares a local `count` variable and returns an inner function that increments and returns it, giving each call to the factory its own private, persistent counter without exposing `count` as a global or object property.

`===` compares value and type without conversion, so `1 === '1'` is false. `==` performs type coercion first, which produces surprising results like `0 == false` and `'' == 0` both being true. Style guides recommend `===` because coercion rules are easy to misremember, and a bug caused by unexpected coercion is harder to spot than one caught immediately by a strict comparison.

Every JavaScript object has an internal link to a prototype object, and property lookups walk up that prototype chain until they find a match or reach `null`. Unlike classical inheritance, where a class is a blueprint instantiated into objects, prototypal inheritance means objects inherit directly from other objects, and `class` syntax in modern JavaScript is syntactic sugar over this same prototype chain rather than a separate mechanism.

`undefined` is what JavaScript assigns automatically: an uninitialized variable, a missing function argument, or a property that doesn't exist on an object. `null` is an intentional absence of value that a developer assigns explicitly to signal "no value here on purpose." The distinction matters in APIs, where returning `null` versus `undefined` can carry different meaning to the caller.

If the loop uses `var`, there's a single shared binding for the loop variable across all iterations, so by the time any click handler fires, the loop has finished and the variable holds its final value. Switching the loop variable to `let` creates a new binding scoped to each iteration, so each closure captures its own value instead of sharing one.

Sequential awaits mean each call waits for the previous one to finish even though they're independent, so total time is the sum of all three. Wrapping them in `Promise.all([...])` kicks off all three requests concurrently and resolves once they've all completed, so total time drops to roughly the slowest single call instead of the sum.

I'd take heap snapshots in the browser DevTools at two points in time, after some interaction that shouldn't retain memory, and diff them to see what's growing. Common causes are event listeners never removed on unmounted components, closures holding references to large objects longer than needed, or a global cache that grows without an eviction policy. I'd confirm the specific retainer in the snapshot before changing code, rather than guessing.

I once had a filter that silently dropped rows where a numeric field was `0`, because the code used `if (value)` as a truthiness check and `0` is falsy just like an actual missing value. It looked like a data problem at first. Switching to an explicit `value !== null && value !== undefined` check fixed it, and I started treating truthiness checks on numeric fields as a specific thing to double-check in review.

I used the analogy of ordering food: a synchronous call is like standing at the counter until your order is ready, blocking everything else. An async call is like getting a buzzer and going back to your table, free to do other things until it goes off. Grounding the explanation in something outside the code made the callback-versus-await distinction click faster than walking through syntax first.