Node.js Interview Questions: Event Loop, Streams & Async Patterns Explained

Node.js powers Uber's real-time dispatch, Netflix's streaming APIs, and LinkedIn's mobile backend — not because it's the fastest language on the planet, but because it handles tens of thousands of simultaneous connections without spawning a new thread for each one. That's a fundamentally different mental model from Java or PHP, and interviewers test whether you truly understand it or just read the docs the night before.

The core problem Node.js solves is the C10K problem — handling 10,000 concurrent connections cheaply. Traditional servers block a thread per connection. Node's non-blocking I/O model means one process can juggle thousands of network requests because it never sits around waiting — it delegates I/O to the OS and moves on. Understanding this isn't trivia; it changes how you architect every feature you build.

By the end of this article you'll be able to explain the event loop's phase sequence under pressure, describe when streams beat buffering, write cluster code that actually uses all CPU cores, and sidestep the async/await traps that trip up even experienced developers. These aren't memory-game answers — they're patterns you'll use on day one of the job.

The Heart of Node: Mastering the Event Loop

To master Node.js, you must stop thinking linearly. The Event Loop isn't just a 'loop'; it's a multi-phase cycle managed by libuv. When an interviewer asks 'What is the order of execution?', they are looking for specific phases: Timers, Pending Callbacks, Idle/Prepare, Poll, Check, and Close Callbacks.

A common senior-level trick question is the difference between setImmediate() and process.nextTick(). While setImmediate() is designed to execute in the 'Check' phase after the poll phase completes, process.nextTick() isn't technically part of the event loop at all—it fires immediately after the current operation completes, before the loop moves to the next phase. If you abuse nextTick, you can actually starve the event loop, preventing I/O from ever happening.

// TheCodeForge — Event Loop Execution Order Demonstration
const fs = require('fs');

console.log('1. Script Start');

setTimeout(() => {
    console.log('2. setTimeout (Timer Phase)');
}, 0);

setImmediate(() => {
    console.log('3. setImmediate (Check Phase)');
});

fs.readFile(__filename, () => {
    console.log('4. File Read (Poll Phase Callback)');
    
    setTimeout(() => console.log('5. Nested setTimeout'), 0);
    setImmediate(() => console.log('6. Nested setImmediate'));
});

process.nextTick(() => {
    console.log('7. nextTick (Microtask - executes before next phase)');
});

console.log('8. Script End');

Data on the Move: Why Streams are Non-Negotiable

Imagine trying to read a 4GB log file into a 2GB RAM instance. If you use fs.readFile(), your app crashes with an 'Out of Memory' error because it tries to buffer the entire file. This is where Streams come in.

Streams allow you to process data piece by piece (chunks). In a production environment, you should 'pipe' data directly from the source to the destination. This keeps the memory footprint tiny and constant, regardless of the file size. At TheCodeForge, we use streams for everything from file uploads to processing large SQL result sets.

// TheCodeForge — Memory Efficient Stream Processing
const fs = require('fs');
const zlib = require('zlib');

const source = fs.createReadStream('./massive_log.txt');
const destination = fs.createWriteStream('./massive_log.txt.gz');

// Piping: Read chunk -> Compress chunk -> Write chunk
// This handles backpressure automatically!
source
  .pipe(zlib.createGzip())
  .pipe(destination)
  .on('finish', () => {
    console.log('Successfully compressed log without breaking the RAM bank. 🚀');
  });

Frequently Asked Questions