Node.js & Express Interview Questions

You already know the basics from the earlier lessons: the event loop and blocking (Backend, Lesson 10), errors (Backend, Lesson 04), logging (Backend, Lesson 05), auth (Backend, Lesson 06), and CORS (Browser Contract, Lesson 04). This lesson does not repeat them. It goes one level deeper, and every output and number below comes from code that was run on Node 22 and Express 5.2.

Words used in this lesson

• Node.js is a program that runs JavaScript outside the browser, mostly for servers. Express is a small web framework for Node that routes requests through a chain of functions.
• Middleware is a function that gets (req, res, next). It can read or change the request, answer it, or call next() to pass it on. Think of a security desk, a ticket desk and a gate in a row.
• A signal is a short message that the operating system sends to a process, such as SIGTERM ("please stop now") or SIGINT (Ctrl+C).
• Backpressure is the way a slow receiver tells a fast sender to wait. Like a funnel: pour slower when it fills up.
• A microtask is a tiny job (a promise callback) that runs as soon as the current code finishes, before the loop moves on.
• ESM (ES modules) uses import and export. CommonJS (CJS) uses require and module.exports.

1. The event loop, phase by phase

The event loop is the part of Node that picks the next callback to run. It goes around in a circle of phases. For the interview you need these four, in this order:

(Node also has "pending callbacks" and "idle/prepare" phases for its own use.) Two queues run in between the phases: first process.nextTick callbacks, then promise (microtask) callbacks. They drain completely before the loop moves on.

Here is a program, and the order it printed on Node 22:

// order.cjssetTimeout(() => console.log("timeout"), 0);setImmediate(() => console.log("immediate"));process.nextTick(() => console.log("nextTick"));Promise.resolve().then(() => console.log("promise"));console.log("sync");// sync, nextTick, promise, timeout, immediate   (timeout and immediate can swap)

Two details that interviewers love:

• From the main module, setTimeout(0) vs setImmediate is not guaranteed. Starting up takes about a millisecond, so the timer may or may not be due. In my runs the order changed between node -e and a module file. Inside an I/O callback, setImmediate always wins, because the check phase comes right after poll.
• In an ES module, the promise runs before nextTick. In CommonJS, nextTick comes first. The reason: an ES module is itself evaluated inside a promise job, so the microtask queue is already being drained. The same two lines printed nextTick, promise in a .cjs file and promise, nextTick in an .mjs file. Many blog posts say "nextTick always first". That is only true for CommonJS.

The libuv thread pool

libuv is the C library under Node that does I/O. It has a thread pool: a fixed group of worker threads for jobs the operating system cannot do without blocking. The default size is 4 (UV_THREADPOOL_SIZE, set in the environment before the process starts; setting it from inside the code is not guaranteed to work). It serves all fs calls, dns.lookup, crypto.pbkdf2/scrypt/randomBytes, and zlib. Network sockets do not use it.

I started eight pbkdf2 hashes at once on a 4-core machine. The first four finished together at about 430 ms. The other four finished near 900 ms. That is the queue. The practical result: eight slow password hashes can delay an unrelated fs.readFile, because they share the same four threads. More threads only help if you also have more CPU cores.

2. Streams and backpressure

A stream handles data in chunks instead of all at once. A writable stream has a buffer (a waiting area in memory) and a highWaterMark, the size at which it says "full". The rule is simple:

• writable.write(chunk) returns false when the buffer is over the mark. That means "stop writing".
• When it empties, it emits 'drain'. Then you may write again.

The default mark is 64 KiB for byte streams in Node 22 (it was 16 KiB before Node 22), and 16 objects in object mode. If you ignore the false, the buffer grows until memory runs out. That is the classic "one slow client crashes the server" bug.

You rarely do this by hand. stream.pipeline does it for you, and it also destroys every stream when one fails:

import { Readable, Writable } from "node:stream";import { pipeline } from "node:stream/promises";const source = new Readable({ read() { this.push("x"); } });const broken = new Writable({ write(chunk, enc, cb) { cb(new Error("disk full")); } });try { await pipeline(source, broken); }catch (e) { console.log(e.message, source.destroyed); } // "disk full" true

a.pipe(b) does not forward errors and does not clean up. Prefer pipeline. In an Express handler, await pipeline(fileStream, res) also stops reading the file if the client disconnects.

3. worker_threads vs cluster vs child_process

Difference in one line: worker_threads makes one process do more work at once, and cluster makes more processes answer requests. Under cluster, a crash only kills one worker, but a cache in memory is not shared. I ran a 3-worker cluster; the primary process used round-robin (it hands each new connection to the next worker) on Linux. In containers, most teams skip cluster and run more containers, as in Backend, Lesson 10. os.availableParallelism() tells you how many cores you can use.

