Node.js Interview Questions

What should you focus on for a Node.js interview?

Which topics should you check first?

Architecture appeared in 24 of 64 interviews. Basics and async work each appeared in 19 of 64 interviews. Check both how Node.js works and how you would organize a backend.

The most asked question was what Node.js is, how it works, and what it is used for. CommonJS versus ES modules followed.

• Can you explain what Node.js is used for and how it differs from JavaScript in a browser?
• Can you explain the difference between CommonJS and ES modules, including require and import?
• Can you explain what npm and the package files do in a Node.js project?

Can you explain how async work runs?

Questions covered the event loop, task scheduling, concurrent requests, and nonblocking work. Check whether you can explain how work runs, not just define each term.

• Can you describe the event loop's phases and queues?
• How does scheduling differ between Promises, queueMicrotask, setTimeout, and setImmediate?
• How does Node.js handle concurrent requests when JavaScript runs on a single thread?
• What does nonblocking mean, and where does the thread pool fit?

Can you walk through a backend request?

Use a request walkthrough to check your answers about APIs, project structure, databases, and security. Questions also covered NestJS, Strapi, design patterns, and choosing between backend technologies.

• Where do routing, middleware, and validation fit in the request lifecycle?
• How would you separate routes, controllers, services, models, and database access?
• Can you explain a backend technology choice and how you would structure the project?
• How would you use connection pools and transactions, and keep concurrent writes correct?
• How does authentication differ from authorization?

Can you handle heavy work and errors?

Questions covered CPU-bound work, scaling, file processing, and production problems. Check whether you can explain what you would do in each case.

• How would you compare worker threads, processes, and clustering for CPU-bound work and using multiple cores?
• How would you make async route failures reach central Express error handling?
• How would you handle backpressure when a stream feeds work faster than it can finish?
• How would you investigate latency or memory problems?
• How would you handle graceful shutdown?

What code can you try writing?

Coding tasks appeared in 2 of 64 interviews. Use the recorded tasks to check whether you can turn your explanation into code:

• In a Node.js and TypeScript service, process an array of 1,000 items with at most five parallel async tasks. Keep the code maintainable.
• Write Express middleware that rejects a request when a required header is missing.

Who gets asked Node.js

The 20 most asked Node.js questions

Counted by interview, not by mention: a question asked twice in one conversation counts once.

1. What is Node.js, how does it work, and what is it used for?

   Asked in 8 of 64 interviews · last asked Sep 19 · Concept · Junior

   Show answer

   Node.js is a runtime that runs JavaScript outside the browser, using Google's V8 engine. It uses an event loop and non-blocking I/O to handle many requests without waiting for each operation to finish. It is commonly used for web servers, APIs, real-time apps, and command-line tools.

   • JavaScript callbacks normally run on one main thread; some work uses operating system support or a thread pool.
   • It works well for apps that spend much of their time waiting for network or file operations.
   • Heavy CPU work can block the event loop; worker threads or separate processes can handle it.

   What the interviewer checks: The interviewer is checking whether you understand the runtime, its event loop, and where it fits best.

   Other ways it was asked

   • “What is Node.js?”
   • “Can you explain what Node.js is?”
   • “What is Node.js? Explain it.”

2. How do CommonJS and ES modules differ, including require and import?

   Asked in 7 of 64 interviews · last asked Oct 19 · Concept · Junior

   Show answer

   CommonJS uses `require()` and `module.exports`; ES modules use `import` and `export`. `require()` loads modules synchronously at runtime, while static imports are linked before execution and expose live bindings. Dynamic `import()` returns a promise and works in both module systems.

   • `.cjs` marks CommonJS; `.mjs` marks ES modules.
   • Set `"type": "module"` in package.json to explicitly treat `.js` files as ES modules.
   • Static imports must be top-level; `require()` and dynamic `import()` can run inside functions or conditions.
   • Recent Node.js versions can require ES modules only when their dependency graph has no top-level await.

   JavaScriptCopy

   // math.cjs
   module.exports = { add: (a, b) => a + b };
   // app.cjs
   const { add } = require('./math.cjs');
   // math.mjs
   export const add = (a, b) => a + b;
   // app.mjs
   import { add } from './math.mjs';

   What the interviewer checks: The interviewer checks whether you understand module syntax, loading behavior, and how Node.js selects a module system.

   Other ways it was asked

   • “What is the difference between require and import in Node.js?”
   • “Could you clarify the syntax differences between require and import, and explain how their loading mechanisms affect module behavior in Node.js?”
   • “What is the difference between `require` and `import` in Next.js?”

