Top 30 Advanced Node.js & Express 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

   When module B requires module A in the middle of A's own loading, what does B receive?

   • aA freshly re-executed copy of A's exports
   • bAn error, since CommonJS forbids cycles
   • cA's exports object as populated so far, possibly incomplete
   • dAn empty object that updates synchronously when A finishes
   Show the answer

   Answer: c · A's exports object as populated so far, possibly incomplete

   CommonJS caches the exports object at load start and returns it as-is, so B gets whatever A has assigned up to that point. It is not re-executed, does not throw, and the reference is not retroactively backfilled.

   Read the full bite: Circular dependencies in CommonJS modules

2. Question 2 of 30

   Why can two installed major versions of the same library cause instanceof checks to fail across packages?

   • aThe older version overwrites the newer version's prototypes
   • bEach copy is a distinct module instance with its own classes, so cross-copy instanceof returns false
   • cinstanceof never works in Node with hoisted dependencies
   • dnpm strips prototype chains during install
   Show the answer

   Answer: b · Each copy is a distinct module instance with its own classes, so cross-copy instanceof returns false

   Two physical copies are separate module instances with separate class identities, so an object from one copy is not an instance of the other copy's class. npm does not strip prototypes.

   Read the full bite: Diamond dependencies and nested node_modules

3. Question 3 of 30

   What is a distinctive advantage of monorepo workspaces over consuming shared code as published private packages?

   • aServices can never have conflicting dependency versions
   • bIt eliminates the need for any CI configuration
   • cEach service automatically deploys independently
   • dA breaking change and all consumer updates can land in one atomic commit without a publish step
   Show the answer

   Answer: d · A breaking change and all consumer updates can land in one atomic commit without a publish step

   Workspaces link internal packages locally, so changes to shared code and its consumers ship in a single atomic commit. Published packages instead require a publish-and-bump cycle and risk version drift.

   Read the full bite: Monorepo workspaces vs private npm packages

4. Question 4 of 30

   Why does a worker-pool design usually finish faster than processing fixed chunks of ten sequentially?

   • aIt keeps ten requests always in flight instead of waiting for each chunk's slowest item
   • bIt opens more than ten connections at once
   • cChunks run serially within each batch
   • dIt skips failed requests entirely
   Show the answer

   Answer: a · It keeps ten requests always in flight instead of waiting for each chunk's slowest item

   Fixed chunks must wait for the slowest request in each batch before starting the next, leaving slots idle. A worker pool immediately refills a freed slot, maintaining full concurrency throughout.

   Read the full bite: Bounded concurrency for many async requests

5. Question 5 of 30

   When is Promise.allSettled the better choice over Promise.all?

   • aWhen you want to abort all operations as soon as one fails
   • bWhen all inputs are guaranteed to succeed
   • cWhen each operation is independent and you need every outcome, including failures, reported
   • dWhen you only need the first result to arrive
   Show the answer

   Answer: c · When each operation is independent and you need every outcome, including failures, reported

   allSettled waits for every input and reports each outcome, ideal when partial success is acceptable and you must see all failures. all aborts on the first rejection, hiding other results.

   Read the full bite: Promise.all vs Promise.allSettled

6. Question 6 of 30

   Why is for await...of preferable to Promise.all for processing a multi-gigabyte file line by line?

   • aPromise.all cannot work with file streams at all
   • bIt automatically caches every line for reuse
   • cIt consumes lines lazily one at a time, keeping memory bounded with backpressure
   • dIt processes all lines in parallel for maximum speed
   Show the answer

   Answer: c · It consumes lines lazily one at a time, keeping memory bounded with backpressure

   for await...of awaits each item before requesting the next, so only one line is held at a time and memory stays flat. Promise.all would require buffering every line in memory at once.

   Read the full bite: Async iterators and for await...of for streaming

