Node.js Interview Questions and Answers

Node.js is a JavaScript runtime built on Chrome's V8 engine. It lets you run JavaScript outside the browser, mostly for servers and tools.

Your JavaScript runs on one main thread, driven by an event loop. "Non-blocking" means slow operations (file, network, database) are handed to the operating system or libuv's thread pool. A callback or promise continues the work when they finish. The main thread stays free to serve other requests.

This makes Node good for I/O-heavy workloads: APIs, real-time chat, streaming, proxies. It is a poor fit for long CPU-heavy work (image processing, heavy maths) on the main thread. That work blocks every request. For that use worker threads, a job queue or another service.

What they are checking: Whether you understand the model, including its weakness

Middleware is a function (req, res, next) that runs between receiving a request and sending the response. It can read or modify req and res, end the response, or call next() to pass control on.

const express = require("express");
const app = express();

app.use(express.json());                      // parse JSON body
app.use((req, res, next) => {                 // logger
  console.log(req.method, req.url);
  next();
});
app.get("/users/:id", auth, (req, res) => res.json({ id: req.params.id }));

app.use((err, req, res, next) => {            // error middleware (4 args)
  res.status(500).json({ error: "Server error" });
});

Order matters: middleware runs in the order it is registered. Types: application level, router level, built-in, third-party (helmet, cors, morgan) and error handling (four parameters). Forgetting next() leaves the request hanging.

What they are checking: Whether you understand the request pipeline and ordering

Blocking code stops the thread until it finishes; nothing else on that thread can run. Non-blocking code starts the work and continues, with a callback, promise or event handling the result.

const fs = require("fs");
const data = fs.readFileSync("big.txt");        // blocks every request
fs.readFile("big.txt", (err, data) => {});      // callback
const d2 = await fs.promises.readFile("big.txt"); // promise

On a server, synchronous calls like readFileSync, pbkdf2Sync or a heavy JSON.parse stall all clients. They are acceptable at startup (loading config). Prefer the async versions in request handlers, and move CPU-heavy tasks to worker threads.

What they are checking: Whether you avoid blocking the loop

CommonJS (CJS) uses require() and module.exports, loads synchronously, and is the traditional Node format. ES modules (ESM) use import/export, are statically analysed, load asynchronously and are the language standard.

package.json lists your direct dependencies with version ranges plus scripts and metadata. package-lock.json records the exact version of every dependency (including indirect ones) and integrity hashes. So every install gives the same tree.

Authentication verifies who you are (login). Authorisation decides what you may do (roles, permissions, ownership).

npm is Node's package manager and registry: it installs packages, runs scripts and publishes modules.

A Buffer is a fixed-size chunk of raw binary data allocated outside the V8 heap. It is used for files, network packets, images and crypto, where data is bytes rather than strings.

dependencies are packages needed at run time (express, pg). devDependencies are only needed for development and build (jest, eslint, typescript). npm install --omit=dev skips the latter in production. peerDependencies declare packages the host project must supply (common in plugins).

EventEmitter (from the events module) is the base of Node's event-driven pattern. Objects emit named events and listeners react to them. Streams, HTTP servers and sockets all extend it.

const fs = require("fs/promises");
const text = await fs.readFile("data.txt", "utf8");   // whole file in memory

const stream = require("fs").createReadStream("big.csv", "utf8"); // chunks

• readFile loads the full file into memory, which is simple and fine for small files such as config. -...

Keep configuration out of the code and read it from process.env, following the twelve-factor approach.

CORS (Cross-Origin Resource Sharing) is a browser mechanism. By default a page from one origin cannot read responses from another origin. The server opts in with headers such as Access-Control-Allow-Origin. For non-simple requests the browser first sends an OPTIONS preflight.

Choose Node.js for:

• I/O-bound APIs and microservices with many concurrent connections.
• Real-time features: chat, notifications, live dashboards (WebSocket, Server-Sent Events).
• Teams that already use JavaScript or TypeScript across frontend and backend, sharing types and code.
• Backends for frontends, serverless functions, proxies and tooling.

exports is a shortcut variable that initially points to the same object as module.exports. require() always returns module.exports.

Use the built-in http module.

Routes map an HTTP method and path to a handler. Use express.Router() to group related routes.

process is a global object that represents the running Node process.

Use util.promisify for functions that follow the Node convention (error first, callback last), or use the built-in promise APIs.

Run the app as a managed process behind a reverse proxy, with the code delivered by a repeatable script.

The event loop is run by libuv and cycles through phases, each with a queue of callbacks:

1. timers: setTimeout and setInterval callbacks that are due.
2. pending callbacks: some deferred system I/O callbacks.
3. idle, prepare: internal.
4. poll: retrieves new I/O events and runs their callbacks; it may wait here if nothing else is scheduled.
5. check: setImmediate callbacks.
6. close callbacks: for example socket.on('close').

Between each callback (and after each phase transition) Node drains process.nextTick first, then promise microtasks.

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
process.nextTick(() => console.log("tick"));
Promise.resolve().then(() => console.log("promise"));
// tick, promise, then timeout/immediate (order of the last two varies in the main module)

Inside an I/O callback, setImmediate always fires before setTimeout.

What they are checking: Whether you can name the phases and ordering

• process.nextTick(fn) runs right after the current operation, before the event loop continues and before promise microtasks. Overusing it can starve I/O.
• setImmediate(fn) runs in the check phase, after the poll phase.
• setTimeout(fn, 0) runs in the timers phase after at least 1 ms.

Order of priority: nextTick, then promise microtasks, then timers/immediates.

