Node.js Developer Interview Questions for AI Training Work

I use async/await over raw promises or nested callbacks wherever possible, since it reads closer to synchronous code while keeping the non-blocking behavior. For cases with genuinely independent async operations, I use Promise.all rather than awaiting them sequentially when there's no dependency between them.

Microtasks, like resolved promises, run before the next macrotask, like a setTimeout callback, even if the macrotask was scheduled first. This matters when ordering assumptions break, like a promise resolving before a timer you expected to fire first, which can cause subtle bugs if you're not aware of the distinction.

I offload it to a worker thread or a separate process rather than running it directly on the main thread, since Node's single-threaded event loop means a long synchronous computation blocks every other request. For very heavy workloads, I'd consider whether the task belongs in Node at all versus a dedicated service.

I add explicit error handling at the boundaries where promises are created rather than relying on a global unhandled rejection handler as the primary safety net, since that handler is better suited for logging and alerting than recovery. I also make sure the process doesn't silently continue in a bad state after an unhandled rejection.

I use EventEmitter for communication within a single process where events don't need to survive a crash or be processed by multiple consumers. I move to a message queue once events need to cross process boundaries, need guaranteed delivery, or need to be consumed by more than one service.

I'd check for blocking operations sneaking into the request path, like synchronous file reads or an inefficient database query, since low CPU with high latency often points to something waiting rather than computing. I'd also check the event loop lag directly, since that's a more precise signal than CPU usage alone.

I'd implement rate limiting keyed by client identity rather than a single global limit, since a blanket limit either throttles legitimate high-volume users or lets abusive traffic through at the same threshold. I'd also look at whether the abusive traffic shares a distinguishing pattern that can be blocked more directly.

I'd use a queue system that supports acknowledgment, so a job isn't marked complete until it's actually finished processing, rather than removing it from the queue as soon as it's picked up. That way a crash mid-job leaves the job available to be retried instead of silently lost.

A long-running service was slowly consuming more memory over days. I used heap snapshots taken at intervals to compare object counts over time, which pointed to an event listener being added on every request without ever being removed. Fixing the listener cleanup resolved it.

I inherited a data processing pipeline built entirely on nested callbacks, which made error handling inconsistent across steps. I converted it incrementally, function by function, verifying behavior against existing tests at each step, rather than rewriting the whole pipeline at once and risking a large regression.