Intermediate Node.js Interview Questions and Answers

Each turn visits: timers (setTimeout/setInterval callbacks that are due), pending callbacks (some deferred system callbacks), poll (wait for and run I/O callbacks), check (setImmediate callbacks), and close callbacks. Between every callback, Node runs the process.nextTick queue and then promise microtasks. That is why promise callbacks run before the next timer, and why setImmediate runs before a 0 ms timer inside an I/O callback.

process.nextTick runs right after the current operation, before promise callbacks and before the event loop continues (overusing it can starve I/O). setImmediate runs in the check phase of the current loop turn. setTimeout(fn, 0) runs in the timers phase of a later turn. Inside an I/O callback, setImmediate always fires before setTimeout(..., 0); at the top level of a script their order is not guaranteed.

Streams process data in chunks instead of loading it all into memory: readable (file reads, requests), writable (file writes, responses), duplex (sockets) and transform (gzip). Backpressure happens when a writable destination cannot keep up with a readable source; the writer signals "slow down" (write() returns false) and the reader pauses until drain. pipeline() handles backpressure and error cleanup automatically, which is why it is preferred over .pipe().

Node throws the error, which crashes the process if nothing catches it. Always attach an error listener to emitters that can fail: streams, sockets, servers and your own emitters.

Wrap await calls in try/catch, or let them propagate to a central handler. Unhandled promise rejections terminate the process in current Node versions. In Express 5, errors thrown (or rejected) in async route handlers are forwarded automatically to error-handling middleware (err, req, res, next); in Express 4 you had to catch them and call next(err).

Resources identified by URLs (plural nouns: /api/orders/42), standard HTTP methods for actions (GET reads, POST creates, PUT replaces, PATCH updates, DELETE removes), stateless requests (each carries what the server needs, such as a token), meaningful status codes, and representations such as JSON. Filtering, sorting and pagination go in the query string.

PUT replaces the whole resource with the representation sent, so all fields are required, and repeating it gives the same result (idempotent). PATCH applies a partial update, changing only the fields sent.

Never build SQL by concatenating user input. Use parameterised queries / prepared statements (WHERE email = ? with the value passed separately), or an ORM or query builder that parameterises for you. Placeholders make the database treat input purely as data, so ' OR '1'='1 cannot change the query.

Anyone can call the API directly with curl or scripts, bypassing the front end. The server must validate types, ranges, formats and permissions for every request. Schema libraries such as Zod or Joi make this consistent and also strip unexpected fields.

With sessions, the server stores session data and the client holds a random session id in a cookie; revoking access is instant (delete the session), but the server needs shared storage (such as Redis) when it scales. With JWTs, the token itself carries signed claims and the server stores nothing; it scales easily, but tokens cannot be revoked before they expire without extra infrastructure, so they should be short-lived (with refresh tokens). Either way, hash passwords with bcrypt, scrypt or Argon2.

Cross-Origin Resource Sharing: browsers block a page on one origin from reading responses from another origin unless the server allows it with Access-Control-Allow-* headers. For requests that are not "simple", the browser first sends a preflight OPTIONS request. Configure CORS on the API with the specific origins you trust; CORS does not restrict non-browser clients such as curl.