3. How does the Node.js event loop work, including its phases and queues?

   Asked in 4 of 64 interviews · last asked Sep 22 · Concept · Mid-level

   Show answer

   The Node.js event loop runs JavaScript callbacks on one thread while I/O can finish in the background. Its phases are timers, pending callbacks, idle/prepare (internal), poll, check, and close callbacks. Each phase handles specific work or callbacks; poll can wait for I/O. Blocking JavaScript delays other callbacks.

   • Timers handle setTimeout and setInterval callbacks; delays are minimum waits, not exact schedules.
   • Poll handles I/O callbacks; check runs setImmediate; close handles callbacks such as a socket's 'close' event.
   • Between callbacks, nextTick usually runs before Promise microtasks; ES module top-level ordering differs.
   • Since libuv 1.45 (used in Node.js 20), timers run only after poll, not before and after.

   What the interviewer checks: The interviewer checks whether you understand non-blocking I/O, callback ordering, and why long-running JavaScript blocks progress.

   Other ways it was asked

   • “What is the role of the event loop in Node.js?”
   • “What is the event loop structure of Node.js?”
   • “Could you explain how the Node.js event loop works and why it's crucial for handling non-blocking I/O?”

4. In Node.js, what's the practical difference between the event loop's microtask queue (Promises and queueMicrotask) and macrotask queue (setTimeout and setImmediate), and when would you choose one over the other?

   Asked in 3 of 64 interviews · last asked Aug 11 · Concept · Senior

   Show answer

   Promise callbacks and queueMicrotask run after current JavaScript finishes, before the event loop continues. setTimeout and setImmediate run in event-loop phases, not one shared queue. Use microtasks for small follow-up work, setImmediate to yield between work chunks, and setTimeout when a delay is needed.

   • Microtasks drain before normal event-loop work resumes; continuously adding them can delay I/O and increase latency.
   • process.nextTick uses a separate queue, not the Promise microtask queue; it can also starve I/O.
   • setTimeout uses the timers phase; setImmediate uses the check phase after polling for I/O.
   • Timer delays are minimum thresholds; top-level ordering between setTimeout(fn, 0) and setImmediate is not guaranteed.

   What the interviewer checks: The interviewer checks whether you understand scheduling order and can choose callbacks without blocking I/O progress.

   Other ways it was asked

   • “In Node.js, what's the difference between the microtask queue (promises and process.nextTick) and the macrotask queue (setTimeout and setImmediate), and how can this affect production latency?”
   • “In JavaScript's event loop, how do microtasks (promises) and macrotasks (setTimeout) differ in scheduling, and what's the practical impact on execution order?”

5. How does Node.js handle concurrent requests and asynchronous work if JavaScript runs on a single thread?

   Asked in 3 of 64 interviews · last asked Aug 24 · Concept · Mid-level

   Show answer

   Node.js handles concurrent requests by starting asynchronous work without waiting for it to finish. The operating system handles network I/O, while libuv’s thread pool handles work such as many file operations. The event loop runs JavaScript callbacks when work completes. CPU-heavy JavaScript still blocks that thread unless moved to worker threads or separate processes.

   • JavaScript callbacks run one at a time on each event loop thread.
   • Concurrent requests can wait for I/O without blocking other requests.
   • Not every asynchronous operation uses a thread from the libuv pool.
   • Using async/await does not move CPU-heavy JavaScript to another thread.

   What the interviewer checks: The interviewer checks whether you can separate JavaScript execution, asynchronous I/O, and parallel CPU work.

   Other ways it was asked

   • “How can Node.js handle thousands of concurrent requests if JavaScript is single-threaded?”
   • “How do Node.js’s event loop and concurrency help your API stay responsive with multiple concurrent users?”
   • “How does Node.js handle multithreading and asynchronous operations through the event loop despite being single-threaded?”

