Node.js interviews have shifted. A few years ago, knowing require vs import and reciting "non-blocking I/O" was enough to get through a junior screen. In 2026, interviewers dig deeper — into event loop internals, memory diagnostics, and system design — even at mid-level. Here's a practical breakdown of what's actually coming up, organized by topic, with the event loop getting its own deep-dive section since it's the single most-tested concept at every level.
1. Event Loop Questions (the ones that trip people up most)
The event loop is Node's most-asked topic because it's easy to describe vaguely and very hard to explain precisely. Interviewers use it to separate people who memorized a definition from people who've actually reasoned about execution order.
Q: What is the event loop, and why does Node need it?
A: Node.js runs JavaScript on a single thread, but it needs to handle many concurrent operations — file reads, network requests, timers — without blocking that thread. The event loop is the mechanism that makes this possible: it continuously checks for completed asynchronous operations and executes their callbacks, cycling through a fixed set of phases. This lets Node handle thousands of concurrent connections efficiently instead of spawning a thread per request.
Q: What are the phases of the event loop, in order?
A: Each loop iteration ("tick") runs through these phases in order:
-
Timers — executes callbacks scheduled by
setTimeoutandsetInterval. - Pending callbacks — executes I/O callbacks deferred from the previous cycle.
- Idle/prepare — internal use.
- Poll — retrieves new I/O events and executes their callbacks; this is where most work happens.
-
Check — executes
setImmediate()callbacks, right after the poll phase. -
Close callbacks — executes cleanup callbacks, e.g.
socket.on('close', ...).
Between every phase transition, Node drains the microtask queue (Promises, process.nextTick) before moving on.
Q: What's the difference between process.nextTick() and setImmediate()?
A: This is the classic trick question. process.nextTick() callbacks run before the event loop continues to the next phase — they're processed as part of the current operation, before I/O events are polled. setImmediate() callbacks run in the check phase, after the poll phase of the current loop iteration.
console.log("start");
setImmediate(() => console.log("setImmediate"));
process.nextTick(() => console.log("nextTick"));
console.log("end");
// Output:
// start
// end
// nextTick
// setImmediate
nextTick always fires before setImmediate in this pattern because the microtask queue (which nextTick uses) is drained before the loop advances to the check phase.
Q: Where do Promises fit into this? Microtasks vs macrotasks.
A: Promise callbacks (.then, .catch, async/await continuations) go into the microtask queue, which has higher priority than the macrotask/callback queue used by setTimeout, setInterval, and I/O callbacks. Node fully drains the microtask queue after every callback and between every event loop phase, before touching the next macrotask.
setTimeout(() => console.log("timeout"), 0);
Promise.resolve().then(() => console.log("promise"));
console.log("sync");
// Output:
// sync
// promise
// timeout
Even though the timeout is scheduled for "0ms," the promise callback always runs first because microtasks are cleared before macrotasks.
Q: If Node is single-threaded, how does it handle file I/O or DNS lookups without blocking?
A: Node offloads I/O-heavy or blocking operations (file system access, DNS lookups, some crypto operations) to a thread pool managed by libuv, Node's underlying C library. The main thread stays free to keep running JavaScript; when the offloaded task finishes, its callback is queued back into the event loop's poll phase for execution on the main thread.
Q: What happens if you run a CPU-intensive synchronous task, like a large loop or heavy computation?
A: It blocks the event loop entirely. Since JavaScript execution on the main thread is synchronous, a long-running loop or expensive computation prevents the event loop from processing any other callback — timers, I/O, everything — until it finishes. This is why CPU-bound work should be offloaded to worker threads or a separate process, not run inline in request handlers.
Q: How would you diagnose an event loop that's "blocked" or "lagging" in production?
A: This is a senior-level follow-up. A strong answer covers:
- Using
perf_hooks'monitorEventLoopDelay()to measure loop lag directly. - Taking CPU profiles (
--profor a tool like Clinic.js) to find synchronous hotspots. - Checking for accidental synchronous APIs (
fs.readFileSync, JSON parsing of huge payloads) inside request handlers. - Considering whether the workload belongs in a worker thread or a queued background job instead of the main event loop.
2. Core Node.js Fundamentals
Asked at every level, usually as a warm-up before diving deeper.
Q: How is Node.js different from a traditional multi-threaded server?
A: Traditional servers employ multi-threading, spawning a new thread per client request, which requires resources even when idle. Node.js instead uses a single thread with non-blocking, asynchronous functions for I/O, making it well-suited for real-time updates and microservices.
Q: What's the first argument convention in a Node.js callback?
A: By convention, the first argument is reserved for an error object — null or undefined if nothing went wrong, otherwise an Error. Checking it before touching the results is the expected pattern.
Q: Why choose Node.js over Java, PHP, or similar backend stacks?
A: Full-stack JavaScript (same language on client and server), a huge npm ecosystem, and an architecture that's naturally efficient for I/O-heavy, real-time, or high-concurrency workloads.
3. Concurrency and Performance (mid to senior level)
Q: Compare child_process.spawn(), child_process.fork(), and worker threads.
A: spawn() launches an independent external process (e.g. running a shell command) with its own memory space and no shared V8 engine. fork() is a specialized version of spawn() for launching new Node.js processes, with an IPC channel built in for message passing. Worker threads run within the same process but on separate threads, letting you offload CPU-bound JavaScript work without the overhead of a full new process.
Q: How does the Cluster module improve performance?
A: The Cluster module lets you run multiple Node.js worker processes that share the same server port, letting a single-threaded runtime take advantage of multiple CPU cores. It also enables rolling restarts without downtime.
Q: How would you handle a memory leak in a long-running Node process?
A: Take heap snapshots at intervals (via --inspect and Chrome DevTools, or heapdump), compare them to find growing retained objects, and check common culprits: unbounded caches, unclosed event listeners, or closures holding references longer than intended.
4. System Design Questions (senior roles)
Senior interviews increasingly open with a design prompt — "design a URL shortener," "design a real-time collaboration tool," "design a chat backend" — and drill into:
- REST API design: idempotency, status codes, pagination
- WebSockets/real-time messaging (
socket.io,ws) - Horizontal scaling: stateless services, load balancing
- Streams and backpressure for large payloads or file uploads
- Observability: structured logging, metrics, distributed tracing
5. Security Questions
- How do you prevent XSS and CSRF in a Node/Express app? (Input validation, output encoding, Helmet middleware, CSP headers.)
- How do you manage secrets and environment configuration safely across dev/staging/prod?
- What's your process for keeping dependencies patched and auditing for known vulnerabilities?
6. A 2026-Specific Shift Worth Knowing
Two things have become near-universal expectations that weren't guaranteed a couple of years ago:
- TypeScript fluency. Interviewers now routinely hand you TypeScript code to read or extend, and expect you to speak to type safety trade-offs, not just plain JS.
- AI-assisted coding literacy. Some interviewers now watch how you use AI tools during live coding — whether you can debug, iterate, and clearly explain your reasoning — treating thoughtful AI use as a baseline skill rather than something to hide.
Wrapping Up
If there's one area worth over-preparing, it's the event loop — not the one-sentence definition, but being able to trace through phase ordering, explain nextTick vs setImmediate vs Promise microtasks from memory, and reason about what blocks the loop versus what gets offloaded to libuv's thread pool. That single topic shows up at every seniority level, just with increasing follow-up depth.
Top comments (0)