Nodejs Interview Questions & Answers for 2026

The event loop is the mechanism that allows Node.js to perform non-blocking I/O operations despite JavaScript being single-threaded. It continuously checks the call stack and the callback queue. When the call stack is empty it picks callbacks from the queue and executes them. Internally it has phases: timers (setTimeout/setInterval), pending callbacks, idle/prepare, poll (I/O), check (setImmediate), and close callbacks. Understanding this prevents blocking the loop with CPU-heavy synchronous code.

process.nextTick() fires after the current operation completes but before the event loop moves to the next phase — it has the highest priority and can starve the loop if used recursively. setImmediate() fires in the check phase of the next iteration of the event loop. setTimeout() with 0ms also fires in the next iteration but in the timers phase, which runs before the check phase. In practice nextTick > setImmediate in priority, though setImmediate is safer in I/O callbacks.

Streams process data in chunks rather than loading it all into memory. There are four types: Readable (fs.createReadStream), Writable (fs.createWriteStream), Duplex (TCP sockets), and Transform (zlib compression). You pipe them together: readStream.pipe(transformStream).pipe(writeStream). Use streams when handling large files, HTTP request/response bodies, or real-time data — they are essential for production performance. Without streams a 1GB file upload would require 1GB of RAM.

Node.js runs on a single CPU core by default. The cluster module allows you to fork the master process into multiple worker processes equal to the number of CPU cores, each with its own event loop and memory. The master process distributes incoming connections to workers using round-robin. Without clustering a Node.js app cannot utilise a multi-core server. In production most use PM2 which handles clustering automatically. Worker threads is an alternative for CPU-intensive tasks within one process.

Wrap await calls in try/catch blocks at the route or controller level. For unhandled promise rejections register process.on("unhandledRejection"). For Express use an error-handling middleware with four parameters (err, req, res, next) and always call next(err) inside async route handlers. A common pattern is a wrapper function asyncHandler(fn) that wraps every route in try/catch and calls next(err) on failure, avoiding repetition.

require() is synchronous and CommonJS — it loads modules at runtime and can be called conditionally anywhere in code. ES module import is asynchronous and static — it must be at the top level, enabling tree-shaking. Node.js supports ES modules with .mjs extension or "type": "module" in package.json. The two systems cannot be mixed directly. require() returns a cached copy on subsequent calls; ES modules also cache but with live bindings. Most existing Node.js packages use CommonJS.

Profile first using clinic.js or node --prof to identify the bottleneck. Common fixes: add database indexes for slow queries, cache repeated computations in Redis, use Promise.all() for parallel async calls instead of sequential awaits, enable gzip compression, move CPU-heavy work to worker threads, and paginate large datasets. Use APM tools like New Relic or Datadog to monitor response times per route. Never optimise without measuring first.

Middleware are functions with signature (req, res, next) that execute sequentially in the order they are registered. Each middleware can modify req/res, end the request, or call next() to pass to the next middleware. app.use() registers global middleware; router.use() scopes it. Error-handling middleware has four parameters. The chain breaks if a middleware sends a response without calling next(), or calls next(err) which skips to error handlers. Common uses: authentication, logging, body parsing, rate limiting.