Node.js Interview Questions for Backend Engineers: Event Loop, Streams, Memory, and Production Debugging

Node.js interview questions for backend engineers test whether you can reason about a live runtime, not whether you memorized Express methods. Strong candidates trace where work executes, identify the constrained queue or memory pool, choose the smallest safe mechanism, and name the evidence that would verify the result.

The core answer is simple: keep event-loop callbacks small, respect stream backpressure, separate V8 heap from total process memory, use worker threads only for suitable CPU work, and debug from measurements rather than folklore.

Use these Software Engineering Fundamentals questions on PracHub to practice the same explanations aloud. PracHub question-bank records are practice material, not predictions of your exact interview.

Node.js interview questions for backend engineers covering the event loop streams memory and production debugging

What Node.js interviewers are actually testing

Node.js runs JavaScript callbacks on one event-loop thread by default, while the operating system, libuv worker pool, V8, and optional Worker threads provide other forms of concurrency. Calling the whole runtime “single-threaded” hides the resource decisions an interviewer wants you to explain.

Area	Baseline answer	Strong backend signal
Event loop	Names timers, poll, check, and callbacks	Locates the work and explains starvation, version, and module-context boundaries
Streams	Knows Readable and Writable	Respects backpressure, cancellation, errors, and slow consumers
Memory	Watches `heapUsed`	Separates V8 heap, external memory, Buffers, RSS, and retention
Production debugging	Opens logs or a profiler	Starts from a symptom, correlates signals, preserves availability, and verifies the fix

Node.js event loop interview questions

Is Node.js single-threaded?

The precise answer is: ordinary JavaScript callbacks normally run on one event-loop thread per Node.js isolate. Node's event-loop guide explains that non-blocking network I/O is usually coordinated with the operating system. A shared libuv pool handles selected filesystem, DNS, crypto, and compression work, while worker_threads can execute JavaScript in parallel.

Which event-loop phases matter in an interview?

Know the simplified path: pending callbacks, poll, check, close callbacks, and timers. Poll runs most I/O callbacks; check runs setImmediate(). A timer delay is a minimum threshold, so other work can make it run later.

Since libuv 1.45.0 in Node 20, timers run after poll during each loop iteration, with an initial compatibility pass before the loop. Top-level setTimeout(fn, 0) versus setImmediate(fn) ordering can vary; inside an I/O callback, setImmediate() runs first.

For generic browser tasks, microtasks, and rendering, use the separate JavaScript event loop interview guide. Keep this answer focused on Node and libuv.

How do `process.nextTick()`, Promise jobs, and `queueMicrotask()` differ?

process.nextTick() is not an event-loop phase. Node drains its queue after the current operation, before allowing the loop to continue; recursive scheduling can therefore starve I/O. queueMicrotask() uses the same V8 microtask queue as resolved Promise handlers.

Name the module context. Current process.nextTick() documentation shows next-tick callbacks before Promise microtasks in CommonJS, but the reverse at ES-module top level. Node recommends queueMicrotask() for most portable userland deferral.

Does `async`/`await` prevent event-loop blocking?

No. await pauses an async function and schedules its continuation after the awaited value settles; it does not move synchronous CPU work to another thread. Split small work deliberately or move substantial CPU-bound JavaScript to a worker pool. Adding async to a tight loop or large JSON transformation does not make it non-blocking.

Does every asynchronous API use the libuv worker pool?

No. Ordinary network sockets generally use OS readiness mechanisms. Node's worker-pool guidance lists asynchronous filesystem work, dns.lookup(), selected crypto, and zlib as pool users. Slow tasks can delay unrelated pool work; changing UV_THREADPOOL_SIZE requires measurement and startup-time configuration.

Node.js streams and backpressure interview questions

What are the four core stream types?

A Readable produces chunks, a Writable consumes them, a Duplex does both independently, and a Transform derives output from input. Also cover errors, end versus close, cancellation, partial output, and slow consumers.

What does backpressure mean in Node.js?

Backpressure is the signal that a downstream consumer cannot safely accept more data at the producer's current rate. When writable.write(chunk) returns false, pause production and resume after 'drain'. Ignoring that signal lets buffers grow, increasing RSS and garbage-collection pressure.

highWaterMark is a threshold that influences when the signal appears, not a hard memory limit. For custom Readables, respect the return value of push() as well. The official backpressure guide shows both sides of that contract.

