Node.js Interview Questions and Answers

Node.js is a JavaScript runtime built on Chrome's V8 engine. It runs JavaScript outside the browser, on servers and in command-line tools.

Its key design is non-blocking, event-driven I/O: instead of one thread per request waiting for the database or disk, a single JavaScript thread starts the I/O, moves on, and handles the result when it's ready. That makes it efficient for I/O-heavy work like APIs, real-time chat and streaming.

console.log("Node version starts with v:", process.version.startsWith("v"));
console.log("Platform is a string:", typeof process.platform === "string");
console.log("V8 is bundled:", typeof process.versions.v8 === "string");

Node version starts with v: true
Platform is a string: true
V8 is bundled: true

Advantages: one language for frontend and backend, a huge npm ecosystem, and good performance for many concurrent connections. Weakness: long CPU-heavy work (image processing, big calculations) blocks the single thread unless moved to worker threads or another service.

Likely follow-up: Which kinds of applications would you not build in Node.js?

Partly. Your JavaScript runs on one main thread, so two pieces of your code never run at the same moment. But Node itself uses more threads behind the scenes:

• libuv's thread pool (4 threads by default) handles file system work, DNS lookups, compression and some crypto.
• Network I/O uses the operating system's asynchronous mechanisms (epoll, kqueue, IOCP), not threads.
• V8 uses extra threads for garbage collection and compilation.
• You can create your own threads with worker_threads.

const crypto = require("node:crypto");

console.log("start");
crypto.pbkdf2("secret", "salt", 100000, 32, "sha256", () => {
  console.log("hash finished on the thread pool");
});
console.log("main thread keeps going");

start
main thread keeps going
hash finished on the thread pool

Likely follow-up: How would you change the size of the libuv thread pool?

require(x) resolves the name in this order:

1. Core modules like fs or node:fs load first.
2. Paths starting with ./, ../ or / load that file (trying .js, .json, .node) or folder (its package.json main/exports, or index.js).
3. Otherwise Node searches node_modules folders, starting in the current directory and moving up to the root.

Modules are cached after the first load, so their top-level code runs only once and every require gets the same object.

const fs = require("node:fs");
const path = require("node:path");
const os = require("node:os");

const dir = fs.mkdtempSync(path.join(os.tmpdir(), "mod-"));
const file = path.join(dir, "counter.js");
fs.writeFileSync(file, "console.log('module code runs'); let n = 0; module.exports = { next: () => ++n };");

const a = require(file);
const b = require(file);
console.log(a.next(), b.next(), a === b);
fs.rmSync(dir, { recursive: true });

module code runs
1 2 true

The module's code ran once, and both variables share the same counter. Caching is why a module can safely hold a shared database client.

Likely follow-up: What happens with circular dependencies in CommonJS?

exports starts as a reference to module.exports. require always returns module.exports.

• Adding properties to exports works, because it changes the same object.
• Reassigning exports = ... breaks the link, so the new value is never exported.

const Module = require("node:module");

function load(source) {
  const m = new Module("demo");
  m._compile(source, "demo.js");
  return m.exports;
}

console.log(load("exports.add = (a, b) => a + b;").add(2, 3));
console.log(load("exports = { add: () => 0 };"));
console.log(typeof load("module.exports = function greet() {};"));

5
{}
function

Rule of thumb: use module.exports = ... when exporting a single function or class, and either style when adding named properties, but never reassign exports itself.

Likely follow-up: What does require return if a module never assigns anything?

Express is a minimal web framework on top of Node's http module. Plain http gives you a request and response and nothing else: you'd parse URLs, bodies and cookies and route requests yourself.

const http = require("node:http");

const server = http.createServer((req, res) => {
  if (req.method === "GET" && req.url === "/health") {
    res.writeHead(200, { "Content-Type": "application/json" });
    return res.end(JSON.stringify({ ok: true }));
  }
  res.writeHead(404).end();
});

server.listen(0, async () => {
  const { port } = server.address();
  const res = await fetch(`http://localhost:${port}/health`);
  console.log(res.status, await res.json());
  server.close();
});

200 { ok: true }

Express adds routing with parameters, middleware, body parsing, helpers like res.json() and res.status(), and a huge ecosystem (cors, helmet, rate limiters).

import express from "express";

const app = express();
app.get("/health", (req, res) => res.json({ ok: true }));
app.listen(3000);

Alternatives: Fastify (faster, schema-based validation), NestJS (structured, Angular-style, TypeScript-first) and Hono (small, runs on edge platforms).

Likely follow-up: When would you choose Fastify or NestJS over Express?

Middleware is a function that runs during the request-response cycle with access to req, res and next. It can:

• run code (logging, timing)
• change req or res (attach the logged-in user, parse the body)
• end the request (send a 401 response)
• call next() to pass control to the next middleware

function logger(req, res, next) {
  const start = Date.now();
  res.on("finish", () => {
    console.log(`${req.method} ${req.originalUrl} ${res.statusCode} ${Date.now() - start}ms`);
  });
  next();
}

app.use(logger);            // every request
app.use(express.json());    // parse JSON bodies
app.use("/admin", requireAdmin); // only /admin routes

Middleware runs in the order it's registered. If a middleware neither sends a response nor calls next(), the request hangs until the client times out.

Likely follow-up: What happens if middleware calls next() after already sending a response?

REST (Representational State Transfer) is an architectural style for APIs over HTTP. Its main ideas:

• Everything is a resource with a URL: /ebooks, /orders/42.
• Use HTTP methods for actions: GET reads, POST creates, PUT/PATCH update, DELETE removes.
• Stateless: each request carries everything needed (like an auth token); the server keeps no session memory between requests.
• Use status codes to report results.
• Resources have representations, usually JSON.
• Responses can be cached where appropriate.

GET    /api/ebooks           list ebooks
GET    /api/ebooks/react     one ebook
POST   /api/orders           create an order
GET    /api/orders/42        one order
PATCH  /api/orders/42        update part of an order
DELETE /api/cart/items/7     remove an item from the cart

Statelessness is what lets you run many server instances behind a load balancer: any instance can handle any request.

Likely follow-up: How is REST different from GraphQL?

• PUT replaces the whole resource with what you send. Fields you leave out may be cleared or reset.
• PATCH partially updates: only the fields you send change.

const profile = { name: "Rohit", city: "Indore", skills: ["Node"] };

const put = (current, body) => ({ ...body });
const patch = (current, body) => ({ ...current, ...body });

console.log("PUT:", put(profile, { city: "Pune" }));
console.log("PATCH:", patch(profile, { city: "Pune" }));

PUT: { city: 'Pune' }
PATCH: { name: 'Rohit', city: 'Pune', skills: [ 'Node' ] }

PUT is idempotent by design: sending the same full replacement twice leaves the same result. In practice, most APIs use PATCH for edit forms where only some fields change.

Likely follow-up: Can PATCH be idempotent?

• Authentication (authn): who are you? Verifying identity with a password, OTP, Google sign-in or a token.
• Authorisation (authz): what are you allowed to do? Checking permissions: can this user view this order, or access the admin panel?

Authentication comes first; authorisation runs on every request for a protected resource.

const users = { u1: { id: "u1", role: "student" }, u2: { id: "u2", role: "admin" } };
const orders = { o1: { id: "o1", userId: "u1" } };

function canViewOrder(user, order) {
  return user.role === "admin" || order.userId === user.id;
}

console.log("Owner:", canViewOrder(users.u1, orders.o1));
console.log("Admin:", canViewOrder(users.u2, orders.o1));
console.log("Other student:", canViewOrder({ id: "u3", role: "student" }, orders.o1));

Owner: true
Admin: true
Other student: false

A very common real-world bug is checking authentication but not authorisation: any logged-in user can view /orders/123 just by changing the ID. This is called IDOR (Insecure Direct Object Reference), and it's in the OWASP Top 10 as part of Broken Access Control.

Likely follow-up: How would you test an API for IDOR vulnerabilities?

A JSON Web Token is a compact, signed token in three base64url parts separated by dots: header.payload.signature.

• Header: the algorithm, like {"alg":"HS256","typ":"JWT"}
• Payload: claims, like the user ID (sub), expiry (exp), issued-at time (iat) and roles
• Signature: an HMAC or RSA/ECDSA signature of the header and payload

const crypto = require("node:crypto");

const b64 = (obj) => Buffer.from(JSON.stringify(obj)).toString("base64url");
const header = b64({ alg: "HS256", typ: "JWT" });
const payload = b64({ sub: "user_42", role: "student", exp: 1900000000 });
const signature = crypto.createHmac("sha256", "server-secret").update(`${header}.${payload}`).digest("base64url");
const token = `${header}.${payload}.${signature}`;

console.log("Parts:", token.split(".").length);
console.log("Anyone can read the payload:", JSON.parse(Buffer.from(token.split(".")[1], "base64url")));

Parts: 3
Anyone can read the payload: { sub: 'user_42', role: 'student', exp: 1900000000 }

The payload is encoded, not encrypted: anyone holding the token can read it. The signature only proves it wasn't changed and was issued by someone with the key. So never put passwords, phone numbers or other secrets in a JWT.

Likely follow-up: What is the difference between HS256 and RS256?

• Operational errors are expected failures in a correct program: a database timeout, an invalid user input, a payment gateway being down, a file not found. Handle them: retry, return a 4xx or 503, show a friendly message.
• Programmer errors are bugs: reading a property of undefined, passing the wrong type, forgetting await. You can't sensibly "handle" a bug at runtime. Log it, return a 500, fix the code, and if the process state might be corrupted, restart.

class NotFoundError extends Error {
  constructor(what) {
    super(`${what} not found`);
    this.name = "NotFoundError";
    this.status = 404;
    this.isOperational = true;
  }
}

function toResponse(err) {
  if (err.isOperational) return { status: err.status, body: err.message };
  return { status: 500, body: "Something went wrong" };
}

console.log(toResponse(new NotFoundError("Order")));
console.log(toResponse(new TypeError("Cannot read properties of undefined")));

{ status: 404, body: 'Order not found' }
{ status: 500, body: 'Something went wrong' }

Custom error classes with a status and an isOperational flag let a single error handler decide what to show the user.

Likely follow-up: Why is it risky to keep a process running after an unknown programmer error?

If a promise rejects and nothing catches it, Node emits unhandledRejection. Since Node 15, the default is to crash the process with the error, the same as an uncaught exception.

process.on("unhandledRejection", (reason) => {
  console.log("Caught globally:", reason.message);
});

async function sendWelcomeEmail() {
  throw new Error("SMTP timeout");
}

sendWelcomeEmail(); // no await, no .catch()
setTimeout(() => console.log("process still alive because a handler exists"), 10);

Caught globally: SMTP timeout
process still alive because a handler exists

The common cause is a fire-and-forget async call with no await and no .catch(). Fix the cause: await it, or add .catch(logError) for intentional background work. A global handler should log and alert, and then usually let the process restart cleanly.

Likely follow-up: How would you safely run a background task after sending a response?