These Node JS interview questions are for engineering managers and senior developers hiring backend or full-stack engineers, and for candidates who want a clear view of what a strong answer covers. They go past trivia into how Node.js behaves in production: what blocks the event loop, how async errors escape, how streams handle large data, and how a service shuts down cleanly. Choose 6 to 10 that fit the level. For each one, ask the candidate how they'd confirm the behavior, not only what they believe it is.
What a strong Node.js interview checks
- Event loop model: knowing what runs when, and what blocks everything else.
- Async correctness: promises, error handling and concurrency limits without leaks or silent failures.
- Runtime and modules: ES modules versus CommonJS, and the built-in tools modern Node ships with.
- Performance and scaling: streams, backpressure, worker threads and running across cores.
- Production habits: graceful shutdown, logging, memory debugging and safe dependencies.
- Team skills: explaining decisions and owning incidents.
Node JS interview questions: the event loop and async
1. Explain how Node.js handles many connections on one thread.
What good looks like: JavaScript runs on a single main thread, while libuv handles I/O. Network sockets use the operating system's non-blocking mechanisms, so one thread can wait on thousands of connections. Some work, including most file system calls, dns.lookup, parts of crypto and zlib, runs on libuv's thread pool, which has 4 threads by default (set with UV_THREADPOOL_SIZE).
Red flag: "Node is single-threaded, so it can only do one thing at a time."
2. In what order do process.nextTick, a resolved promise's then, setTimeout(fn, 0) and setImmediate run?
What good looks like: in a CommonJS script, the nextTick queue runs first, then promise microtasks, both before the event loop moves on. Between setTimeout(fn, 0) and setImmediate in the main script, the order isn't guaranteed. Inside an I/O callback, setImmediate always runs first, because the check phase comes right after the poll phase. Strong candidates name the loop phases: timers, pending callbacks, poll, check and close callbacks.
3. What blocks the event loop, and how do you find it?
What good looks like: long synchronous work, such as parsing a huge JSON body, a regex with catastrophic backtracking, synchronous crypto or readFileSync inside a request handler, or a big loop. To find it, measure event loop delay with perf_hooks.monitorEventLoopDelay and profile with --cpu-prof or the inspector. Fixes include streaming, splitting work, or moving it to a worker thread.
4. What happens to an unhandled promise rejection?
What good looks like: since Node 15 the default is to throw, which crashes the process. They know the common causes, like a missing await or a .then() without a .catch(), and that a process-level handler is for logging and shutting down, not for carrying on as if nothing happened.
Red flag: adding an unhandledRejection handler that swallows everything.
5. When would you use Promise.all, Promise.allSettled, Promise.race and Promise.any?
What good looks like: all rejects on the first failure, so use it when every result is required. allSettled waits for all and reports each outcome, which suits partial results. race settles with the first to settle, often for timeouts. any resolves with the first success and rejects only if all fail.
6. You need to call an API for 10,000 records. Why is Promise.all over all of them a problem?
What good looks like: it starts every request at once, which can exhaust sockets and memory and trip rate limits. They'd cap concurrency with a small pool or a library such as p-limit, add timeouts with AbortSignal.timeout(), and retry failures with backoff.
Modules, runtime and tooling
7. What are the practical differences between CommonJS and ES modules?
What good looks like: require loads synchronously, while import is resolved before the code runs and supports top-level await. ESM is enabled with "type": "module" or the .mjs extension. ESM has no __dirname, so they'd use import.meta.dirname in current versions. Strong candidates know recent Node versions can require() an ES module as long as its graph has no top-level await.
8. What can modern Node do without extra packages?
What good looks like: a global fetch, a built-in test runner in node:test, --watch mode, and --env-file for loading environment variables. Recent releases can also run TypeScript files directly by stripping type annotations, though that doesn't type-check, so tsc still runs in CI.
9. How do you keep npm dependencies safe?
What good looks like: commit the lockfile and install with npm ci in CI, so builds use exact versions. Review new packages before adding them, keep the dependency count low, run audits, and be careful with install scripts. They should know about the npm package compromises of 2025 and why pinning and slow, reviewed upgrades matter.
Red flag: "We just run npm install and use whatever version comes."
10. What changed in Express 5 that affects error handling?
What good looks like: route handlers that return a rejected promise now pass the error to the error-handling middleware automatically, so async handlers no longer need a wrapper to avoid hanging requests. Strong candidates mention other choices too, such as Fastify, and say why they'd pick one.
Performance, streams and scaling
11. A user uploads a 2 GB file that you need to send to object storage. How do you handle it?
What good looks like: stream it, never buffer it. Pipe the request stream through to the upload using pipeline from node:stream/promises, which handles errors and cleanup. They explain backpressure: when write() returns false, the producer waits for the drain event.
Red flag: reading the whole file into a Buffer first.
12. How do you use all the CPU cores on a server?
What good looks like: run several Node processes, through the cluster module, a process manager, or more container replicas behind a load balancer. Keep the processes stateless, with sessions in a shared store like Redis. Use worker_threads for CPU-heavy tasks inside a process, not to handle each request.
13. Memory climbs until the container is killed. How do you find the leak?
What good looks like: take heap snapshots a few minutes apart (with --inspect and DevTools, or v8.writeHeapSnapshot()) and compare what keeps growing. Common causes: an unbounded in-memory cache or Map, event listeners never removed (watch for MaxListenersExceededWarning), timers never cleared, and closures holding large objects.
14. How should a Node service shut down in Kubernetes?
What good looks like: handle SIGTERM, start failing the readiness check, stop accepting new connections with server.close(), let in-flight requests finish, close database pools and queues, then exit. Add a hard timeout so a stuck request can't block shutdown forever.
15. How do you attach a request ID to every log line without passing it through every function?
What good looks like: AsyncLocalStorage from node:async_hooks, set in middleware at the start of each request. Pair it with a structured JSON logger so logs can be searched by request ID across services.
Practical scenarios
16. An endpoint calls three internal services. How do you keep it fast and reliable?
What good looks like: call independent services in parallel, set a timeout on each, and decide what happens when one fails (fail the request, or return partial data with allSettled). Retry only idempotent calls, with backoff, and consider caching and a circuit breaker for a flaky dependency.
17. What are the first security checks you'd make on a Node API?
What good looks like: validate input with a schema, use parameterized queries, set security headers, rate-limit auth routes, and never pass user input to eval or child_process. They mention prototype pollution from unsafe object merging, verifying JWT signatures with a fixed algorithm, and keeping secrets out of code.
18. How do you test code that writes to a database and calls a payment provider?
What good looks like: unit tests with the payment client injected and replaced by a fake. Integration tests against a real database in a container, reset between tests. Test the failure paths too: timeouts, declined payments and duplicate webhook deliveries.
Behavioral (STAR)
19. Tell me about a production problem in a Node service you worked on.
What good looks like: a clear account of symptoms, how they narrowed it down (metrics, profiles, heap snapshots), the fix, and what they added afterward so it would be caught sooner. They describe their own part and credit others.
20. Describe a major upgrade you led, such as a new Node version or a framework migration.
What good looks like: they read the breaking changes, upgraded in small steps behind tests, rolled out gradually, and kept the team informed. The Result covers what broke and how quickly they recovered.
A simple scoring rubric
Running this interview with AI
When dozens of applicants list Node.js on their resume, an AI interviewer can sort the people who know the event loop from those who know the buzzwords. Node.js is part of NTRVSTA's exam library, and the interviewer adjusts the difficulty in real time: a strong answer on promise ordering leads to a harder question about backpressure, while a shaky one gets a simpler follow-up. System-design prompts come with an interactive whiteboard, and a hint system shows how a candidate responds to a nudge.
Your engineers receive a score breakdown and video snippets of the moments that matter, and decide who gets the live coding round. See how AI interviews are scored and our list of top AI interview software. Related pages: JavaScript, backend developer, React and system design interview questions.
Questions
Should a Node.js interview include TypeScript questions?
If your codebase uses TypeScript, yes, a few. Ask how they type an API response they do not control, and why runtime validation is still needed when the types look correct. Keep the focus on Node behavior, since TypeScript knowledge is easier to pick up on the job.
How do I pitch these questions for a junior Node developer?
Use the event loop, async error and module questions, and score clear explanations over vocabulary. Skip the scaling and memory leak scenarios or treat them as stretch questions. Juniors who reason carefully about what blocks the event loop are worth a second round.
What setup works best for a live Node coding exercise?
A small existing project with a failing test or a slow endpoint is closer to real work than a blank file. Let candidates use their normal editor and the Node docs, agree the time limit up front, and ask them to talk through choices as they go.
Hiring Node developers and short on engineer time for first calls? Book a 20-minute demo, or try the sample interview and see the questions for yourself.