6. How do you structure a Node.js backend to separate routes, controllers, services, models, and database access?

   Asked in 3 of 64 interviews · last asked Sep 13 · Design · Mid-level

   Show answer

   I separate the backend by responsibility: routes map URLs to controllers, controllers handle HTTP input and responses, and services hold business logic. Models define data structures, while repositories handle database queries. A shared database module manages the connection pool or client. I keep HTTP details out of services so they are easier to test and reuse.

   • Routes attach middleware and call controllers; controllers call services.
   • Services enforce business rules and use repositories for data access.
   • Models define schemas or entities; some ORMs also give models database methods.
   • Initialize the database client or pool centrally, not once per request.

   CodeCopy

   src/
     routes/        # URLs and middleware
     controllers/   # HTTP input and responses
     services/      # Business rules
     models/        # Schemas or entities
     repositories/  # Database queries
     db/            # Database client or pool
     app.js         # Configure Express and routes
     server.js      # Start server and handle shutdown

   What the interviewer checks: The interviewer checks whether you can separate responsibilities and keep database access and business logic easy to test.

   Other ways it was asked

   • “In Node.js/Express, how would you structure a REST API project’s folders or modules to keep routes, controllers, services, and data access cleanly separated?”
   • “How do you structure your Node.js backend?”
   • “How do you structure a Node.js backend project, including controllers, models, and database connections?”

7. How do you use multiple CPU cores on a single server with Node.js?

   Asked in 3 of 64 interviews · last asked Oct 8 · Concept · Mid-level

   Show answer

   Run multiple Node.js processes on the same server using the cluster module or a process manager such as PM2. These processes can handle requests across CPU cores. For CPU-heavy JavaScript work, use a pool of worker threads so the main event loop stays responsive.

   • Cluster workers are separate processes and can share a server port.
   • Worker threads run JavaScript in parallel and can share memory.
   • Keep shared session data outside individual processes, such as in Redis.
   • Size the process or thread pool for available CPUs and memory; measure performance.

   What the interviewer checks: The interviewer checks whether you can spread work across cores and choose between processes and worker threads.

   Other ways it was asked

   • “How do you use more CPU cores in Node.js?”
   • “How can you use all CPU cores in a Node.js application?”
   • “If a Node.js application uses only one core on a 128-core server, how can you use the other cores without horizontal scaling?”

8. How do you centralize Express error handling and ensure async route failures reach it?

   Asked in 3 of 64 interviews · last asked Aug 15 · Tooling · Mid-level

   Show answer

   Centralize errors in one middleware with four arguments, registered after all routes, and return a consistent error response. In Express 4, catch async route failures and pass them to next(err), usually through a wrapper. Express 5 automatically forwards rejected promises returned by route handlers.

   • Error middleware must use the signature (err, req, res, next), with all four arguments.
   • Callback-based errors still need next(err); detached promises are not caught automatically.
   • If response headers were already sent, delegate with next(err) instead of sending another response.
   • Use appropriate HTTP status codes, log unexpected errors, and keep internal details out of responses.

   JavaScriptCopy

   const express = require('express');
   const app = express();
   const wrap = fn => (req, res, next) => Promise.resolve().then(() => fn(req, res, next)).catch(next);
   app.get('/demo', wrap(async () => { throw new Error('Failed'); }));
   app.use((err, req, res, next) => {
     if (res.headersSent) return next(err);
     console.error(err);
     res.status(500).json({ error: 'Internal server error' });
   });
   app.listen(3000);

   What the interviewer checks: The interviewer checks whether you can route errors safely to one handler and understand Express version differences.

   Other ways it was asked

   • “How do you implement centralized error handling in an Express app so route handlers stay clean, and how do you ensure async errors reliably reach that handler?”
   • “How do you handle error propagation and consistent HTTP error responses across an Express app, including async route handlers?”
   • “In Node.js with Express, how do you structure error handling so async route failures return consistent responses and don't crash the process?”

