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. Junior: core theory, definitions, and simple practical cases.
Node runs your JavaScript on one thread and hands I/O to the operating system, picking up the results as callbacks when they are ready. Single-threaded means your code never runs in two places at once — but the waiting happens elsewhere, which is why Node handles thousands of idle connections cheaply. The consequence to remember: a slow loop in your code blocks every request, not just the one it belongs to.
They are the same mechanism at three levels of ergonomics. A callback is a function called on completion and nests badly. A promise is an object representing a future value that can be chained. async/await is syntax over promises that lets you write sequential-looking code. What does not change is the underlying model — await does not block the thread, it yields.
The function continues immediately with a pending promise instead of the value, so you get undefined behaviour downstream, and any error inside becomes an unhandled rejection that can take the process down. The most common shape is a database write that appears to succeed because nobody waited to find out it failed. Linters catch this and the rule is worth turning on.
With try/catch around the await, because a rejected promise inside an async function behaves like a thrown error. What does not work is try/catch around a callback-based call — the callback runs later, outside the block. In Express, errors from async handlers must be passed to next() or the request hangs until it times out.
Dependencies are needed to run the application, devDependencies only to build and test it. The distinction matters when the production image installs with --omit=dev: putting a build tool in the wrong place either bloats the image or breaks the build. The related question is package-lock — commit it, because it is what makes two installs produce the same tree.
A function that receives the request, the response and next, and either handles the request or passes it along. Order is everything: authentication placed after the route it protects does nothing, and an error handler must be registered last to catch what comes before it. Forgetting to call next() is the classic bug, and the symptom is a request that never answers.
Environment variables come from outside the code, so the same build can run in staging and production with different values, and secrets never enter the repository. A config file is convenient and versioned, which is exactly why credentials must not live in one. The practical setup is a schema that validates the variables at startup, so a missing one fails immediately rather than at the first request.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Junior Node.js Backend interview →