• Use nextTick to run something after the current function but before any I/O. One example is emitting an event after you return the emitter.
• Use setImmediate to yield to the event loop between chunks of work.
• From the main module the order of setTimeout 0 and setImmediate is not guaranteed; inside an I/O callback setImmediate is always first.

What they are checking: Whether you know the queue order

A stream processes data in chunks instead of loading it all into memory. There are four types: Readable, Writable, Duplex (both) and Transform (modify data while passing through).

const { pipeline } = require("stream/promises");
const fs = require("fs");
const zlib = require("zlib");

await pipeline(
  fs.createReadStream("input.log"),
  zlib.createGzip(),
  fs.createWriteStream("input.log.gz")
);

Use them for large files, uploads and downloads, HTTP request/response bodies, CSV processing and compression. Benefits: constant memory use and faster time to first byte. Use pipeline (not bare .pipe) so errors propagate and resources are cleaned up. Streams support backpressure: when the consumer is slow, write() returns false and the source pauses until drain.

What they are checking: Whether you can handle big data without exhausting memory

All three use more CPU cores, but in different ways.

const { Worker, isMainThread, parentPort, workerData } = require("worker_threads");
if (isMainThread) {
  new Worker(__filename, { workerData: 40 }).on("message", console.log);
} else {
  const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));
  parentPort.postMessage(fib(workerData));
}

In production, cluster is often replaced by PM2 or containers with one process each behind a load balancer.

What they are checking: Whether you pick the right tool for I/O versus CPU work

Use a central error-handling middleware with four arguments, registered last. Synchronous throws inside route handlers reach it automatically. In Express 4, rejected promises from async handlers do not, so wrap them or call next(err). Express 5 forwards rejected promises automatically.

const wrap = (fn) => (req, res, next) => fn(req, res, next).catch(next);

app.get("/users/:id", wrap(async (req, res) => {
  const user = await db.find(req.params.id);
  if (!user) { const e = new Error("Not found"); e.status = 404; throw e; }
  res.json(user);
}));

app.use((err, req, res, next) => {
  const status = err.status || 500;
  res.status(status).json({ error: status === 500 ? "Internal error" : err.message });
});

Also: create custom error classes, log with context, and never leak stack traces to clients. Handle unhandledRejection and uncaughtException at process level, to log the error and exit cleanly.

What they are checking: Whether you handle async errors and avoid leaking details

A JSON Web Token is a signed token with a header, payload (claims such as sub, exp) and signature. The server signs it after login; the client sends it on each request; the server verifies the signature and expiry without a session lookup.

Layered measures:

Scale vertically first, then horizontally, and remove bottlenecks before adding servers.

After an uncaughtException the process state may be inconsistent, so log it and exit; let a supervisor (PM2, Docker, Kubernetes) restart it. Since Node 15, unhandled promise rejections also crash the process by default.

libuv is the C library that provides Node's event loop and asynchronous I/O across operating systems. Network I/O uses OS facilities (epoll, kqueue, IOCP) directly. Operations with no async OS API are run on libuv's thread pool, which has 4 threads by default.

Use the cache-aside pattern: check Redis, on a miss read the database and store the result with a TTL.

Opening a database connection is slow and databases limit concurrent connections. A pool keeps a set of open connections and lends them out, reusing them across requests.

Use layers of tests.

Use structured (JSON) logs and send them to a central system.

Backpressure happens when a producer writes data faster than a consumer can handle. Without control, buffered data piles up in memory.

A writable stream signals this: write() returns false when its internal buffer passes highWaterMark. The producer should pause until the drain event, then resume.

All start another process, but with different output handling.

Recent LTS releases reduced the need for extra packages:

Confirm it is a leak: memory climbs and does not drop after garbage collection. Then check process.memoryUsage() or metrics for heapUsed and RSS over time.

Find it:

1. Run with node --inspect, connect Chrome DevTools, and take heap snapshots under load a few minutes apart. Use the Comparison view to see which object types grow. Then read what keeps them alive (their retainers).
2. Or use --heapsnapshot-signal=SIGUSR2 in production-like environments, or tools such as clinic.js.

Typical causes:

• Unbounded in-memory caches or maps keyed by user id.
• Event listeners added per request and never removed (the "MaxListeners" warning is a hint).
• Closures holding large request objects, global arrays that accumulate, timers never cleared.
• Un-ended streams or unclosed connections.

Fix: bound caches (LRU with a max size and TTL) or move them to Redis, remove listeners, clear timers, close resources. Verify memory plateaus under load. Setting --max-old-space-size only delays the crash.

What they are checking: Whether you debug with heap snapshots, not guesses

Node runs your code on one thread, so a hot function blocks all requests.

Diagnose:

• Capture a CPU profile: node --prof and node --prof-process, clinic flame, or Chrome DevTools via --inspect. Read the flame graph for the widest functions.
• Check event loop lag (perf_hooks.monitorEventLoopDelay) and which endpoint correlates with the spike.

Common culprits and fixes:

• Large JSON.parse/stringify, sorting or looping over big arrays: paginate, stream, or process in chunks with setImmediate.
• Synchronous crypto or hashing: use async versions or worker threads.
• Catastrophic regex backtracking: fix the pattern or limit input size.
• Complex per-request computation: cache results, precompute, or move to a worker pool or separate service.

Then run one process per core (cluster or containers). That way one busy process does not take down all capacity. Add load tests to confirm the fix.

What they are checking: Whether you profile and know the single-thread consequence

Work from measurement to cause.

Never buffer the whole file in memory. Stream it end to end and batch the writes.

Counters must be shared across instances, so use a central store (Redis), not in-memory counters per process.

Combine graceful shutdown with a rolling or blue-green deploy.

Act in layers, fastest wins first.

Likely suspects:

Stateless JWTs are valid until they expire, so revocation needs extra design.