Node.js Mock Interview: The Questions to Rehearse Before the Real One

A Node.js interview is not a JavaScript quiz with a server theme. Interviewers are checking one thing above all: do you understand that your code shares a single thread with everything else in the process, and do you write code that respects that? Here is the loop as it actually runs, round by round, with the answers that get credit.

Round one: the event loop

“Explain the event loop.” The answer that scores is not the phase diagram recited from memory — it is the consequence. Node runs your JavaScript on one thread; I/O is delegated to the platform and its completion is queued back as a callback. So a slow synchronous function does not slow one request, it stalls every request in the process. Name the phases if asked (timers, pending callbacks, poll, check, close), and know that process.nextTick and promise microtasks drain between phases, before setImmediate.

The follow-up is usually: “so what do you do with CPU-heavy work?” Answer with the ladder — move it out of the request path, use worker threads, split it into chunks, or hand it to a queue and a separate process. Any of those is right; not noticing the problem is what fails.

Round two: async patterns

Callbacks to promises to async/await, and why each step happened. Be fluent in Promise.all versus allSettled versus race, what happens to an unhandled rejection, and why an awaitinside a loop is often an accidental performance bug. Expect a live rewrite: “here is a callback pyramid, make it readable”, or “these five requests run one after another, make them concurrent”.

Round three: streams and backpressure

The classic scenario: process a two-gigabyte CSV on a container with 512 MB of memory. Reading it into a string is the failing answer. Streams with pipeline() is the passing one, and mentioning backpressure — the reader slowing down because the writer cannot keep up — is what marks you as someone who has done it in production rather than read about it.

Round four: errors and reliability

How you handle a rejected promise in an Express or Fastify handler, why an uncaught exception should end the process rather than be swallowed, graceful shutdown on SIGTERM, and the difference between an operational error (a database timeout, retry it) and a programmer error (undefined is not a function, fix it). Timeouts, retries with backoff, and circuit breaking on outbound calls all belong in this answer.

Round five: scaling and deployment

Cluster mode or multiple containers to use every core, statelessness so instances are interchangeable, Redis for shared state and caching, and a queue for anything slow. Then the observability question: how would you find out that p95 latency doubled last Tuesday? Mentioning structured logs, metrics, and tracing here costs one sentence and buys a lot of credibility.

Round six: the design question

Most Node loops end with something like “design a URL shortener”, “design a rate limiter”, or “design the notification service for our app”. Talk through the API first, then storage, then the failure modes, then scale. Say your trade-offs out loud — the interviewer is grading the reasoning, not the diagram.

How to rehearse this

Read these topics once, then close the tab and say each answer out loud as if someone asked. The event loop explanation should take you about ninety seconds without stumbling. If it does not, that is your first practice session. Running a full mock backend interview end to end — in the language your real interview will use — turns a list of topics you recognise into answers you can produce on demand.