Node.js interviews revolve around the event loop, asynchronous patterns, Express or NestJS, and the consequences of a single-threaded runtime. Below are the most common questions with model answers. Middle: deeper understanding, optimization, and real-world situations.
Because it occupies the single thread that serves every request — a two-second computation makes every concurrent user wait two seconds. The options are moving it to a worker thread, to a separate process or queue, or replacing the algorithm. The trap is that it looks fine under low traffic in development and appears as a latency cliff under load.
They let you process data in chunks instead of holding it in memory. Reading a one-gigabyte upload with readFile allocates a gigabyte per concurrent request, which is how a service dies at three simultaneous uploads. Piping keeps memory constant regardless of file size. Backpressure is the part people skip — if the destination is slower than the source, an unpiped stream buffers until the process runs out of memory.
Confirm it first — rising heap that never returns after garbage collection, rather than normal sawtooth. Then take two heap snapshots minutes apart under load and compare retained objects; the diff usually names the culprit directly. The usual causes are a growing cache with no eviction, listeners added per request and never removed, and closures holding a large object alive.
It runs one process per core so you use the whole machine instead of one thread, with the OS balancing connections. What it does not give you is shared state — anything in memory now exists per worker, so in-process caches diverge and sessions break unless they move to Redis. It also does not fix a slow handler; it multiplies the number of things that can be slow.
The same way as anywhere: notice one query per item in the log, then load the related rows in a single query. Prisma has include, Sequelize has eager loading, and a raw join always works. The Node-specific trap is awaiting inside a for loop, which serialises calls that could run together — Promise.all fixes the latency, but does not fix the query count.
Whether the event loop is blocked, which a lag metric answers directly and guessing does not. If the loop is fine, the time is in a downstream call — database, upstream API — and connection pool exhaustion is a frequent cause. Logs of average latency hide this; percentiles do not, because the p99 is where the pool exhaustion lives.
Intercept at the HTTP layer with something like nock rather than mocking your own client, so the test exercises the real request-building and parsing. Record one real response as a fixture and assert against it. Mocking your own wrapper tests that your mock matches your mock, which is why those suites stay green while the integration breaks.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle Node.js Backend interview →