Top 30 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

   Which statement best describes how Node.js handles I/O for thousands of concurrent connections?

   • aNetwork sockets are watched by the OS, while blocking tasks like DNS and file reads use a small internal thread pool.
   • bIt spawns a new OS thread for every incoming connection to process requests in parallel.
   • cAll I/O operations, including file reads and DNS lookups, are handled directly by the event loop without blocking.
   • dThe event loop busy-waits in a while loop, polling each file descriptor until data is available.
   Show the answer

   Answer: a · Network sockets are watched by the OS, while blocking tasks like DNS and file reads use a small internal thread pool.

   Node.js relies on the OS kernel to monitor network sockets and notify the event loop when data arrives, while delegating blocking operations like DNS and some file system work to a limited internal thread pool. Distractor D is tempting because Node is famous for non-blocking I/O, but it wrongly assumes every I/O operation can run without thread assistance.

   Read the full bite: How does Node.js handle thousands of connections on one thread?

2. Question 2 of 30

   In which event loop phase do the majority of completed I/O callbacks, such as a finished network read, actually execute?

   • aThe check phase, alongside setImmediate callbacks
   • bThe close callbacks phase, after the loop drains
   • cThe timers phase, right after expired setTimeout callbacks
   • dThe poll phase, which retrieves and runs I/O completions
   Show the answer

   Answer: d · The poll phase, which retrieves and runs I/O completions

   The poll phase retrieves new I/O events and executes most of their callbacks. The timers phase only handles elapsed setTimeout/setInterval, not I/O completion.

   Read the full bite: Order of the Node.js event loop phases

3. Question 3 of 30

   When both are scheduled from inside a completed fs I/O callback, which runs first and why?

   • asetTimeout(fn, 0), because timers always precede check
   • bThey run simultaneously since both mean zero delay
   • csetImmediate, because the check phase follows poll in the same iteration
   • dprocess.nextTick, because it is also a macrotask
   Show the answer

   Answer: c · setImmediate, because the check phase follows poll in the same iteration

   From within an I/O callback the loop is in poll, so the next phase is check, making setImmediate fire before the timers phase comes around again. setTimeout(0) waits for the next iteration.

   Read the full bite: nextTick vs setImmediate vs setTimeout(fn, 0)

4. Question 4 of 30

   Why does wrapping a heavy synchronous computation in an async function fail to keep a Node server responsive?

   • aThe computation is still synchronous and never yields the single JS thread
   • bPromises lower the priority of CPU work in the loop
   • cAsync functions run on a separate OS thread automatically
   • dThe garbage collector preempts long Promises
   Show the answer

   Answer: a · The computation is still synchronous and never yields the single JS thread

   async/await only helps when there is an awaited asynchronous boundary; a synchronous CPU loop still occupies the single thread, blocking the event loop. Worker Threads provide real parallelism.

   Read the full bite: Offloading CPU-bound work with Worker Threads

5. Question 5 of 30

   Why is it a problem to list a library your source code imports at runtime under devDependencies?

   • adevDependencies are always installed, so it makes no difference
   • bnpm will refuse to install the package at all
   • cIt forces the package to be loaded twice
   • dA production install that skips devDependencies leaves it missing, causing runtime errors
   Show the answer

   Answer: d · A production install that skips devDependencies leaves it missing, causing runtime errors

   Production installs omit devDependencies, so a runtime import placed there will be absent and throw module-not-found. Runtime libraries must live under dependencies.

   Read the full bite: dependencies vs devDependencies in package.json

6. Question 6 of 30

   What does Node do first when it encounters require('fs')?

   • aMatches it against built-in core modules, which take precedence
   • bDownloads it from the npm registry on demand
   • cTreats it as a relative path from the current file
   • dSearches node_modules directories upward for an fs package
   Show the answer

   Answer: a · Matches it against built-in core modules, which take precedence

   Bare specifiers are checked against built-in core modules first; fs is compiled into the binary and resolves without touching node_modules. The package search only runs for non-core bare names.

   Read the full bite: Resolving core vs relative module specifiers

7. Question 7 of 30

   What core problem does committing package-lock.json solve that package.json alone cannot?

   • aIt makes installs faster by caching tarballs in the repo
   • bIt documents which packages are devDependencies
   • cIt guarantees every install resolves to the exact same dependency tree, including transitive packages
   • dIt prevents anyone from adding new dependencies
   Show the answer

   Answer: c · It guarantees every install resolves to the exact same dependency tree, including transitive packages

   package.json uses version ranges, so installs can drift; the lockfile pins exact versions and tree shape for all transitive deps, making installs deterministic. It does not store tarballs or block additions.

   Read the full bite: Why package-lock.json must be committed