4. Async patterns and AbortController

An AbortController is an object that lets you cancel work. You give its signal to the work, and later call controller.abort(). The work stops and rejects.

// 1. A timeoutawait fetch(url, { signal: AbortSignal.timeout(2000) });  // rejects with TimeoutError// 2. Cancel for your own reason, and keep the reasonconst ac = new AbortController();req.on("close", () => ac.abort(new Error("client left")));// 3. Stop on the first of many reasonsconst signal = AbortSignal.any([ac.signal, AbortSignal.timeout(2000)]);await setTimeout(5000, null, { signal });   // from "node:timers/promises"

What I saw when I ran it: a timeout rejects with TimeoutError. abort(reason) makes fetch reject with your reason. Timers from node:timers/promises reject with an AbortError, and signal.reason tells you which reason fired. Pass the signal down through your own functions, and call signal.throwIfAborted() inside long loops.

The four promise helpers, in one line each:

• Promise.all: all must succeed; fails fast on the first rejection (the other tasks keep running, they are not cancelled).
• Promise.allSettled: waits for all; gives {status, value|reason} for each.
• Promise.race: the first to settle, success or failure.
• Promise.any: the first to succeed; if all fail it rejects with an AggregateError that holds every error.

5. ESM vs CommonJS

Facts that changed recently: since Node 22.12 (and 20.19), require() can load an ES module with no flag, unless it uses top-level await. I ran this: the sync module loaded fine, and the one with await threw ERR_REQUIRE_ASYNC_MODULE. So the old line "you cannot require an ES module" is out of date. The other direction always worked: import() can load CommonJS. Inside ESM you can still get require with createRequire(import.meta.url). A missing file in import fails with ERR_MODULE_NOT_FOUND, and in ESM you must write the file extension.

6. Errors and process signals

The error design is in Backend, Lesson 04. Process-level facts:

• Since Node 15 an unhandled promise rejection crashes the process. I ran Promise.reject(new Error("lost")) and the process died. With process.on("unhandledRejection") the handler is called instead.
• uncaughtException fires for a throw that nothing caught. The program may be half-changed. Log, then exit; the process manager starts a clean one.
• SIGTERM and SIGINT have default handlers that exit at once. When you add your own handler, you own the shutdown.

7. Express 5: what changed

Express 5 needs Node 18 or newer. Install gives 5.2.1 today; Express 4 stays supported as the "latest-4" line. These are the changes worth knowing, each checked in code:

Removed: app.del(), req.param(), res.sendfile() (use sendFile), and res.redirect("back"). For res.json(obj, 201): the docs say the signature is gone. In my run on 5.2.1 it did not throw. It answered 200 and ignored the 201. A silent wrong status is worse than an error, so use res.status(201).json(obj).

// Express 5: no try/catch and no wrapper neededapp.get("/users/:id", async (req, res) => {  const user = await db.users.findById(req.params.id); // a rejection goes to the error handler  if (!user) return res.status(404).json({ error: "not_found" });  res.json(user);});

8. Middleware order and routers

Express runs middleware in the order you register it. Most "it does not work" bugs are order bugs. I tested each of these:

const app = express();app.use(requestId);                    // 1. first: every later log can use itapp.use(helmet());                     // 2. security headers on every response, even errorsapp.use(cors(corsOptions));            // 3. before routes, so preflight (OPTIONS) is answeredapp.use(express.json({ limit: "10kb" })); // 4. body parser, before the routes that need itapp.use("/v1", v1Router);              // 5. routesapp.use((req, res) => res.status(404).json({ error: "not_found" })); // 6. 404 after all routesapp.use((err, req, res, next) => { /* 7. error handler, always last, exactly 4 params */ });

• A route registered before express.json() sees req.body === undefined. A route registered after the 404 handler is never reached (I got 404).
• An error handler is recognised by having four parameters. (err, req, res) with three is treated as a normal middleware, so the error went to the default HTML page (500). Also, if headers were already sent, call next(err) instead of writing again.
• next("route") skips to the next route for the same path. next(err) skips to the error handler.
• Without NODE_ENV=production, the default error page prints the stack trace. With it, you get plain Internal Server Error. It also turns on view caching. Set it in production, and still write your own handler.

A router is a mini app that groups routes. express.Router({ mergeParams: true }) lets a child router see the parent's params. router.param("orderId", fn) runs a function once for any route that has :orderId, which is a good place for ID checks. For versions, mount routers by prefix: app.use("/v1", v1), app.use("/v2", v2); the rules are in Backend, Lesson 02.

9. Security middleware