7. Question 7 of 30

   In a cluster setup, what is the primary (master) process responsible for?

   • aForking and supervising worker processes while workers serve traffic
   • bHandling all incoming HTTP requests directly for consistency
   • cRunning the heaviest CPU computation while workers stay idle
   • dSharing a single mutable memory heap across all workers
   Show the answer

   Answer: a · Forking and supervising worker processes while workers serve traffic

   The primary forks workers and restarts them on exit; the workers handle requests across cores. It does not serve traffic itself, share a heap, or run the heavy compute.

   Read the full bite: Scaling across cores with cluster and os

8. Question 8 of 30

   What advantage does stream.pipeline have over the .pipe() method when streaming a file to an HTTP response?

   • apipeline propagates errors and destroys all streams on failure, preventing leaks
   • bpipeline transfers data faster by skipping the internal buffer
   • cpipeline encrypts the stream contents automatically
   • dpipeline disables backpressure for maximum throughput
   Show the answer

   Answer: a · pipeline propagates errors and destroys all streams on failure, preventing leaks

   pipeline adds unified error handling and resource cleanup that pipe lacks, avoiding leaked descriptors. Both honor backpressure; pipeline does not skip buffering, drop backpressure, or encrypt data.

   Read the full bite: Backpressure in Node.js streams

9. Question 9 of 30

   Why does enabling keepAlive on an http.Agent improve performance for repeated requests to the same host?

   • aIt runs each request on a separate CPU core
   • bIt compresses request bodies to reduce bandwidth
   • cIt reuses pooled sockets, skipping the TCP and TLS handshakes on later requests
   • dIt caches response bodies so repeated requests return instantly
   Show the answer

   Answer: c · It reuses pooled sockets, skipping the TCP and TLS handshakes on later requests

   keepAlive keeps sockets in the pool for reuse, avoiding repeated handshakes that add round trips. It does not compress, parallelize across cores, or cache responses.

   Read the full bite: http.Agent and connection pooling

10. Question 10 of 30

    When mounting a router with app.use('/users', usersRouter), how should routes inside the router file be defined?

    • aWith the full path, like router.get('/users/:id')
    • bThey must repeat /users or the mount is ignored
    • cWith an absolute path including the host name
    • dRelative to the mount point, like router.get('/:id'), which resolves to /users/:id
    Show the answer

    Answer: d · Relative to the mount point, like router.get('/:id'), which resolves to /users/:id

    The mount prefix is prepended automatically, so routes are defined relative to it; router.get('/:id') becomes /users/:id. Repeating /users yields a doubled /users/users path.

    Read the full bite: Modularizing routes with express.Router

11. Question 11 of 30

    Why must auth middleware return after sending res.status(401) when the key is invalid?

    • aBecause res.status throws unless followed by return
    • bTo stop execution so it does not also call next and trigger a double response
    • cTo reset the response status back to 200
    • dTo free the API key from memory immediately
    Show the answer

    Answer: b · To stop execution so it does not also call next and trigger a double response

    Without returning, the function would continue and could call next, sending a second response and causing a headers-already-sent error. The return simply halts the handler; it does not free memory or reset status.

    Read the full bite: Custom API key auth middleware

12. Question 12 of 30

    What distinguishes an Express error-handling middleware from a regular one?

    • aIt has four parameters (err, req, res, next), and Express detects this signature
    • bIt must be named errorHandler
    • cIt is registered with app.error instead of app.use
    • dIt returns a Promise rejection instead of calling next
    Show the answer

    Answer: a · It has four parameters (err, req, res, next), and Express detects this signature

    Express identifies error handlers by their four-argument arity and routes errors to them. The name is irrelevant, there is no app.error method, and it is still registered with app.use.

    Read the full bite: Centralized error-handling middleware

13. Question 13 of 30

    Your JWT middleware sends a 401 for bad tokens but crashes with 'Cannot set headers after they are sent'. What is the bug?

    • aIt uses jwt.verify instead of jwt.decode
    • bIt calls next() after sending the 401 response
    • cIt attaches the payload to req.user
    • dThe secret is read from an environment variable
    Show the answer

    Answer: b · It calls next() after sending the 401 response

    After responding you must return without calling next(), or the chain continues and a later handler tries to send again. verify (not decode) is exactly what you want for security.

    Read the full bite: Write a JWT authentication middleware

