Node.js Developer interview questions

Node.js moves through phase-specific callback queues coordinated by libuv, with timers processed after poll in current releases.

• Pending callbacks handle selected deferred system-operation callbacks.
• Poll receives I/O readiness and runs many I/O callbacks, then check runs setImmediate callbacks.
• Close callbacks run for abrupt handle closure, while nextTick and microtask queues are drained around JavaScript callback execution.

Macrotask is an informal name for event-loop work such as timers and I/O callbacks, while microtasks run at checkpoints between those callbacks.

• Promise reactions and resumed await continuations use the V8 microtask queue.
• process.nextTick has a separate Node.js queue with higher priority after ordinary callbacks.
• Node.js drains these high-priority queues before continuing to another event-loop callback, so they can delay macrotask progress.

After an ordinary callback returns, Node.js normally drains the nextTick queue before the V8 Promise microtask queue.

• Callbacks scheduled by nextTick can enqueue more nextTick work before event-loop phases resume.
• Promise handlers can enqueue further microtasks within the same checkpoint.
• ESM evaluation and code already running inside a microtask mean this rule is not a universal source-order guarantee.

process.nextTick runs before the event loop advances, setImmediate targets the check phase, and setTimeout targets timer processing after a delay threshold.

• nextTick has the highest urgency and can starve I/O when scheduled recursively.
• When both are created in one I/O callback, setImmediate runs in the upcoming check phase before a zero-delay timer.
• From top-level code, setImmediate and a zero-delay timer have no universal relative-order guarantee.

The poll phase can wait for I/O when its queue is empty and no scheduling condition requires immediate progress elsewhere.

• Ready I/O callbacks are processed from the poll queue.
• A queued setImmediate causes the loop to proceed to check rather than wait indefinitely.
• Upcoming timers bound how long poll can wait before timer processing is needed.

Microtasks can starve other work because Node.js drains their queues before returning to event-loop phases.

• Each Promise handler may enqueue another handler and keep the checkpoint busy.
• Recursive process.nextTick is even more urgent and can prevent poll from running.
• Breaking large work into bounded pieces scheduled with setImmediate allows timers and I/O to regain progress.

The libuv thread pool runs selected blocking or CPU-intensive native operations away from the event-loop thread.

• Many filesystem calls, dns.lookup, crypto, and zlib share the pool.
• Pool saturation queues more of those operations even when the event-loop thread is idle.
• Socket readiness usually uses operating-system event notification and does not consume one pool thread per connection.

Event loop utilization estimates the proportion of elapsed time the event-loop thread was active rather than waiting for events.

• A high value can indicate sustained JavaScript work or callbacks that keep the loop busy.
• A low value does not prove healthy latency because work may be waiting in the libuv pool or an external dependency.
• It complements delay histograms and application metrics rather than replacing them.

Each worker thread has its own JavaScript isolate and event loop, so CPU work there does not execute on the main event-loop thread.

• The main thread and workers communicate through messages or explicitly shared memory.
• Asynchronous I/O on the main thread is usually efficient without workers.
• Worker startup and communication have costs, so they suit substantial CPU-bound work rather than every callback.

highWaterMark is a buffering threshold used to signal flow control, not a strict maximum amount of memory.

• A readable stream may stop requesting more source data near the threshold.
• A writable stream returns false from write when buffered data reaches the threshold.
• In object mode the value counts objects, while byte-oriented streams generally count bytes.

Backpressure propagates when a slower writable signals that upstream producers should pause until capacity returns.

• write returning false tells a manual producer to wait for drain.
• pipe pauses and resumes compatible readable sources based on downstream demand.
• Ignoring the signal permits buffers to grow, increasing memory use and garbage-collection pressure.

stream.pipeline connects streams while coordinating errors, closure, and teardown across the entire chain.

• A failure in one stage destroys the related streams instead of leaving the rest running silently.
• Its callback or Promise settles when the pipeline completes or fails.
• The Promise form integrates with async functions and can accept an AbortSignal for cancellation.

stream.finished observes when a stream ends, finishes, closes, or fails according to its readable and writable sides.

• It is useful when code needs completion notification without constructing a full pipeline.
• The callback form returns a cleanup function for removing the listeners it installed.
• The Promise utility from stream/promises enables the same lifecycle wait with await.

A Transform stream implements a writable input side and a readable output side connected by transformation logic.

• _transform receives an input chunk, encoding, and callback, then pushes zero or more output chunks.
• The callback signals that the current chunk is finished and controls when the next input can be processed.
• _flush can emit final buffered output before the readable side ends.

Object mode lets stream chunks be JavaScript values other than null instead of byte-like data.

• null remains reserved as the end-of-readable-stream signal, and readableObjectMode and writableObjectMode configure duplex sides independently.
• highWaterMark counts objects rather than bytes in object mode.
• Object mode is useful for record pipelines but does not serialize objects for network or file transport automatically.

cork buffers small writes temporarily so uncork can flush them together to the underlying destination.

• Batching can reduce system-call overhead for many small chunks.
• Implementing _writev allows a custom writable to receive buffered chunks efficiently as a group.
• uncork is commonly deferred with process.nextTick so writes from the current turn can be batched.

Async iteration provides sequential chunk consumption with Promise-based waiting and natural use inside async functions.

• The loop receives chunks only as they become available, respecting stream flow control.
• Breaking early normally destroys the iterator-backed stream unless iterator options specify otherwise.
• Errors from the stream reject the iteration and should be handled through the surrounding async error path.

Current Node.js can convert compatible readable and writable streams between Node.js and Web Streams representations.

• Readable.toWeb and Readable.fromWeb bridge readable implementations.
• Writable.toWeb and Writable.fromWeb provide the corresponding writable bridge.
• Backpressure, cancellation, chunk types, and object-mode expectations still need compatible semantics at the boundary.

The cluster module starts multiple Node.js worker processes that can share incoming server connections.

• Each worker is a separate process with its own V8 heap, event loop, and module state.
• The primary process coordinates workers and connection distribution but does not create shared JavaScript memory.
• Clustering uses multiple CPU cores for process-isolated request handling.

The cluster primary coordinates a shared server handle or distributes accepted connections to workers.

• Workers can call listen with the same address through cluster-aware server setup.
• The default scheduling policy on common platforms distributes connections among workers.
• Application-level state is not shared merely because the workers serve one port.