helmet sets a group of safe HTTP response headers in one line. On version 8, I saw it add: Content-Security-Policy, Strict-Transport-Security (max-age=31536000; includeSubDomains), X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, and X-Frame-Options: SAMEORIGIN. It sets X-XSS-Protection: 0 on purpose (the old browser filter caused bugs), and it removes X-Powered-By. It is not a firewall, it does not do CORS, and the default CSP (script-src 'self') will block inline scripts on pages you serve. CSP itself is explained in Browser Contract, Lesson 07.

CORS (cross-origin resource sharing) is a browser rule that blocks a page from reading a response from another origin unless the server allows it (Browser Contract, Lesson 04). Facts from running the cors package:

• cors() with no options sends Access-Control-Allow-Origin: *.
• With an allow-list, a request from another origin still runs on the server; it just has no allow header. CORS protects the user's browser, not your API. Use real auth.
• origin: "*" with credentials: true sends both headers, and the browser rejects it. origin: true with credentials reflects any origin, which is as bad as a wide-open API for logged-in users.
• A preflight (OPTIONS) got 204 with Access-Control-Allow-Methods, -Headers and Max-Age.

Rate limiting with express-rate-limit (v8) counts requests per key (the IP by default) in a time window and answers 429 when the limit is passed. Three things matter:

app.set("trust proxy", 1);   // one proxy (the load balancer) in front of the appapp.use(express.json());      // the limiter reads req.body, so the parser must come firstapp.use("/login", rateLimit({  windowMs: 60_000, limit: 3, standardHeaders: "draft-8", legacyHeaders: false,  keyGenerator: (req) => ipKeyGenerator(req.ip) + ":" + (req.body?.email ?? ""),}));

1. trust proxy. Behind a load balancer every request seems to come from the balancer's IP, so everyone shares one bucket. Set the number of proxies in front. I ran with a forwarded header and trust proxy off, and the library printed ERR_ERL_UNEXPECTED_X_FORWARDED_FOR. Too high a number is also wrong: users can fake the header and dodge the limit.
2. The store. The default store is in memory, per process. With 4 instances the real limit is 4 times bigger. Use a shared store such as Redis.
3. The key. For login, limit by IP and account name, so one attacker cannot lock out a user from everywhere. Wrap IPs with ipKeyGenerator so IPv6 users cannot dodge by changing the last part of their address.

Cookies. res.cookie("sid", value, { httpOnly: true, secure: true, sameSite: "lax", signed: true, maxAge }). With cookie-parser and a secret, a changed signed cookie reads as false. Express 5's res.clearCookie ignores maxAge and expires, so call res.clearCookie("sid", { path: "/" }) with the same path and domain you used to set it. JWT: always pin algorithms: ["HS256"] in verify and check iss and aud. I confirmed that a token with alg: none is rejected when you pin the algorithm. Session versus token trade-offs are in Browser Contract, Lesson 02.

File uploads with multer (v2): set limits.fileSize and limits.files. A file over the limit raised LIMIT_FILE_SIZE, which you map to 413. A fileFilter that returns false silently skips the file; the route still runs with req.file empty. The mimetype is just what the client claimed: a 16-byte text file named evil.png with type image/png passed. Check the real file signature (magic bytes), never trust the name, and better still let clients upload straight to object storage with a presigned URL.

10. Running in production

Graceful shutdown

Graceful shutdown means finishing the requests in progress before the process exits. The order matters. This is the code I ran; a 1.5 s request that was in flight when SIGTERM came still returned 200, and a new request got 503:

let ready = true;app.get("/readyz", (req, res) => res.sendStatus(ready ? 200 : 503));async function shutdown(signal) {  ready = false;                                  // 1. readiness fails: balancer stops sending traffic  await new Promise((r) => setTimeout(r, 5000));  // 2. wait for the balancer to notice (use your real value)  setTimeout(() => { server.closeAllConnections(); process.exit(1); }, 25_000).unref(); // 3. hard deadline  server.close(async () => { await db.close(); process.exit(0); }); // 4. wait for in-flight work, then close the DB  server.closeIdleConnections();                  // 5. drop idle keep-alive sockets}process.on("SIGTERM", () => shutdown("SIGTERM"));process.on("SIGINT", () => shutdown("SIGINT"));

server.close() stops new connections and waits. Since Node 19 it also closes idle keep-alive sockets for you; I confirmed the callback fired with an idle socket open. Active requests still hold it open, hence the deadline. Make the deadline shorter than the platform's kill timeout (Kubernetes waits 30 s by default before SIGKILL). Liveness says "restart me if dead". Readiness says "send me traffic or not". Do not use one endpoint for both.

Containers, PM2 and the first process

A process manager such as PM2 restarts crashed processes and can run a cluster. In containers, the orchestrator does that, so run node directly. Two traps:

• CMD ["npm", "start"]: npm does not pass signals to your app. I sent SIGTERM to npm start (npm 10) and the app never saw it and kept running. Use CMD ["node", "server.js"].
• Node as PID 1 (the first process in a container) gets no default signal handlers from Linux. You need your own SIGTERM handler as above, or an init program such as tini (docker --init) that forwards signals.

Timeouts behind a load balancer

On Node 22 the defaults are keepAliveTimeout 5 s, headersTimeout 60 s and requestTimeout 300 s. Many load balancers (AWS ALB, for example) keep an idle connection for 60 s. If Node closes an idle connection after 5 s at the same moment the balancer reuses it, the client sees a random 502. The fix: set server.keepAliveTimeout higher than the balancer's idle timeout (for example 65 s), and headersTimeout a little above that. This default may change in newer Node versions, so check yours.

Config

Read environment variables once, at start, and check them with a schema so the app fails fast:

// node --env-file=.env server.js   (built in; or process.loadEnvFile())import { z } from "zod";const Env = z.object({  PORT: z.coerce.number().default(3000),  NODE_ENV: z.enum(["development", "test", "production"]).default("development"),  DATABASE_URL: z.string().url(),});export const env = Env.parse(process.env);   // throws with the field name if something is missing

Env values are always strings; z.coerce.number() turns "3000" into a number. Never commit .env. More in Backend, Lesson 03.

11. Memory leaks and profiling

A memory leak is memory that is no longer needed but still reachable, so the garbage collector (the part that frees unused memory) cannot free it. Usual causes: a Map used as a cache with no limit, listeners added on every request, and timers that are never cleared. Node warns about one of them: more than 10 listeners for one event gives MaxListenersExceededWarning.

How to look, in order:

1. Watch process.memoryUsage() over time: heapUsed (JavaScript objects), external and rss (all memory the process holds). Buffers live outside the heap. In my test, a Map holding 10 KB buffers showed heapUsed going from 5 MB to 7 MB but external going from 49 MB to 145 MB. If you only watch the heap you miss it.
2. Take two heap snapshots some minutes apart and compare them in Chrome DevTools. Start with --heapsnapshot-signal=SIGUSR2, or call v8.writeHeapSnapshot(). Look for the object type that grew and read its "retainers" (what holds it).
3. For CPU, use --cpu-prof or --inspect and read the flame graph.
4. Fix: use an LRU cache with a size limit, remove listeners, clear timers, and put limits on queues.

12. Testing and observability

supertest calls your app without listen(); it picks a free port itself. Export a createApp() and keep server.js for the listen call. Here is a run on node --test (all five passed):

import { test } from "node:test";import request from "supertest";import { createApp } from "./app.mjs";const app = createApp();test("malformed JSON gives 400, not 500", async () => {  await request(app).post("/v1/echo").set("content-type", "application/json").send("{bad").expect(400);});test("body over the limit gives 413", async () => {  await request(app).post("/v1/echo").send({ x: "a".repeat(20_000) }).expect(413); // limit is 10kb});

For tracing, AsyncLocalStorage keeps a value (like a request ID) available to every function called during one request, without passing it around:

const als = new AsyncLocalStorage();app.use((req, res, next) => als.run({ id: req.get("x-request-id") ?? randomUUID() }, next));// anywhere later: als.getStore().id

I tested that the ID sent in the header came back inside a handler and in the response. Logs, metrics and traces are in Backend, Lesson 05.

Common mistakes

1. Saying nextTick always runs before promises (wrong in ES modules).
2. Ignoring the false from write(), or using .pipe() without error handling.
3. Starting the container with npm start, and having no SIGTERM handler.
4. Putting the error or 404 handler in the wrong place, or giving the error handler three parameters.
5. No trust proxy behind a load balancer, or an in-memory rate-limit store on many instances.
6. cors({ origin: true, credentials: true }), which allows every site.
7. Trusting an upload's file name or mimetype, and watching only heapUsed.

Interview questions

Key takeaways

• Order: sync code, nextTick, promises, timers, I/O, setImmediate. In ES modules, promises come before nextTick.
• The libuv pool (4 threads by default) is shared by fs, dns.lookup, zlib and some crypto.
• Respect write() returning false, or use pipeline. Use AbortSignal for real cancellation.
• Express 5 handles async errors, but path syntax and several defaults changed. The error handler goes last and has four parameters.
• Pin JWT algorithms, set trust proxy, share rate-limit state, and never treat CORS as protection.
• Shut down in order: fail readiness, wait, server.close(), close dependencies, hard deadline. Start containers with node, not npm.
• Watch external and rss, not only the heap.

What's next

Lesson 07: MongoDB Interview Questions for 4+ Years. Most Node services keep their data somewhere. Next is the document database that pairs with Express: schema design, indexes, aggregation, transactions and sharding.