9. What does nonblocking mean in Node.js?

   Asked in 2 of 64 interviews · last asked Oct 19 · Concept · Mid-level

   Show answer

   Nonblocking means Node.js can start an operation, such as reading a file, without making the JavaScript thread wait for it to finish. Other code can run while the operation is pending. Blocking code keeps that thread busy until it finishes, delaying other work.

   • Nonblocking operations report completion through callbacks or promises.
   • Synchronous file operations and long CPU tasks block the event loop.
   • Using async or promises does not make CPU-heavy code nonblocking.

   What the interviewer checks: The interviewer checks whether you understand how blocking code delays other requests on the event loop.

   Other ways it was asked

   • “What is the difference between blocking and non-blocking code in Node.js?”

10. What are asynchronous operations in Node.js?

    Asked in 2 of 64 interviews · last asked Aug 20 · Concept · Junior

    Show answer

    Asynchronous operations in Node.js let the calling code continue without waiting for the operation to finish. Results or errors are handled later through callbacks, promises, or async/await. Synchronous operations make the calling code wait until they finish.

    • Common examples include reading files, making network requests, and waiting for timers.
    • The event loop runs JavaScript callbacks when their work is ready.
    • await pauses its async function, not the whole JavaScript thread.
    • Marking a function async does not make CPU-heavy code non-blocking.

    What the interviewer checks: The interviewer checks whether you understand waiting, non-blocking execution, and how asynchronous results are handled.

    Other ways it was asked

    • “Can you clarify what exactly makes an operation asynchronous in Node.js and how it differs from synchronous ones?”

11. Why is Node.js single-threaded?

    Asked in 2 of 64 interviews · last asked Sep 18 · Concept · Mid-level

    Show answer

    Node.js runs JavaScript on one main thread by default, but it is not entirely single-threaded. Its event loop handles many requests using non-blocking I/O, without a separate thread for each request. This simplifies handling shared data, but CPU-heavy JavaScript can block the main thread.

    • The operating system and libuv thread pool handle asynchronous work; not every operation uses the pool.
    • Worker threads let JavaScript run in parallel for CPU-heavy tasks.
    • Non-blocking I/O lets other requests make progress while waiting for data.

    What the interviewer checks: The interviewer checks whether you understand the difference between JavaScript execution, I/O concurrency, and parallel work.

    Other ways it was asked

    • “Is Node.js single-threaded or multi-threaded?”

12. Can you explain what middleware is in Express.js and give some examples?

    Asked in 2 of 64 interviews · last asked Oct 7 · Concept · Junior

    Show answer

    Middleware in Express.js is a function that runs during request handling. It can read or change the request and response, end the response, or call next() to pass control to the next handler. Common uses include logging, authentication, parsing request bodies, and handling errors.

    • Middleware runs in registration order, so placement matters.
    • Built-in middleware includes express.json() and express.static(); external examples include cors and morgan.
    • Call next() to continue, or send a response; otherwise, the request can hang.
    • Error middleware has four parameters: (err, req, res, next); next(err) passes control to error handlers.

    JavaScriptCopy

    const express = require('express');
    const app = express();
    app.use(express.json());
    app.use((req, res, next) => {
      console.log(req.method, req.path);
      next();
    });
    app.get('/', (req, res) => res.send('Hello'));
    app.listen(3000);

    What the interviewer checks: The interviewer is checking whether you understand request flow, middleware order, and suitable middleware tasks.

    Other ways it was asked

    • “What are some examples of external middleware used in Express.js applications?”
    • “How does middleware work in Express, and what kinds of tasks are appropriate to implement as middleware?”

13. What is Express.js, and what is it used for?

    Asked in 2 of 64 interviews · last asked Apr 16 · Concept · Junior

    Show answer

    Express.js is a web framework for Node.js. It is used to build web servers and APIs by defining routes and handling HTTP requests and responses. It also supports middleware for tasks such as reading JSON, checking access, and handling errors.

    • Routes connect HTTP methods and URL paths to handler functions.
    • Middleware runs in order to process requests and responses.
    • Express adds web features on top of Node.js; it is not a separate runtime.

    What the interviewer checks: The interviewer is checking whether you understand how Express helps Node.js handle web requests.

    Other ways it was asked

    • “What is Express.js?”

