Node.js interview questions and answers

Question 1

What is Node.js?

Accepted Answer

Answer: Node.js lets you run JavaScript outside the browser, on a server or your machine. It bundles Google's V8 JavaScript engine with a set of libraries for things browsers do not give you: reading files, opening network sockets, talking to databases, and running child processes. It uses the same single-threaded, event-loop model as the browser, plus a background thread pool (libuv) for file and crypto work. Its strength is I/O-heavy workloads: web servers, APIs, real-time apps. Its weakness is heavy CPU work, which blocks the one thread. Analogy: the browser's JavaScript engine, taken out of the browser and given a toolbelt for talking to the operating system. In an interview: Node runs JavaScript on the server using V8 plus system libraries for files, networking, and processes. It shares the browser's single-thread event-loop model with a libuv thread pool underneath. Great for I/O-bound servers, poor for CPU-heavy work.

Question 2

Is Node.js multi-threaded? How does it handle many requests at once?

Accepted Answer

Answer: Your JavaScript runs on a single thread, the same event-loop model as the browser. Node handles many requests at once not with threads but by never blocking: when a request needs the database or the file system, Node starts that I/O and moves on to the next request. When the I/O finishes, its callback is queued and the event loop picks it up. So one thread juggles thousands of connections, as long as each request spends most of its time waiting on I/O rather than doing heavy computation. Node is not purely single-threaded underneath: it has a small background thread pool (libuv) for file I/O and crypto, and you can spawn worker threads or run a cluster across CPU cores for CPU-heavy work. Analogy: one waiter taking orders from many tables. The waiter does not stand at the kitchen waiting for each dish; they take the next order while the kitchen cooks, and deliver food as it comes out. In an interview: Node runs your JavaScript on one thread with an event loop. It scales by non-blocking I/O: it starts I/O and serves other requests while waiting. A libuv thread pool handles file and crypto work; worker threads or clustering handle CPU-heavy tasks.

Question 3

What is the event loop in Node, and what are its phases?

Accepted Answer

Answer: The event loop is the loop that keeps checking for work to do and runs the callbacks for finished operations. It runs in phases, in order, over and over: 1. Timers: run callbacks from setTimeout and setInterval whose time is up. 2. Pending callbacks: some system-level callbacks. 3. Poll: wait for and run I/O callbacks (incoming requests, file reads). 4. Check: run setImmediate callbacks. 5. Close: run 'close' event callbacks (a socket closing). Between every phase (and between each callback), Node drains two special queues first: process.nextTick callbacks, then Promise microtasks. That is why a resolved promise's .then runs before a setTimeout scheduled at the same time. Analogy: a night guard doing rounds of a building in a fixed order: check the timers room, the mail room, the phones, and so on, looping forever. At every door they first check their pager (nextTick and promises). In an interview: The event loop cycles through phases: timers, pending, poll (I/O), check (setImmediate), close. Between every phase it drains process.nextTick then Promise microtasks, which is why promise callbacks beat a same-time setTimeout.

Question 4

What is the difference between process.nextTick, setImmediate, and setTimeout(fn, 0)?

Accepted Answer

Answer: process.nextTick(fn): runs fn before the event loop continues to its next phase, right after the current operation. It jumps the whole queue. Overusing it can starve the loop, because the loop cannot move on until the nextTick queue is empty. setImmediate(fn): runs fn in the 'check' phase, on the next loop iteration, after I/O callbacks. This is the safe 'do it right after this, but yield first' option. setTimeout(fn, 0): runs fn in the 'timers' phase after at least 0ms, which in practice is roughly 1ms. Similar to setImmediate but with slightly different ordering, especially outside an I/O callback where the order is not guaranteed. Rule: use setImmediate to yield, avoid process.nextTick unless you specifically need to run before I/O. Analogy: nextTick is 'stop the presses, do this now'. setImmediate is 'add it to the top of tomorrow's list'. setTimeout(0) is 'add it to tomorrow's list at the earliest slot'. In an interview: process.nextTick runs before the loop advances, jumping the queue and able to starve it. setImmediate runs on the next iteration in the check phase and is the safe way to yield. setTimeout(fn, 0) runs in the timers phase roughly a millisecond later.

Question 5

What is a blocking operation in Node, and why is it dangerous?

Accepted Answer