8. Question 8 of 30

   Which statement about using ES Modules instead of CommonJS in Node is accurate?

   • aCommonJS supports top-level await but ESM does not
   • bYou can require an ESM-only file directly from a CommonJS module
   • cimport is just an alias for require with identical semantics
   • dESM lacks __dirname by default and is enabled via type module or .mjs
   Show the answer

   Answer: d · ESM lacks __dirname by default and is enabled via type module or .mjs

   ESM omits __dirname and require, and is enabled by type module or the .mjs extension. import is not an alias for require, and only ESM supports top-level await.

   Read the full bite: Choosing between CommonJS and ES Modules

9. Question 9 of 30

   Why should the service layer in a layered Express API avoid referencing the request and response objects?

   • aServices run in a different thread from controllers
   • bExpress forbids accessing them outside route handlers
   • cPassing them is slower than passing plain values
   • dIt keeps business logic framework-agnostic and unit-testable without HTTP
   Show the answer

   Answer: d · It keeps business logic framework-agnostic and unit-testable without HTTP

   Keeping req and res out of services makes the business logic reusable and testable without spinning up HTTP. Express does not forbid it and services are not on a separate thread.

   Read the full bite: Layered structure for a scalable Express API

10. Question 10 of 30

    Given a dependency written as ^1.4.2, which upgrade would npm refuse to install on its own?

    • a1.5.3, a later minor and patch
    • b2.0.0, a major release
    • c1.4.9, a patch release
    • d1.7.0, a minor release
    Show the answer

    Answer: b · 2.0.0, a major release

    The caret allows updates below the next major, so anything under 2.0.0 is permitted, but 2.0.0 itself is excluded. The tilde would be the operator that also blocks 1.7.0.

    Read the full bite: SemVer and the caret vs tilde range operators

11. Question 11 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

12. Question 12 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

13. Question 13 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

14. Question 14 of 30

    Which statement about a Promise's state transitions is correct?

    • aOnce settled as fulfilled or rejected, the state is permanent and cannot change
    • bA rejected Promise can later return to pending if retried
    • cthen callbacks execute synchronously the instant resolve is called
    • dA Promise can be both fulfilled and rejected to cover all cases
    Show the answer

    Answer: a · Once settled as fulfilled or rejected, the state is permanent and cannot change

    Settling is one-way and final; a Promise transitions from pending to exactly one of fulfilled or rejected and stays there. then callbacks run later as microtasks, not synchronously.

    Read the full bite: The three states of a JavaScript Promise

15. Question 15 of 30

    Why does the Promise callback print before the setTimeout(0) callback despite both being scheduled in the same tick?

    • aThe order is implementation-defined and can vary
    • bPromises run on a higher-priority OS thread
    • csetTimeout has an enforced minimum delay larger than the Promise
    • dThe microtask queue is fully drained before the next macrotask runs
    Show the answer

    Answer: d · The microtask queue is fully drained before the next macrotask runs

    After the synchronous stack clears, all microtasks (Promise reactions) drain before any macrotask (setTimeout) runs. The delay value is not the deciding factor here; queue priority is.

    Read the full bite: Output order of sync, microtask, and macrotask

16. Question 16 of 30

    What happens to the remaining requests when one input to Promise.all rejects?

    • aPromise.all waits for all of them before reporting the rejection
    • bThe combined Promise rejects immediately, but the other requests still run to completion
    • cTheir results replace the rejected one
    • dThey are automatically cancelled by the runtime
    Show the answer

    Answer: b · The combined Promise rejects immediately, but the other requests still run to completion

    Promise.all rejects as soon as the first input rejects, but JavaScript Promises are not cancellable, so the other in-flight requests continue running. They simply have no remaining handler.

    Read the full bite: Running independent requests with Promise.all and race

17. Question 17 of 30

    In classic Express 4, how should an error from an awaited database call inside async middleware reach the error handler?

    • aThrow it and let Express catch it automatically
    • bIgnore it, since unhandled rejections are routed by default
    • cCatch it and pass it to next(err) so the error-handling middleware runs
    • dCall res.send with the error directly from the middleware
    Show the answer

    Answer: c · Catch it and pass it to next(err) so the error-handling middleware runs

    Express 4 does not auto-catch async throws, so you must catch and forward with next(err) to trigger the four-argument error handler. Throwing alone leaves the request hanging.

    Read the full bite: Handling async errors in Express middleware

18. Question 18 of 30

    Why might a try/catch fail to catch an error from an async call inside it?

    • atry/catch never works with Promises under any circumstance
    • bIf the returned Promise is not awaited, control leaves the block before it rejects
    • ccatch only catches synchronous TypeErrors
    • dasync functions disable the surrounding try/catch
    Show the answer

    Answer: b · If the returned Promise is not awaited, control leaves the block before it rejects

    Without await, the async call returns a pending Promise and execution exits the try block immediately, so a later rejection is not caught there. Awaiting the call keeps it within the try/catch scope.

    Read the full bite: Comparing the three async error-handling styles