14. What is NestJS?

    Asked in 2 of 64 interviews · last asked Sep 8 · Concept · Junior

    Show answer

    NestJS is a framework for building server-side applications with Node.js. It supports TypeScript and organizes code into modules, controllers, and providers. It uses dependency injection to connect these parts, making code easier to test and maintain. It uses Express by default and also supports Fastify.

    • Modules group related parts of the application.
    • Controllers handle incoming requests; providers usually contain business logic or shared services.
    • Dependency injection supplies the objects a class needs.
    • Express is the default HTTP platform; Fastify is an alternative.

    What the interviewer checks: The interviewer is checking whether you understand NestJS’s purpose, basic structure, and relationship to Node.js.

    Other ways it was asked

    • “How does NestJS work?”

15. How do ASP.NET Core and Node.js with Express compare, and when would you choose each?

    Asked in 2 of 64 interviews · last asked Oct 19 · Concept · Senior

    Show answer

    ASP.NET Core is a full web framework, usually used with C#; Express is a small web framework for Node.js. I would choose ASP.NET Core for its built-in features or a team experienced in .NET. I would choose Express for a JavaScript or TypeScript team wanting a flexible setup. Both handle large applications; the choice depends on team skills and requirements.

    • ASP.NET Core includes dependency injection and authentication support; Express relies more on middleware and added packages.
    • Both support asynchronous I/O and run across platforms.
    • CPU-heavy work blocks Node.js's event loop unless moved to workers or separate services.
    • Compare real workloads and maintenance needs, not claims that one is always faster.

    What the interviewer checks: The interviewer checks whether you can compare practical trade-offs and choose based on the application and team.

    Other ways it was asked

    • “How do you feel about the differences working with .NET versus Express/Node from your perspective?”
    • “Why would you choose ASP.NET Core over Node.js?”
    • “Which would you recommend for this application, ASP.NET Core or Express.js, and why?”

16. How would you implement per-user rate limiting in a Node.js API?

    Asked in 2 of 64 interviews · last asked Sep 17 · Design · Mid-level

    Show answer

    I would authenticate the request, then limit requests using the verified user ID as the key. I would store counters in Redis so all API instances share the same limit. For example, allow 100 requests per minute and return HTTP 429 with a Retry-After header when the limit is reached.

    • Run the limiter after authentication; never trust a user ID supplied directly by the client.
    • Use atomic Redis operations and expiration to keep shared counters correct.
    • Fixed windows are simple but allow bursts near window boundaries.
    • Decide whether requests should fail or continue if Redis is unavailable.

    JavaScriptCopy

    import { rateLimit } from 'express-rate-limit';
    import { RedisStore } from 'rate-limit-redis';
    import { createClient } from 'redis';
    const redis = createClient({ url: process.env.REDIS_URL });
    redis.on('error', console.error);
    await redis.connect();
    export const userRateLimit = rateLimit({
      windowMs: 60_000, limit: 100, keyGenerator: (req) => String(req.user.id),
      store: new RedisStore({ sendCommand: (...args) => redis.sendCommand(args) }),
      standardHeaders: 'draft-8', legacyHeaders: false });

    What the interviewer checks: The interviewer is checking whether you can identify users safely and enforce consistent limits across multiple API instances.

    Other ways it was asked

    • “Imagine you're building an API in Node.js that needs to handle rate limiting for different users. How would you design that solution?”
    • “Can you implement rate limiting in Node.js?”

17. How do you handle CPU-bound tasks in Node.js without blocking the event loop?

    Asked in 2 of 64 interviews · last asked Oct 7 · Scenario · Mid-level

    Show answer

    I move CPU-heavy JavaScript to worker threads or separate processes so the main event loop stays free. For repeated tasks, I use a worker pool to limit concurrency and avoid creating a worker for every request. For long jobs in Express, I can queue the work and return a job ID.

    • Worker threads run JavaScript in parallel without blocking the main event loop.
    • Using async/await or a Promise alone does not move CPU work off the main thread.
    • Limit worker count and queue size to avoid exhausting CPU and memory.
    • Handle worker errors and timeouts; separate processes provide stronger isolation.

    What the interviewer checks: The interviewer checks whether you can keep requests responsive while safely running CPU-heavy work.

    Other ways it was asked

    • “In Node.js, how would you handle a scenario where you expect a CPU bound task?”
    • “How would you handle heavy processing in Express, since it is single-threaded?”

