Node.js Interview Questions and Answers (2026)

Node runs JavaScript on a single thread but delegates I/O (file system, network, timers) to the system/libuv, which notifies the event loop when work completes. The loop then runs the associated callback. This is why Node handles thousands of concurrent connections cheaply — it isn't blocked waiting on I/O — but a CPU-heavy synchronous task still blocks everything else.

Roughly: timers (setTimeout/setInterval), pending callbacks, poll (fetching new I/O events, executing their callbacks), check (setImmediate), and close callbacks. process.nextTick() and resolved promise callbacks (microtasks) run between phases, before the loop continues — which is why they fire before a setTimeout(fn, 0).

They're the same underlying mechanism with different ergonomics. Callbacks are prone to nesting ("callback hell") and inconsistent error handling. Promises standardise success/error paths and chain cleanly. async/await is syntax sugar over promises that reads like synchronous code — use it by default, but remember await still needs try/catch for errors and doesn't make anything actually synchronous.

Node emits an unhandledRejection event and, depending on version/configuration, can crash the process. Always attach .catch() or wrap await calls in try/catch; in Express-style apps, funnel errors to a single error-handling middleware rather than leaving stray unhandled rejections.

CommonJS resolves and loads modules synchronously at runtime and supports dynamic require() calls anywhere. ES Modules are statically analysed (imports are known at parse time, enabling tree-shaking) and loaded asynchronously; top-level await is only available there. Interop between the two has sharp edges — a default export from CJS doesn't always map cleanly into ESM import.

It tells Node to treat .js files as ES Modules instead of the CommonJS default, enabling import/export syntax and top-level await without needing a .mjs extension.

dependencies are needed at runtime in production; devDependencies are only needed for building/testing (linters, test runners, bundlers). A package-lock.json (or equivalent) pins exact resolved versions so installs are reproducible — always commit it.

Promise.all([...]) runs them concurrently and rejects as soon as any one fails. Promise.allSettled([...]) runs them concurrently but waits for all to finish regardless of failure, giving you each result's status individually — use it when partial failure is acceptable.

Two main ways: the built-in cluster module forks multiple processes that share a port (good for stateless HTTP servers), and worker_threads run genuine parallel JS threads with message-passing (good for CPU-bound work like image processing or parsing) without forking a whole new process.

Offload it — either to a worker_thread, a separate microservice/queue consumer, or by breaking it into chunks processed across multiple event-loop ticks. Never run a heavy synchronous loop directly in a request handler; it stalls every other in-flight request.

Streams process data in chunks as it arrives, so memory use stays flat regardless of file size, and processing can start before the whole file is available. For large files or proxying HTTP payloads, this is the difference between a service that scales and one that runs out of memory under load.

Readable (a source, e.g. reading a file), Writable (a destination, e.g. an HTTP response), Duplex (both, e.g. a TCP socket), and Transform (a duplex stream that modifies data as it passes through, e.g. gzip compression).

.pipe() connects a readable stream to a writable one and automatically manages backpressure — pausing the source if the destination can't keep up. Reimplementing that manually is easy to get wrong; .pipe() (or the pipeline() utility, which also handles errors and cleanup correctly) is the standard approach.

A middleware function receives (req, res, next) and can inspect/modify the request, end the response, or call next() to pass control along the chain. Order matters — body parsers, auth checks, and logging typically run before route handlers; error-handling middleware (four arguments) runs last.

Centralise it: throw or pass errors to next(err) inside route handlers, and let one error-handling middleware format the response consistently (status code, message shape) rather than duplicating try/catch logic in every route.

Set security headers (helmet), configure CORS explicitly rather than allowing all origins, validate and sanitise input, use parameterised queries (never string-concatenate SQL), rate-limit auth endpoints, and keep dependencies patched — npm audit regularly, not just once.

Watch heap usage over time (via process.memoryUsage() or a monitoring tool) — if it climbs and never comes back down after GC, take a heap snapshot (--inspect + Chrome DevTools, or clinic.js/heapdump) and look for objects that shouldn't still be retained, commonly an ever-growing cache, array, or event listeners that were never removed.

Confirm where time is actually going: add timing around the database call, downstream HTTP calls, and any synchronous processing. Check for missing indexes, N+1 query patterns, connection-pool exhaustion, or a synchronous block stalling the event loop. Profile with --prof/clinic.js under realistic load rather than guessing.

process.nextTick() callbacks run immediately after the current operation, before the event loop continues to the next phase — even before promise microtasks in some Node versions' ordering nuances. setImmediate() callbacks run in the check phase, after I/O events for the current loop iteration. In practice: use setImmediate for "run after I/O this tick," and use nextTick sparingly since overusing it can starve the event loop.