Top 30 Node.js Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   Why did moving the apps into workspace packages under services/* initially break production?

   • aThe root package.json orchestration layer masked environment variables required by the OAuth worker at runtime
   • bNx build caching invalidated Docker layer caches and caused container startup failures
   • cNode enforced package boundaries, exposing invalid import aliases and hardcoded paths that assumed the old root-relative layout
   • dConsolidating three lockfiles into one root package-lock.json introduced conflicting transitive dependency versions
   Show the answer

   Answer: c · Node enforced package boundaries, exposing invalid import aliases and hardcoded paths that assumed the old root-relative layout

   Node began enforcing package boundaries after the move, so an import alias that reached outside the services/site boundary failed with ERR_INVALID_PACKAGE_TARGET and a hardcoded MDX fetch path pointed to the wrong location. Option D is tempting because lockfile consolidation produced most of the diff, but the outage was caused by path assumptions, not dependency conflicts.

   Read the full bite: Kent C. Dodds Fixes Accidental Monorepo with Workspaces

2. Question 2 of 30

   What is the primary benefit of splitting a CPU-intensive synchronous operation into smaller pieces using setTimeout(fn, 0)?

   • aTo ensure the entire operation completes faster by leveraging asynchronous execution.
   • bTo allow the browser to process UI updates and user input between task segments.
   • cTo execute each piece of the task in parallel, improving overall performance.
   • dTo guarantee that each piece runs immediately after the previous one, without any delay.
   Show the answer

   Answer: b · To allow the browser to process UI updates and user input between task segments.

   The card states that splitting work with setTimeout(fn, 0) allows yielding control back to the event loop, enabling the browser to process user input and render updates, keeping the UI alive. Option A is incorrect because this technique adds overhead and does not necessarily speed up the overall execution time; its purpose is responsiveness, not raw speed.

   Read the full bite: JavaScript's Event Loop: Macrotasks & Microtasks

3. Question 3 of 30

   For which task would Node.js Worker Threads provide the most significant benefit?

   • aHandling concurrent network requests from many clients.
   • bQuerying a remote database for user profiles.
   • cProcessing a large video file to apply a filter.
   • dReading multiple files from the local filesystem.
   Show the answer

   Answer: c · Processing a large video file to apply a filter.

   Worker threads are specifically designed for CPU-bound operations like video processing to offload heavy computation from the main thread. I/O-bound tasks, such as database queries or network requests, are already efficiently managed by Node's event loop and do not benefit from worker threads.

   Read the full bite: Worker Threads: True Parallelism in Node.js

4. Question 4 of 30

   What is the primary characteristic that distinguishes the Service Layer from the Web Layer?

   • aIt handles all direct database interactions and data persistence.
   • bIt defines application routes and manages the request/response cycle.
   • cIt is responsible for validating incoming user input and sanitizing data.
   • dIt contains the core business logic, independent of HTTP specifics.
   Show the answer

   Answer: d · It contains the core business logic, independent of HTTP specifics.

   The card explicitly states the Service Layer "contains the core business logic, orchestrating tasks without knowing about HTTP," highlighting its independence from the web protocol. Option B describes the primary function of the Web Layer, which is concerned with HTTP requests and responses.

   Read the full bite: Structuring Express Apps with Layered Architecture

5. Question 5 of 30

   When is it inappropriate to use a callback in Node.js?

   • aWhen you must have a result before the next line runs
   • bWhen responding to an incoming HTTP request
   • cWhen performing a file system operation
   • dWhen handling multiple concurrent network sockets
   Show the answer

   Answer: a · When you must have a result before the next line runs

   The card explicitly warns against using callbacks when you need a result immediately before moving on, because they are designed for deferred, non-blocking execution. The other three options are all I/O scenarios where callbacks are the recommended pattern.

   Read the full bite: Node.js Callbacks: Functions That Run Later

6. Question 6 of 30

   In JavaScript's single-threaded environment, what is the main problem Promises are designed to address?

   • aTo prevent the user interface from freezing during network requests or file I/O.
   • bTo guarantee that all asynchronous operations complete in a specific, predetermined order.
   • cTo enable parallel execution of multiple CPU-bound tasks.
   • dTo automatically retry failed operations without explicit error handling.
   Show the answer

   Answer: a · To prevent the user interface from freezing during network requests or file I/O.

   Promises were created to manage asynchronous operations gracefully, allowing other code to run without blocking the main thread, which prevents the user interface from freezing during long-running tasks like network requests. Option C is incorrect because JavaScript remains single-threaded; Promises manage non-blocking I/O, not true parallel CPU execution.

   Read the full bite: JavaScript Promises: Handling Future Values

7. Question 7 of 30

   What is the fundamental mechanism by which Promise.then() enables sequential asynchronous operations?

   • aEach call to .then() returns a new promise, whose resolution depends on the preceding handler's outcome.
   • bIt attaches multiple handlers to the original promise, which then execute in a defined order.
   • cIt directly executes the next handler function only after the previous one finishes.
   • dIt gathers all promises in a chain and resolves them concurrently once all are ready.
   Show the answer

   Answer: a · Each call to .then() returns a new promise, whose resolution depends on the preceding handler's outcome.

   The core mechanism for chaining is that every .then() call creates and returns a new promise, allowing the next step in the sequence to wait for the previous one's resolution. Option C describes the outcome but not the underlying mechanism of how this sequential execution is achieved. Option B describes a common misconception where multiple handlers attached to the *same* promise execute in parallel, not sequentially.

   Read the full bite: Promise.then(): Each Call Returns a New Promise

8. Question 8 of 30

   When an await keyword is encountered inside an async function, what is its primary effect?

   • aIt forces the awaited operation to run synchronously, blocking all subsequent code in the function.
   • bIt immediately returns a new Promise from the async function, continuing the awaited operation in parallel.
   • cIt causes the entire JavaScript application to pause until the awaited Promise resolves.
   • dIt pauses the execution of the async function, allowing other tasks to run, and resumes when the Promise settles.
   Show the answer

   Answer: d · It pauses the execution of the async function, allowing other tasks to run, and resumes when the Promise settles.

   The card explains that await acts as a 'pause and resume' button for the async function, allowing the JavaScript engine to do other work while the Promise settles, thus ensuring non-blocking behavior. Option C describes a blocking scenario, which async/await is designed to prevent.

   Read the full bite: Async/Await: Write Non-Blocking Code That Reads Synchronously

9. Question 9 of 30

   What is the immediate outcome when one of the promises provided to Promise.all() rejects?

   • aThe Promise.all() promise waits for all other promises to settle before rejecting with an array of all outcomes.
   • bThe Promise.all() promise attempts to retry the rejected promise before determining its final state.
   • cThe Promise.all() promise immediately rejects with the reason of the first failed promise.
   • dThe Promise.all() promise resolves with the values of the successfully completed promises, ignoring the rejected one.
   Show the answer

   Answer: c · The Promise.all() promise immediately rejects with the reason of the first failed promise.

   Promise.all() has a 'fail-fast' behavior: if any single input promise rejects, the entire Promise.all() promise immediately rejects with the reason of that first failed promise. Option A describes the behavior of Promise.allSettled(), which waits for all promises to settle regardless of their outcome.

   Read the full bite: Promise.all(): Wait for Multiple Promises at Once

10. Question 10 of 30

    When using Promise.race() for a network request with a timeout, what is the outcome if the timeout promise rejects before the network request resolves?

    • aThe Promise.race() promise will eventually resolve with the network request's data.
    • bThe Promise.race() promise will resolve with an array of results from both promises.
    • cThe Promise.race() promise will wait for both to complete and then reject if either failed.
    • dThe Promise.race() promise will reject with the timeout's error.
    Show the answer

    Answer: d · The Promise.race() promise will reject with the timeout's error.

    Promise.race() settles with the outcome of the very first promise to settle, regardless of whether it resolves or rejects. If the timeout promise rejects first, the race() promise immediately rejects with that error. The network request's eventual resolution is ignored because it was not the first to settle.

    Read the full bite: Promise.race(): First Promise to Settle Wins

11. Question 11 of 30

    What is the primary reason to use Promise.allSettled() over Promise.all() for multiple asynchronous tasks?

    • aTo obtain a status report for every task, allowing individual handling of successes and failures.
    • bTo optimize performance by running all promises concurrently and discarding failed ones.
    • cTo ensure the entire operation fails immediately if any single task encounters an error.
    • dTo retrieve the result of the first promise that completes, whether it succeeds or fails.
    Show the answer

    Answer: a · To obtain a status report for every task, allowing individual handling of successes and failures.

    Promise.allSettled() is designed to provide an outcome for every promise in the batch, whether it fulfilled or rejected, allowing for graceful handling of partial failures. Option C describes Promise.all(), which short-circuits and rejects the entire batch if any promise fails.

    Read the full bite: Promise.allSettled(): Never Fail a Batch of Promises

12. Question 12 of 30

    Which scenario best describes when to use Promise.any()?

    • aTo wait for all promises to settle (fulfill or reject) and get their individual outcomes.
    • bTo ensure all provided promises fulfill successfully before proceeding with their combined results.
    • cTo get the value from the very first promise that either fulfills or rejects.
    • dTo retrieve the result from the first promise that successfully completes, ignoring any failures.
    Show the answer

    Answer: d · To retrieve the result from the first promise that successfully completes, ignoring any failures.

    The correct answer (D) accurately describes Promise.any()'s purpose: to get the first successful result, even if other promises fail. Option C describes Promise.race(), which settles with the first promise regardless of its outcome.

    Read the full bite: Promise.any(): Get the Fastest Successful Result

13. Question 13 of 30

    How does Top-Level Await primarily affect the loading and execution of an ES module and its dependencies?

    • aIt pauses the execution of the specific module and any modules that depend on it until the top-level promise resolves.
    • bIt allows the module to perform asynchronous setup, but only if it is imported using a dynamic import() statement.
    • cIt forces the entire application to wait for the module's asynchronous operations to complete before any other modules can load.
    • dIt converts the module into a CommonJS module, enabling require() calls to handle asynchronous dependencies.
    Show the answer

    Answer: a · It pauses the execution of the specific module and any modules that depend on it until the top-level promise resolves.

    The card states that Top-Level Await "pauses the execution of that specific module" and that "When another module imports it, the JavaScript engine effectively 'awaits' the completion of the module being imported." This means dependent modules will wait. Option C is incorrect because the card explicitly states, "it does not block the main thread for other unrelated tasks."

    Read the full bite: Top-Level Await: `await` Without an `async` Function

14. Question 14 of 30

    Which action is crucial for a Node.js HTTP server to signal that a response has been fully sent to the client?

    • aCalling server.listen() to activate the server on a port.
    • bSetting the response.statusCode to a success code like 200.
    • cInvoking response.end() on the response object.
    • dUsing response.write() to send all data chunks to the client.
    Show the answer

    Answer: c · Invoking response.end() on the response object.

    The card explicitly states that `response.end()` is critical to signal that the response is complete, otherwise the client will hang indefinitely. While `response.write()` sends data, it does not close the connection or mark the response as finished.

    Read the full bite: Creating a Basic HTTP Server in Node.js

15. Question 15 of 30

    Under which circumstance would directly using __dirname in a Node.js script result in a ReferenceError?

    • aThe path module is not explicitly required before __dirname is used.
    • bThe Node.js project is configured to use ES Module syntax (e.g., import/export).
    • cThe script attempts to access a file outside its own directory.
    • dThe script is executed using a relative path from the command line.
    Show the answer

    Answer: b · The Node.js project is configured to use ES Module syntax (e.g., import/export).

    The card explicitly states that __dirname does not exist in ES Modules, and attempting to use it in such a context will cause a ReferenceError. Other options describe scenarios that are either the problem __dirname solves or unrelated to its availability.

    Read the full bite: __dirname and __filename: Path Anchors in Node.js

16. Question 16 of 30

    Which task is the Node.js os module primarily designed to help with?

    • aInteracting with the currently running Node.js process.
    • bManaging environment variables for process configuration.
    • cConstructing platform-specific file paths.
    • dQuerying the host system's hardware and operating system details.
    Show the answer

    Answer: d · Querying the host system's hardware and operating system details.

    The os module is designed for querying static system properties and environment details like CPU cores, memory, and platform type. Tasks like managing environment variables, path manipulation, or interacting with the Node.js process itself are handled by other modules like process or path.

    Read the full bite: Node.js os Module: Reading Your System's Vital Signs

17. Question 17 of 30

    What is the primary security risk when using algorithms like MD5 or SHA1 for sensitive data hashing?

    • aThey are susceptible to collision attacks, where distinct inputs yield identical hash values.
    • bTheir fixed-size output is too small, making brute-force attacks trivial.
    • cThey are no longer supported by the Node.js crypto module.
    • dThey can be easily decrypted to recover the original sensitive data.
    Show the answer

    Answer: a · They are susceptible to collision attacks, where distinct inputs yield identical hash values.

    The card explicitly states that MD5 and SHA1 are vulnerable to 'collision attacks,' where two different inputs can produce the same hash, undermining their reliability. Hashing is a one-way process by design, so it cannot be reversed to retrieve original data, making option D incorrect for any hashing algorithm.

    Read the full bite: Hashing Data with Node.js's `crypto` Module

18. Question 18 of 30

    What is the primary negative consequence of 'Callback Hell' in JavaScript?

    • aIt forces asynchronous operations to execute synchronously, slowing down the application.
    • bIt results in deeply nested, unreadable code that is difficult to maintain.
    • cIt causes the application to block and become unresponsive during I/O operations.
    • dIt prevents the JavaScript runtime from properly executing subsequent callback functions.
    Show the answer

    Answer: b · It results in deeply nested, unreadable code that is difficult to maintain.

    Callback Hell's core problem is the 'pyramid of doom' structure, leading to deeply indented code that is 'notoriously difficult to read and maintain.' It does not block the application; JavaScript's asynchronous model prevents that.

    Read the full bite: Callback Hell: Navigating JavaScript's Async Pyramid

19. Question 19 of 30

    Which scenario is most likely to cause a functional issue immediately after adding app.use(helmet()) to an Express app without further configuration?

    • aThe application implements custom authentication logic.
    • bThe application is running in a local development environment without HTTPS.
    • cThe application handles sensitive user data.
    • dThe application loads scripts or styles from external domains like CDNs.
    Show the answer

    Answer: d · The application loads scripts or styles from external domains like CDNs.

    The default Content-Security-Policy (CSP) in Helmet is very strict, only allowing resources from the same origin ('self'). This will block common external resources like scripts from CDNs or Google Fonts, causing functional issues until the CSP is explicitly configured. While running without HTTPS can cause issues with 'upgrade-insecure-requests', the card highlights CSP configuration for external resources as the primary and most common 'footgun'.

    Read the full bite: Helmet.js: Secure Express Apps with HTTP Headers

20. Question 20 of 30

    Which change to an API would most likely necessitate creating a new version?

    • aOptimizing the database query for an existing endpoint to improve speed.
    • bAdding a new, optional field to an existing response payload.
    • cIntroducing a completely new endpoint to handle a new business process.
    • dSplitting a single 'address' field into 'street', 'city', and 'zipCode' fields.
    Show the answer

    Answer: d · Splitting a single 'address' field into 'street', 'city', and 'zipCode' fields.

    The card states that 'breaking changes' alter data structures or endpoint behavior, citing splitting a 'fullName' field as an example. Splitting an 'address' field is analogous, requiring clients to adapt to new fields. Adding optional fields or new endpoints are non-breaking changes, and performance optimizations do not alter the API contract.

    Read the full bite: API Versioning: Managing Change Without Breaking Clients

21. Question 21 of 30

    Given its synchronous API and embedded design, which workload is node:sqlite best suited for?

    • aA distributed system where multiple servers write to the same database file concurrently
    • bA video streaming service requiring non-blocking database access for each request
    • cA local CLI utility that logs events to a file without extra npm dependencies
    • dA high-traffic e-commerce API processing hundreds of checkouts per second
    Show the answer

    Answer: c · A local CLI utility that logs events to a file without extra npm dependencies

    node:sqlite is designed for lightweight, local structured storage such as CLI tools that avoid external dependencies, whereas a high-traffic API is a poor fit because DatabaseSync executes synchronously and blocks the event loop.

    Read the full bite: Node.js Built-in SQLite Driver

22. Question 22 of 30

    In an error-first callback, what is the specific purpose of the very first argument?

    • aTo define the context (this) for the callback's execution.
    • bTo manage the flow control for subsequent asynchronous operations.
    • cTo provide the successful data returned by the asynchronous task.
    • dTo signal the presence of an error or the successful completion of the task.
    Show the answer

    Answer: d · To signal the presence of an error or the successful completion of the task.

    The card states that the first parameter is "always an Error object (or null if no error occurred)," which means it signals whether an error occurred or if the task completed successfully. Option C is incorrect because successful data is passed in subsequent arguments, not the first.

    Read the full bite: Error-First Callbacks: Node.js's Original Async Handler

23. Question 23 of 30

    What is the primary benefit of implementing custom error classes in an application, especially for APIs?

    • aThey reduce the need for try...catch blocks by handling errors implicitly.
    • bThey simplify error messages by standardizing them across the application.
    • cThey automatically prevent the application from crashing when an error occurs.
    • dThey allow for reliable, type-based differentiation of failure modes, enabling specific responses.
    Show the answer

    Answer: d · They allow for reliable, type-based differentiation of failure modes, enabling specific responses.

    The card emphasizes that custom error classes provide explicit, typed categories for failures, allowing consuming code (like API middleware) to reliably differentiate between various failure types (e.g., using 'instanceof') and send appropriate responses. While preventing crashes is a goal of error handling, it's not the primary, unique benefit of *custom* error classes over generic ones, which also allow for caught errors.

    Read the full bite: Custom Error Classes: Beyond Generic Errors

24. Question 24 of 30

    What is the fundamental benefit of using Joi for data validation over writing custom imperative checks?

    • aIt guarantees faster execution of validation rules due to optimized internal algorithms.
    • bIt integrates directly with database schemas, ensuring data consistency across the application layers.
    • cIt enables a declarative approach to defining data structures, enhancing readability and maintainability.
    • dIt automatically cleanses data, protecting against common injection attacks like XSS.
    Show the answer

    Answer: c · It enables a declarative approach to defining data structures, enhancing readability and maintainability.

    Joi's primary advantage is replacing error-prone, repetitive imperative validation with a readable, declarative schema that acts as a blueprint for data. Option D is incorrect because the card explicitly states Joi is for validation, not sanitization against attacks like XSS.

    Read the full bite: Joi: Declarative Schemas for Data Validation

25. Question 25 of 30

    What is Supertest's core mechanism for simplifying Node.js API testing?

    • aIt provides an in-memory simulation of the HTTP request-response cycle.
    • bIt automatically generates mock data for all API responses.
    • cIt replaces traditional HTTP clients with a faster, built-in alternative.
    • dIt spins up a new, fully isolated HTTP server process for each test.
    Show the answer

    Answer: a · It provides an in-memory simulation of the HTTP request-response cycle.

    Supertest simplifies API testing by simulating the entire HTTP request-response cycle directly in-memory, interacting with the application's router. Option D is incorrect because Supertest's primary goal is to avoid the boilerplate of managing separate server processes, operating in-process instead.

    Read the full bite: Supertest: Test Node.js APIs Without the Boilerplate

26. Question 26 of 30

    When would you use a Mock over a Stub or Spy?

    • aWhen you need to verify that a specific interaction with a dependency occurred as expected.
    • bWhen you need to record all calls to a dependency for later inspection without prior expectations.
    • cWhen you need to provide a predictable return value for a dependency.
    • dWhen you want to replace a complex dependency with a simpler, in-memory version.
    Show the answer

    Answer: a · When you need to verify that a specific interaction with a dependency occurred as expected.

    Mocks are specifically used for verifying interactions with dependencies, often with pre-defined expectations about how they should be called. While Spies also record calls for later inspection, Mocks are designed for direct verification of expected interactions, making option A the correct choice. Option B describes the primary use case for a Spy.

    Read the full bite: Test Doubles: Mocks, Stubs, and Spies

27. Question 27 of 30

    Which characteristic is the primary reason for advocating a limited and strategic use of End-to-End (E2E) tests?

    • aTheir execution is slow, they can be brittle, and debugging failures is complex.
    • bThey are most effective at catching bugs in individual UI components.
    • cThey cannot accurately simulate real user interactions across multiple services.
    • dThey are designed to test only isolated backend API endpoints.
    Show the answer

    Answer: a · Their execution is slow, they can be brittle, and debugging failures is complex.

    The card explicitly states that E2E tests are slow to run, can be flaky, and are difficult to debug, making them unsuitable for widespread use. While E2E tests involve the UI, their main purpose is to verify the entire integrated system, not individual UI components.

    Read the full bite: E2E Testing: The Final Check, Not The Whole Strategy

28. Question 28 of 30

    Why should you copy package.json before copying the rest of the app code in a Dockerfile?

    • aIt ensures dependencies are installed in the correct order.
    • bIt prevents node_modules from being bloated.
    • cIt is a Docker requirement; the build fails otherwise.
    • dIt allows Docker to cache the dependency layer; if only app code changes, dependencies are not reinstalled.
    Show the answer

    Answer: d · It allows Docker to cache the dependency layer; if only app code changes, dependencies are not reinstalled.

    Docker layer caching works by matching command inputs. If package.json hasn't changed, the RUN npm ci layer is cached and reused. Copying all code first would invalidate the cache on any code change, forcing a full reinstall every time. This separation optimizes build speed dramatically.

    Read the full bite: What are key Dockerfile steps for Node.js Express apps?

29. Question 29 of 30

    Why is it critical that output encoding for XSS prevention is context-aware?

    • aEncoding must be applied at the server-side, before any client-side processing occurs.
    • bTo reduce the amount of data transmitted, improving network efficiency.
    • cDifferent output locations (like HTML body vs. script tag) interpret special characters differently.
    • dIt ensures that the data is always displayed exactly as the user originally typed it.
    Show the answer

    Answer: c · Different output locations (like HTML body vs. script tag) interpret special characters differently.

    The correct answer is B because browsers interpret special characters differently depending on whether they are in an HTML tag, an attribute, or a script block, requiring specific encoding for each context. Option D is a common misconception, as encoding modifies characters to prevent execution, not to preserve their literal form if it's malicious.

    Read the full bite: XSS Prevention: Context-Aware Output Encoding

30. Question 30 of 30

    Which practice primarily prevents sensitive API keys from being accidentally exposed via version control in a Node.js application?

    • aHashing the API keys before they are used by the application's logic.
    • bStoring them in a .env file and ensuring .env is listed in .gitignore.
    • cConfiguring the server to disable detailed error messages in production environments.
    • dEncrypting the API keys directly within the application's JavaScript files.
    Show the answer

    Answer: b · Storing them in a .env file and ensuring .env is listed in .gitignore.

    Storing sensitive data like API keys in a .env file and excluding it from version control via .gitignore is the recommended method to prevent accidental exposure, as highlighted in the canonical example. Encrypting keys within source files (D) or hashing them (A) does not prevent their initial exposure if the files are committed, and hashing is typically for passwords. Disabling verbose error messages (C) prevents information leakage but not exposure of secrets in version control.

    Read the full bite: Preventing Sensitive Data Exposure in Node.js