Why prefer `stream.pipeline()` over a chain of `pipe()` calls?

stream.pipeline() coordinates backpressure and reports chain completion or failure. It destroys unfinished streams after errors, subject to documented exceptions. Still cover abort signals and ownership; failed stream reuse needs care because listeners may remain.

Node.js memory and leak interview questions

How do `heapUsed`, `external`, `arrayBuffers`, and RSS differ?

process.memoryUsage() reports bytes. heapTotal and heapUsed describe V8 heap; external covers C++ memory associated with JavaScript objects; arrayBuffers includes Node Buffer allocations and is already part of external. RSS is resident memory for the whole process.

With Workers, RSS is process-wide while the other fields describe the current Worker thread. Rising RSS with stable heap may reflect Buffers, native allocation, or fragmentation—not necessarily a JavaScript leak.

Can Node.js leak memory even with garbage collection?

Yes. Garbage collection reclaims unreachable objects, not reachable objects the application no longer needs. Unbounded maps, caches without eviction, listeners that are never removed, timers, closures, queued work, and request context retained beyond its lifecycle can all leak. Define the expected steady state before labeling a deliberate bounded cache as a defect.

How should you investigate sustained memory growth?

Use a repeatable evidence path:

Reproduce the trend under representative traffic and compare equivalent lifecycle points.
Separate V8 heap growth from Buffer/ArrayBuffer, external, and total RSS growth.
Correlate the curve with requests, GC, event-loop delay, deployments, and workload stages.
Use GC traces or sampling heap profiling before reaching for a disruptive snapshot.
Compare retention paths only from an instance whose loss will not reduce availability.
Repeat the workload after the fix and prove that retained memory reaches an expected plateau.

Official heap-snapshot guidance warns that a snapshot stops main-thread work, may take more than a minute, can double heap usage, and may crash the process.

Node.js production debugging map for event-loop delay CPU memory and active resources

Worker threads and production safety questions

When should you use `worker_threads`?

Use Worker threads for CPU-intensive JavaScript, not as a replacement for built-in asynchronous I/O. Pool recurring jobs; one Worker per request can cost more than the work. Cover queue bounds, cancellation, transfer cost, failures, and observability.

Worker resourceLimits constrain parts of that Worker's JavaScript engine, not external memory or the entire process. A process-wide out-of-memory condition can still terminate every isolate.

Why does a Node.js process refuse to exit?

Referenced resources keep the loop alive. Open servers, sockets, timers, ports, watchers, and in-flight I/O with referenced handles or requests are common causes; an unresolved Promise alone does not keep Node alive. process.getActiveResourcesInfo() reports resource types; a diagnostic report adds libuv handles, stacks, heap statistics, and platform data.

For graceful shutdown, stop traffic, set a drain deadline, finish or cancel owned work, close dependencies, and verify resources. unref() changes liveness; it does not cancel work.

Production debugging questions for Node.js

What would you inspect when p99 latency rises but CPU looks normal?

Correlate dependency latency, pool saturation, GC, queue depth, event-loop delay, and event-loop utilization. monitorEventLoopDelay() reports nanoseconds; utilization measures active versus idle loop time, not CPU.

High delay and utilization suggest the loop is not yielding. High latency with low utilization may point to dependencies or pools. Synchronous waiting can raise utilization while CPU stays mostly idle, so confirm with profiles and traces.

How would you investigate a CPU spike?

Protect users first, then use a CPU profile for hot JavaScript or native execution such as serialization, regular-expression backtracking, compression, loops, or logging. Inspect operation latency, concurrency, and queueing separately for libuv-pool saturation. Change one cause and compare the same load.

Diagnostic report, CPU profile, or heap snapshot?

Choose from the symptom. CPU profiles locate execution time; heap profiles or controlled snapshots investigate allocation and retention; diagnostic reports preserve stacks, heap statistics, resource use, and libuv handles. Reports may include environment and network details, so treat them as sensitive.

A production-grade Node.js answer framework

Use P-Q-E-V for almost any runtime question:

Path: Trace the request or chunk from JavaScript into the host API, operating system, libuv pool, Worker, stream, or V8 heap.
Queue: Name the constrained queue, buffer, thread, handle, or memory region and its ownership.
Evidence: Select the metric or artifact that can distinguish competing hypotheses.
Verification: State the correctness test, representative load, availability safeguard, and before/after signal.