Answer: A blocking operation is one that holds the single thread until it finishes, so no other request can be handled meanwhile. Because Node serves every client on one thread, one slow synchronous call freezes the whole server for everyone. Culprits: the synchronous file APIs (fs.readFileSync), synchronous crypto (crypto.pbkdf2Sync), JSON.parse or JSON.stringify on a huge object, a big loop, regex catastrophic backtracking, and synchronous child_process calls. Fixes: use the async versions of APIs, move CPU-heavy work to a worker thread or a separate service, stream large data instead of loading it all, and break big loops into chunks that yield with setImmediate. Analogy: one cashier serving a queue. If they stop to count a huge jar of coins by hand, everyone behind them just waits, no matter how quick their own purchase is. In an interview: A blocking call holds the one thread so nothing else runs, freezing the server for all clients. The usual causes are synchronous file and crypto APIs, huge JSON parsing, and big loops. Use async APIs, workers for CPU work, and streaming for large data.

Question 6

What is the difference between CommonJS and ES modules in Node?

Accepted Answer

Answer: Node has two module systems. CommonJS (the original): require("x") to import, module.exports = ... to export. It is synchronous and dynamic, so you can require inside an if. It is the default for .cjs files and for .js unless you opt out. ES modules (the standard, also used in browsers): import and export. You enable it with "type": "module" in package.json or an .mjs extension. Imports are static (analysable at load time, which helps bundlers and tree-shaking) and support top-level await. New projects generally use ES modules. Mixing the two needs care: an ES module can import a CommonJS one, but not always the reverse without dynamic import(). Analogy: CommonJS is the old wiring standard, ES modules are the new one that the whole industry, browsers included, is moving to. In an interview: CommonJS uses require and module.exports, is synchronous and dynamic. ES modules use import and export, are static and analysable, support top-level await, and match browsers. New code uses ES modules, and mixing them takes care.

Question 7

What is package.json, and what is the difference between dependencies, devDependencies, and the lockfile?

Accepted Answer

Answer: package.json is the manifest for a Node project: its name, version, scripts, and the packages it depends on. dependencies: packages your app needs to run in production (express, react). devDependencies: packages needed only to build or test (typescript, eslint, jest). They are skipped with npm install --production. Version ranges like ^1.2.3 allow compatible updates, so two installs at different times could get different versions. The lockfile (package-lock.json, pnpm-lock.yaml) records the EXACT version of every package and sub-package that was installed. Committing it means every machine and the CI server install the identical tree, so 'works on my machine' bugs from version drift disappear. Use npm ci in CI, which installs strictly from the lockfile. Analogy: package.json is the shopping list ('some kind of milk'). The lockfile is the receipt ('this exact carton, this brand, this size'). In an interview: package.json lists the project's metadata, scripts, and dependencies. dependencies are needed at runtime, devDependencies only to build and test. The lockfile pins the exact resolved versions of the whole tree so every install is identical, and CI uses npm ci to install strictly from it.

Question 8

What is the difference between npm, npx, and a global install?

Accepted Answer

Answer: npm install : adds a package to the current project's node_modules and package.json. This is the normal case. npm install -g : installs a command-line tool globally so you can run it from any folder (for example a scaffolding tool). Downside: the version is not tracked per project, so different projects can clash. npx : downloads and runs a package's command once, without installing it, then cleans up. Great for one-off tools like create-next-app, or running a project's local binary. It prefers a locally installed version if there is one. Modern practice: install tools as devDependencies and run them via npm scripts or npx, and avoid global installs. Analogy: npm install is buying a tool for your workshop. Global install is bolting it to every workshop. npx is renting it for one job and returning it. In an interview: npm install adds a package to the project. npm install -g installs a CLI tool system-wide, which is untracked and can clash. npx runs a package's command once without installing it, preferring a local copy. Prefer local devDependencies plus npx over globals.

Question 9

What are streams in Node, and why use them?

Accepted Answer

Answer: A stream processes data piece by piece as it arrives, instead of loading the whole thing into memory first. There are four kinds: Readable (a file being read, an incoming request), Writable (a file being written, an outgoing response), Duplex (both, like a socket), and Transform (a duplex that changes the data, like gzip). Why: memory and speed. Serving a 2GB video by reading it fully into a Buffer would use 2GB of RAM per request and delay the first byte. A stream sends chunks as it reads them, using a small constant amount of memory, and the client starts receiving immediately. You connect streams with pipe (or pipeline, which also handles errors and cleanup). Analogy: a bucket brigade versus carrying the whole reservoir. The brigade moves water continuously with small buckets; nobody has to lift the lake. In an interview: A stream handles data in chunks as it flows rather than buffering it all. The types are Readable, Writable, Duplex, and Transform. Use them for large files and responses to keep memory constant and start delivery immediately, connecting them with pipeline.