14. Question 14 of 30

    You want an XML parser to run only for application/xml requests, with the condition kept out of the parser's own code. Which is the cleanest approach?

    • aApply the XML parser globally to every request
    • bParse the body twice and discard the wrong result
    • cAdd an if-check on req.headers['content-type'] inside the parser
    • dUse express.text({ type: 'application/xml' }) or a wrapper that checks req.is() then delegates
    Show the answer

    Answer: d · Use express.text({ type: 'application/xml' }) or a wrapper that checks req.is() then delegates

    The type option and a req.is() wrapper keep the matching logic declarative and outside the parser, exactly what the question asks; embedding the check inside the parser is the disallowed approach.

    Read the full bite: Conditionally apply middleware by request property

15. Question 15 of 30

    In an Express 4 API with a central error middleware, async route errors still hang the request while sync throws work fine. What is missing?

    • aA second error-handling middleware
    • bAn asyncHandler wrapper that catches promise rejections and calls next
    • cA try/catch inside the error middleware itself
    • dRegistering the error handler before the routes
    Show the answer

    Answer: b · An asyncHandler wrapper that catches promise rejections and calls next

    Express 4 auto-catches synchronous throws but not promise rejections, so async handlers need a wrapper that forwards rejections to next. Moving the error handler before routes would actually break it.

    Read the full bite: Centralized error handling in an Express API

16. Question 16 of 30

    A team picks header-based API versioning over URL-path versioning. Which downside are they accepting?

    • aIt prevents returning JSON responses
    • bVersions are hidden, harder to test in a browser, and complicate caching (Vary)
    • cIt makes every endpoint non-idempotent
    • dOld and new clients can no longer coexist
    Show the answer

    Answer: b · Versions are hidden, harder to test in a browser, and complicate caching (Vary)

    Header versioning keeps URLs clean but hides the version, making it less discoverable, harder to curl, and requiring caches to Vary on the header. Both strategies still let versions coexist.

    Read the full bite: API versioning: URL vs header strategies

17. Question 17 of 30

    You fetch 50 blogs and Sequelize logs 51 SQL queries. What single change most directly reduces this to one query?

    • aPass include for the Author model in the findAll call
    • bIncrease the connection pool size
    • cWrap the loop in a transaction
    • dAdd a database index on the authors table primary key
    Show the answer

    Answer: a · Pass include for the Author model in the findAll call

    Eager loading via include builds one JOIN query, eliminating the per-row author lookups. An index speeds each query but leaves the count at 51.

    Read the full bite: Solving the N+1 query problem in Sequelize

18. Question 18 of 30

    In a managed Sequelize transaction you create an Order with the transaction but decrement Product stock without passing it. What goes wrong?

    • aSequelize throws a syntax error at startup
    • bBoth writes roll back if anything throws
    • cThe order creation is skipped entirely
    • dThe stock decrement commits independently and is not rolled back
    Show the answer

    Answer: d · The stock decrement commits independently and is not rolled back

    A query that omits the transaction option runs outside it and commits on its own, so a later rollback cannot undo the stock change. Only queries passed the transaction participate in atomicity.

    Read the full bite: Atomic order creation with Sequelize transactions

19. Question 19 of 30

    You group sales by productId to compute totalSales, then want only products above 1000. Where must that $match stage go?

    • aBefore $group, because $match always runs first
    • bIt must be combined into the $group stage
    • cEither position works identically
    • dAfter $group, because totalSales does not exist until grouping
    Show the answer

    Answer: d · After $group, because totalSales does not exist until grouping

    totalSales is a field created by $group, so a $match referencing it must come afterward. Placing $match first could only filter raw input fields, not the aggregated total.

    Read the full bite: MongoDB aggregation pipeline for total sales