19. Question 19 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

20. Question 20 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

21. Question 21 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

22. Question 22 of 30

    Why is calling fs.readFileSync inside an Express request handler a problem under concurrent load?

    • aIt spawns a new thread per request, exhausting the thread pool
    • bIt silently returns stale cached data from previous reads
    • cIt blocks the single event loop thread, stalling all other pending requests
    • dIt throws an error because sync calls are forbidden in handlers
    Show the answer

    Answer: c · It blocks the single event loop thread, stalling all other pending requests

    The sync read blocks the one event loop thread until it finishes, so every other request waits. It is not forbidden and does not spawn threads; the async version uses the libuv pool instead.

    Read the full bite: fs.readFileSync vs fs.readFile

23. Question 23 of 30

    What does path.join provide that naive string concatenation of path segments does not?

    • aFaster disk reads by caching the joined path
    • bGuaranteed protection against all directory traversal attacks
    • cPlatform-correct separators plus normalization of redundant slashes and segments
    • dAutomatic encryption of the resulting file path
    Show the answer

    Answer: c · Platform-correct separators plus normalization of redundant slashes and segments

    path.join inserts the right separator per OS and normalizes the path. It does not encrypt, speed up reads, or by itself stop traversal attacks, which still require explicit validation.

    Read the full bite: Why use path.join over string concatenation

24. Question 24 of 30

    In a bare http module server, what is the consequence of never calling res.end inside the request listener?

    • aThe client connection hangs because the response is never finalized
    • bNode automatically sends an empty 200 after a timeout
    • cThe request is silently retried by the http module
    • dThe server crashes with an unhandled exception
    Show the answer

    Answer: a · The client connection hangs because the response is never finalized

    res.end finalizes and flushes the response; without it the client waits indefinitely. Node does not auto-complete the response, crash, or retry the request on its own.

    Read the full bite: Minimal HTTP server with the http module

25. Question 25 of 30

    Why does fs.createReadStream with readline scale to a 5GB log while fs.readFile does not?

    • areadline compresses the file before reading it
    • breadFile cannot open files larger than 2GB on any platform
    • ccreateReadStream reads the file twice as fast on disk
    • dStreaming keeps memory roughly constant by processing small chunks instead of buffering all 5GB
    Show the answer

    Answer: d · Streaming keeps memory roughly constant by processing small chunks instead of buffering all 5GB

    Streaming processes the file in small chunks so memory stays flat; readFile allocates the whole file at once. It does not compress, double disk speed, and the issue is memory, not a hard 2GB open limit.

    Read the full bite: Counting lines in a 5GB log file efficiently

26. Question 26 of 30

    Why must you wait for the request's end event before calling JSON.parse on a POST body?

    • aThe end event decrypts the body which is otherwise unreadable
    • breq.body is populated synchronously but only readable after end
    • cJSON.parse only works inside event handlers named end
    • dThe body arrives as multiple chunks and is only complete once end fires
    Show the answer

    Answer: d · The body arrives as multiple chunks and is only complete once end fires

    The request is a stream delivering chunks via data events; the full body exists only after end. The body is not encrypted, JSON.parse works anywhere, and req.body is not natively populated.

    Read the full bite: Reading a POST body from the request stream

27. Question 27 of 30

    Given path.resolve('/foo', 'bar', '/baz', 'qux'), what is returned and why?

    • aqux because resolve uses only the last segment
    • b/foo/bar/baz/qux because resolve concatenates like join
    • c/foo/bar/qux because /baz is treated as a filename
    • d/baz/qux because an absolute segment discards everything to its left
    Show the answer

    Answer: d · /baz/qux because an absolute segment discards everything to its left

    resolve processes right to left and a leading-slash segment resets the path, so /baz/qux results. join would keep /foo/bar/baz/qux; resolve does not simply concatenate or use only the last segment.

    Read the full bite: path.resolve vs path.join

28. Question 28 of 30

    What is the core mechanism difference between fs.watch and fs.watchFile?

    • afs.watch uses OS-native change notifications; fs.watchFile polls with stat on an interval
    • bBoth use OS events, but fs.watchFile adds encryption
    • cBoth poll, but fs.watch polls faster
    • dfs.watch polls stat on an interval; fs.watchFile uses OS events
    Show the answer

    Answer: a · fs.watch uses OS-native change notifications; fs.watchFile polls with stat on an interval

    fs.watch is event-driven via OS APIs and efficient but inconsistent; fs.watchFile polls stat, making it portable but slower. The roles are not reversed and neither relies on encryption.

    Read the full bite: fs.watch vs fs.watchFile

29. Question 29 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

30. Question 30 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