Question 10

What is a Buffer in Node?

Accepted Answer

Answer: A Buffer is a fixed-size chunk of raw binary data, outside the normal V8 heap. JavaScript strings are for text; a Buffer is for bytes: file contents, network packets, image data, encryption input. You get Buffers from file reads, socket data, and crypto. You convert to and from strings by specifying an encoding (utf8, base64, hex). A common bug is assuming one character equals one byte; a multi-byte UTF-8 character split across two Buffer chunks decodes wrongly unless you use a decoder that handles boundaries. Analogy: a string is a sentence; a Buffer is the raw ink and paper. Text APIs work on sentences, but files and networks deal in ink. In an interview: A Buffer is a fixed-size block of raw bytes stored off the V8 heap, used for binary data from files, sockets, and crypto. You convert to and from strings with an explicit encoding, and you have to be careful about multi-byte characters split across chunks.

Question 11

How do you handle errors in Node across callbacks, promises, and events?

Accepted Answer

Answer: It depends on the style of the API. Error-first callbacks (older APIs): the callback's first argument is the error. Always check it: if (err) return handle(err). Promises / async-await: use .catch() or wrap await in try/catch. An unhandled rejection fires process 'unhandledRejection' and, in newer Node, crashes the process by default. EventEmitters (streams, servers): listen for the 'error' event. An 'error' event with no listener throws and crashes the process, so always attach one. Last resort: process.on('uncaughtException') to log and exit gracefully. Do not use it to keep running; the process is now in an unknown state. Let a process manager restart it. Analogy: each API style has its own alarm: callbacks put the error in your hand, promises ring a bell you must answer, and emitters shout 'error' and break things if nobody is listening. In an interview: Error-first callbacks put the error in the first argument, so check it. Promises use catch or try/catch, and unhandled rejections crash newer Node. EventEmitters need an 'error' listener or they throw. uncaughtException is only for logging and a clean exit, then let a process manager restart.

Question 12

How do you use all the CPU cores on a machine with Node?

Accepted Answer

Answer: One Node process uses one core for JavaScript. To use all cores you run multiple processes or threads. cluster module: forks several copies of your server process, and the operating system (or the cluster master) spreads incoming connections across them. Each worker is a full process with its own memory. Good for a stateless HTTP server. worker_threads: real threads inside one process, sharing memory via SharedArrayBuffer. Good for offloading CPU-heavy tasks (image processing, parsing) without a separate process. In practice a process manager like PM2, or a container orchestrator running N containers behind a load balancer, does the clustering for you. Keep the app stateless (no in-memory sessions) so any process can handle any request. Analogy: one chef per stove. To cook faster you add stoves and chefs (cluster), or bring in helpers who share your kitchen for the heavy chopping (worker threads). In an interview: One Node process uses one core, so you run several: the cluster module forks worker processes that share the incoming connections, and worker_threads gives real threads for CPU-heavy work. In production PM2 or a container orchestrator does this, and the app must be stateless.

Question 13

What causes event-loop lag or a memory leak in a Node service, and how do you find it?

Accepted Answer

Answer: Event-loop lag: something synchronous is hogging the thread. Causes: heavy JSON work, a big synchronous loop, sync file or crypto calls, or a bad regex. Symptom: requests that should be fast get slow under load, and latency spikes. Measure the loop delay (perf_hooks monitorEventLoopDelay, or an APM tool) and move the heavy work off the main thread. Memory leak: memory climbs and never comes down, ending in an out-of-memory crash. Causes: an ever-growing array, Map, or cache with no limit; event listeners added per request and never removed; closures holding large objects; global state accumulating. How to find it: run with --inspect and take heap snapshots in Chrome DevTools before and after load, or use clinic.js. Compare snapshots and look for the object type that keeps growing. Analogy: loop lag is one task blocking the checkout line. A leak is the stockroom filling with boxes nobody ever removes. In an interview: Event-loop lag is synchronous work blocking the thread, found by measuring loop delay and moving heavy work to a worker. A memory leak is memory that only grows, usually an unbounded cache, un-removed listeners, or accumulating global state, found by comparing heap snapshots under load with --inspect or clinic.js.

Node.js interview preparation

The Node runtime

Modules and packages

Core APIs

Scaling and production