20. Question 20 of 30

    Where should the role used by an RBAC middleware come from to remain secure?

    • aA query parameter on the protected route
    • bA custom HTTP header the client sets on each request
    • cThe verified token payload or database lookup, set by auth middleware
    • dThe request body submitted with the action
    Show the answer

    Answer: c · The verified token payload or database lookup, set by auth middleware

    The role must derive from a trusted source the client cannot forge, namely the verified token or a server-side lookup populated during authentication. Client-controlled headers, body, or query params can be spoofed to escalate privileges.

    Read the full bite: Role-based access control middleware in Express

21. Question 21 of 30

    You add a Redis denylist checked on every request to revoke JWTs instantly. What is the main trade-off you accept?

    • aThe payload becomes encrypted and unreadable
    • bRefresh tokens are no longer needed at all
    • cTokens can no longer be signed asymmetrically
    • dYou reintroduce a per-request stateful lookup, reducing statelessness
    Show the answer

    Answer: d · You reintroduce a per-request stateful lookup, reducing statelessness

    A denylist gives immediate revocation but requires checking external state on each request, partly undoing the stateless advantage of JWTs. It has nothing to do with the signing algorithm or payload encryption.

    Read the full bite: Strategies for revoking stateless JWTs

22. Question 22 of 30

    You move a JWT from localStorage into an httpOnly cookie. Which new defense becomes necessary that was not needed before?

    • aCSRF protection such as SameSite or anti-CSRF tokens
    • bDisabling the Authorization header
    • cEncrypting the JWT payload
    • dA longer signing key
    Show the answer

    Answer: a · CSRF protection such as SameSite or anti-CSRF tokens

    httpOnly cookies are sent automatically by the browser, exposing the app to CSRF, so SameSite or anti-CSRF tokens are required. With localStorage the token was attached manually and not auto-sent, so CSRF was not a concern there.

    Read the full bite: JWT storage: localStorage versus httpOnly cookies

23. Question 23 of 30

    After catching an uncaughtException, why is the recommended action to log and exit rather than keep the server running?

    • aContinuing would double-handle the same request
    • bThe event automatically restarts the process for you
    • cReaching this handler means an error escaped all handling, so process state is untrustworthy
    • dNode.js forces the process to exit regardless
    Show the answer

    Answer: c · Reaching this handler means an error escaped all handling, so process state is untrustworthy

    An uncaughtException means an error bypassed every local handler, so the process may be in a corrupted state and should restart cleanly under a supervisor. Node does not auto-exit (in older versions) or auto-restart, which is exactly why you must exit deliberately.

    Read the full bite: Handling uncaughtException and unhandledRejection

24. Question 24 of 30

    Why can wrapping each integration test in a transaction that is rolled back afterward sometimes fail to isolate state?

    • aJest cannot open a database transaction
    • bRollbacks permanently corrupt the schema
    • cIf the code under test commits or uses a second connection, the rollback no longer covers all changes
    • dTransactions are slower than truncating tables
    Show the answer

    Answer: c · If the code under test commits or uses a second connection, the rollback no longer covers all changes

    Rollback only undoes work inside that transaction and connection; code that commits or opens another connection escapes it. Rollback is generally faster than truncation, so speed is not the issue.

    Read the full bite: Managing clean test state across API integration tests

25. Question 25 of 30

    What is the main drawback of testing a third-party integration by mocking your own client wrapper module rather than intercepting at the HTTP layer?

    • aIt cannot simulate a successful response
    • bIt bypasses request construction and the HTTP layer, leaving header and serialization bugs untested
    • cIt requires a running third-party sandbox account
    • dIt makes tests slower than real network calls
    Show the answer

    Answer: b · It bypasses request construction and the HTTP layer, leaving header and serialization bugs untested

    Mocking your own wrapper skips the real request-building and transport code, so serialization or header bugs go uncaught. It is actually faster than real calls and needs no sandbox account.

    Read the full bite: Testing code that calls a third-party API

