JavaScript Developer Interview Questions for AI Training Work

A closure lets a function retain access to variables from its enclosing scope even after that scope has finished executing. I've used it most often for creating private state, like a counter that can only be modified through specific returned functions rather than being directly accessible.

var is function-scoped and hoisted with an initial value of undefined, while let and const are block-scoped and exist in a temporal dead zone until declared. I've seen bugs from var leaking a loop variable outside the intended block, which let fixes by default since each iteration gets its own binding.

I use event delegation when dealing with a dynamic list of elements, like rows that get added or removed, since attaching a listener to a shared parent avoids having to reattach listeners every time the list changes. For a small, static set of elements, direct listeners are simpler and clearer.

I add explicit logging with timestamps around each async operation to see the actual execution order rather than assuming it based on the code's written order, since async execution order is often not what it looks like on the page. Once I see the actual sequence, I fix it with proper awaiting or a lock mechanism rather than a timing-based workaround.

I remove listeners explicitly when a component or element is destroyed, matching every addEventListener with a corresponding removeEventListener, rather than assuming garbage collection will handle it. Detached DOM elements with lingering listeners are a common and hard-to-spot source of memory growth.

I'd add debouncing so the function only executes after the input events have stopped for a set delay, rather than trying to filter duplicate calls after the fact. I'd choose debounce over throttle here since the goal is a single final execution, not periodic execution during the input burst.

I'd avoid adding new global state myself, wrapping the new feature's logic in its own scope or module even if the surrounding code doesn't follow that pattern, so I'm not making the existing problem worse. I'd migrate the legacy globals to a more contained pattern only if it's directly in the path of the feature I'm building.

I'd wrap the existing callback-based functions in promise-returning versions first, keeping the original implementation intact underneath, then migrate calling code to use the new promise interface incrementally. Rewriting the underlying implementation and the calling code at the same time increases the risk of introducing a regression.

I passed an object method as a callback directly, and it lost its this binding when invoked later, causing it to reference the wrong context. I fixed it by binding the method explicitly, and I started being more deliberate about binding whenever passing methods as callbacks after that.

A search-as-you-type feature was firing an expensive filter operation on every keystroke. I added debouncing to limit how often the filter ran and memoized the filtered result for repeated queries, which brought the interface back to feeling responsive without changing the underlying filter logic.