18. How would you diagnose and fix a Node.js memory issue, including identifying a memory leak?

    Asked in 2 of 64 interviews · last asked Jul 27 · Scenario · Senior

    Show answer

    I would compare memory, traffic, p95 latency, and garbage collection activity over time. Under steady load, a rising heap baseline after garbage collection suggests a leak. I would compare heap snapshots and inspect which objects keep growing and what retains them. Then I would fix unwanted references and repeat the load test to check memory and latency stabilize.

    • Track heap usage, RSS, and external memory separately; growing RSS alone does not prove a JavaScript leak.
    • Check unbounded caches, event listeners, timers, and request data kept after requests finish.
    • Take snapshots on a safe replica: capturing them pauses execution and can exhaust memory.
    • Bound caches and remove unused references; increasing the heap limit does not fix a leak.

    What the interviewer checks: The interviewer checks whether you can distinguish load-related growth from a leak, find retained objects, and verify a fix.

    Other ways it was asked

    • “How would you diagnose and resolve a Node.js memory issue?”
    • “Suppose you see rising p95 latency and memory in a Node.js API over several hours with no deploys. What is your step-by-step approach to confirm a memory leak and pinpoint the source?”

19. How is Node.js different from JavaScript in the browser?

    Asked once · last asked Mar 26 · Concept · Junior

    Show answer

    Node.js runs JavaScript outside the browser, often on a server. Both run the same language, but provide different APIs. Browsers provide the DOM to work with web pages. Node.js provides APIs for files, processes, and servers, but has no built-in browser DOM.

    • JavaScript is the language; Node.js is a runtime that runs it.
    • Browsers restrict file and system access; Node.js can access them within operating system permissions.
    • Both support asynchronous work, but their event loops and available APIs differ.

    What the interviewer checks: The interviewer checks whether you can separate the JavaScript language from the features provided by its runtime.

20. What is package-lock.json used for, and how does it differ from package.json?

    Asked once · last asked Apr 8 · Concept · Junior

    Show answer

    package-lock.json records the exact dependency versions and dependency tree so npm can repeat an installation. package.json describes the project, its scripts, and its direct dependencies, usually with allowed version ranges. The lock file also records indirect dependencies. Commit both files, and use npm ci for clean installs that follow the lock file.

    • package.json declares what the project needs; package-lock.json records the resolved dependency tree.
    • The lock file helps keep dependency versions consistent across developers and CI.
    • npm ci fails if the files disagree; it does not update the lock file.

    What the interviewer checks: The interviewer checks whether you understand dependency declarations, locked versions, and repeatable installs.

Live coding round next? Coding mode in the MeetAssist desktop app solves the problem on your screen, with your phone as the remote.

Related interview questions

• Software Engineer interview questions
• IT Support and Help Desk interview questions
• Solutions Architect interview questions
• Cloud Engineer interview questions
• Data Engineer interview questions
• QA Engineer interview questions
• React interview questions
• Angular interview questions
• Next.js interview questions
• HTML and CSS interview questions
• Spring Boot interview questions
• Android and Kotlin interview questions
• iOS and Swift interview questions

How this list is made

Every question here was asked by a real interviewer in a real job interview that a candidate ran MeetAssist in. After the call, the interviewer's questions are pulled from the transcript. Practice sessions, tests, exams and anything that was not a job interview are dropped.

Questions are rewritten so they make sense on their own: names of people, employers and clients are removed, and speech-to-text mistakes are fixed. Small talk, logistics and questions about one candidate's own résumé are left out. Rephrasings of the same question are merged, and the count is the number of different interviews it came up in.

The interviews come from candidates who use MeetAssist, so they lean towards software, data and AI roles: the shares describe these interviews, not every Node.js interview. Answers to the most asked questions are written and checked by an editor; a "common mistake" is shown only when reviews of real answers in these interviews show it, with the count.

64 interviews, 53 candidates, Dec 2025 to Oct 2026. Updated every month with new interviews.