26. Question 26 of 30

    When testing an API call that writes to a database and then publishes to a message queue, why is a fixed setTimeout a poor way to wait for completion?

    • asetTimeout cannot be used inside Jest tests
    • bMessage queues reject any consumer that waited on a timer
    • cIt blocks the event loop and freezes the broker
    • dIt is flaky under load yet slow when over-padded; polling-until-asserted is more reliable
    Show the answer

    Answer: d · It is flaky under load yet slow when over-padded; polling-until-asserted is more reliable

    A fixed delay races against variable latency: too short and it flakes, too long and it wastes time. Retrying an assertion until it passes within a timeout adapts to actual completion.

    Read the full bite: Testing an async workflow that spans DB and message queue

27. Question 27 of 30

    How can a strict CSP permit the SPA's own inline bootstrap script while still blocking attacker-injected inline scripts, without using unsafe-inline?

    • aBy listing the page's full URL in default-src
    • bBy disabling CSP for first-party scripts
    • cBy adding unsafe-eval to script-src
    • dBy stamping a fresh per-request nonce on trusted inline tags and listing it in script-src
    Show the answer

    Answer: d · By stamping a fresh per-request nonce on trusted inline tags and listing it in script-src

    A per-request nonce on trusted tags, matched in script-src, lets your code run while injected scripts lack the unpredictable nonce and are blocked. unsafe-eval concerns eval, not inline tags, and the other options weaken or void the policy.

    Read the full bite: Deploying a strict CSP for an Express SPA

28. Question 28 of 30

    Why is prototype pollution dangerous beyond the single object an attacker targets?

    • aIt deletes the targeted object from memory
    • bWriting to Object.prototype makes the injected property visible on every object that does not override it
    • cIt is limited to the request that triggered it and resets immediately
    • dIt only affects objects created after the application restarts
    Show the answer

    Answer: b · Writing to Object.prototype makes the injected property visible on every object that does not override it

    Because objects inherit from the shared Object.prototype, a property set there leaks into all objects lacking their own value, enabling app-wide effects. It is not scoped to one request or one object instance.

    Read the full bite: Prototype pollution: how it works and prevention

29. Question 29 of 30

    What trade-off does moving a JWT from localStorage to an HttpOnly cookie introduce?

    • aIt blocks JavaScript from reading the token (mitigating XSS theft) but reintroduces CSRF risk needing SameSite and CSRF tokens
    • bIt removes the need for short-lived tokens
    • cIt makes the token readable by any script but immune to network attacks
    • dIt eliminates XSS risk entirely and has no downsides
    Show the answer

    Answer: a · It blocks JavaScript from reading the token (mitigating XSS theft) but reintroduces CSRF risk needing SameSite and CSRF tokens

    HttpOnly hides the token from JavaScript, defeating XSS exfiltration, but auto-sent cookies bring CSRF exposure that must be mitigated. It does not eliminate all risk or remove the need for short token lifetimes.

    Read the full bite: JWT storage: localStorage versus HttpOnly cookie

30. Question 30 of 30

    During a zero-downtime restart using cluster module, why must the master stop accepting new connections on old workers before terminating them?

    • aBecause old and new workers cannot coexist on the same port without stopping new connections.
    • bTo prevent new requests from landing on workers about to die, ensuring they can drain existing connections cleanly.
    • cBecause the cluster module automatically blocks all new connections once shutdown begins.
    • dTo force immediate rejection of client requests so the deployment finishes faster.
    Show the answer

    Answer: b · To prevent new requests from landing on workers about to die, ensuring they can drain existing connections cleanly.

    The master stops routing new requests to old workers so they can finish their in-flight work without abandoning clients. This prevents the thundering herd problem. Blocking new connections is not automatic; it requires explicit routing changes. Rejecting requests defeats the purpose of zero-downtime. Multiple workers can share a port via clustering.

    Read the full bite: How does Node.js cluster module enable zero-downtime restarts?