For example, do not answer “increase the thread pool.” Say: “If filesystem and PBKDF2 work share the pool, I would measure queueing under representative concurrency, separate or bound expensive work, test a startup-time pool change if justified, and verify both latency and throughput without starving the event loop.”

Practice with PracHub backend questions

These verified records exercise the same reasoning. They are practice material, not a forecast of a particular employer's interview.

PracHub question	Practice focus	Why it helps
Explain JavaScript Scope, Closures, Timers, and the Event Loop	Host execution and timer semantics	Forces you to name the environment before predicting behavior
Wrap a Fixed-Chunk Stream Reader with Arbitrary-Length Reads	Buffering, EOF, partial reads	Exercises stateful stream contracts without losing data
Investigate High Memory Usage	Heap, RSS, retention, evidence	Turns memory growth into a disciplined production investigation
Debug an Asynchronous SDK Race Condition with a Customer	Async ordering and incident communication	Connects runtime reasoning to reproduction and verification
Design async batched key-value fetcher	Batching, bounded work, failure handling	Tests queue ownership, throughput, and partial-result semantics

A seven-day Node.js interview plan

Day 1: Draw the event loop and explain poll, check, timers, and the Node 20 change without notes.
Day 2: Trace nextTick, Promise, microtask, immediate, and timer behavior in both CommonJS and ESM.
Day 3: Implement one Readable-to-Transform-to-Writable pipeline with abort, error, and slow-consumer handling.
Day 4: Create a controlled memory-growth example and compare heapUsed, external, arrayBuffers, and RSS.
Day 5: Move a CPU-heavy task to a bounded Worker pool and measure transfer overhead.
Day 6: Diagnose three scenarios: event-loop delay, pool saturation, and a process that will not exit.
Day 7: Answer five questions with P-Q-E-V.

Common Node.js interview mistakes

Avoid saying every asynchronous call uses a thread, every Promise runs before nextTick, or every zero-delay timer runs immediately. Do not treat highWaterMark as a hard cap, RSS as the V8 heap, or a heap snapshot as a harmless production command. “Use worker threads” is incomplete without workload size, pool bounds, failure behavior, and measurement.

The strongest answers preserve context. State the Node version, module system, workload, and exact resource under pressure.

Frequently asked questions

Which Node.js version should I prepare for?

Use the release named by the job or assessment. As of August 30, 2026, Node.js 24 is Active LTS, Node.js 22 is Maintenance LTS, and Node.js 26 is Current. Learn stable runtime principles first, then review version-sensitive timer, stream-default, and diagnostics behavior in the exact environment.

Are Node.js interview questions different for experienced backend engineers?

Yes. Senior follow-ups move toward overload, backpressure, memory categories, cancellation, graceful shutdown, sensitive diagnostics, and proof under production traffic. Interviewers expect a resource model and validation plan, not only an API name.

Should I memorize every event-loop phase?

Know the simplified phases well enough to place I/O, setImmediate(), timers, and close callbacks. More important, explain that the diagram is simplified, timer delays are thresholds, module context changes microtask examples, and a long callback can delay every client sharing the event-loop thread.

Worker threads or child processes?

Worker threads share one process and can transfer or share memory, which suits CPU-heavy JavaScript with controlled coordination. Child processes provide stronger memory and failure isolation but add process and communication overhead. Choose from isolation, data-transfer cost, crash domain, security boundary, deployment, and workload duration.

Which Node.js debugging tools should I mention?

Map tools to symptoms: event-loop delay and utilization for responsiveness, CPU profiles for hot execution, process.memoryUsage() for memory categories, sampling heap profiles or controlled snapshots for retention, process.getActiveResourcesInfo() for liveness, and diagnostic reports for failure-time stacks, heap statistics, and libuv handles.

Final takeaway

Node.js interview questions for backend engineers reward exact runtime boundaries. Trace the execution path, respect backpressure, separate heap from process memory, offload only suitable CPU work, and choose diagnostics that preserve availability. Practice until every answer names the constrained resource, evidence, failure mode, and verification step.

Sources and Further Reading

Research note: Checked August 30, 2026. Node.js release status and some runtime defaults change; confirm the interview and production versions before relying on version-sensitive behavior.

Node.js Interview Questions for Backend Engineers: Event Loop, Streams, Memory, and Production Debugging