Node.js Developer interview questions

Node.js is a JavaScript runtime built for executing JavaScript outside a web browser.

• It uses the V8 engine to compile and run JavaScript.
• It provides server-side APIs for files, networking, processes, and operating-system integration.
• Its event-driven, non-blocking I/O model suits services that handle many concurrent I/O operations.

V8 executes JavaScript, while libuv provides the event loop and cross-platform asynchronous I/O support.

• V8 parses, compiles, optimizes, and runs JavaScript code.
• libuv coordinates timers, networking readiness, and work delegated to its thread pool.
• Node.js binds these components to JavaScript APIs such as fs, timers, and network modules.

It means one event-loop thread normally executes a process's JavaScript callbacks one at a time.

• Concurrent I/O can still progress through the operating system and libuv.
• Some filesystem, DNS, crypto, and compression work uses the libuv thread pool.
• Worker threads or child processes can provide additional JavaScript execution threads or processes when needed.

The event loop is the mechanism that repeatedly runs ready callbacks and coordinates asynchronous work without blocking on each operation.

• JavaScript starts work such as a timer or network request and registers what should happen when it is ready.
• Node.js processes callback queues in defined phases.
• Long synchronous JavaScript delays every other callback because the event-loop thread cannot run them simultaneously.

The main phases are timers, pending callbacks, idle and prepare internals, poll, check, and close callbacks.

• The timers phase runs eligible setTimeout and setInterval callbacks.
• Poll receives I/O events and runs many I/O callbacks, while check runs setImmediate callbacks.
• Close callbacks handle events such as a socket's close callback, with microtasks processed around callback execution rather than as a normal phase.

The timers phase makes a callback eligible after its delay has elapsed but does not guarantee an exact execution time.

• The delay is a minimum threshold rather than a scheduled wall-clock appointment.
• Earlier synchronous work and other queued callbacks can postpone execution.
• setInterval repeats eligibility at an interval, but its callbacks can also be delayed by event-loop load.

The poll phase retrieves new I/O events and runs eligible callbacks for many completed I/O operations.

• It can wait for I/O when no callback is immediately ready and no scheduling rule requires moving on.
• Its waiting time is influenced by timers and queued setImmediate callbacks.
• Not every asynchronous API completes in poll, so the event-loop phases still matter.

setImmediate schedules a callback for the check phase, while setTimeout schedules it for the timers phase after a minimum delay.

• Their relative order from top-level code is not a reliable general guarantee.
• When both are scheduled from the same I/O callback, setImmediate runs in the upcoming check phase before the zero-delay timer.
• Choose based on the intended phase rather than assuming either API means run immediately.

process.nextTick queues a callback to run after the current JavaScript operation finishes and before the event loop continues to another phase.

• After an ordinary callback returns, Node.js drains the nextTick queue before Promise microtasks.
• ESM evaluation and an already-running microtask checkpoint mean this is not a universal source-order guarantee.
• Recursively scheduling nextTick callbacks can starve timers and I/O, so it should not replace ordinary asynchronous scheduling.

Promise reactions run from the microtask queue after the current callback or script completes, before Node.js continues with more event-loop work.

• then, catch, finally, and resumed await code are scheduled as microtasks.
• Microtasks are not a separate libuv event-loop phase.
• A long chain of microtasks can delay timers and I/O callbacks even though each step is asynchronous.

Blocking the event loop prevents the process from running other JavaScript callbacks during that work.

• CPU-heavy loops and synchronous I/O increase latency for unrelated requests in the same process.
• Non-blocking APIs let the event loop serve other work while I/O is pending.
• Large CPU tasks may belong in worker threads, child processes, or another service instead of the request thread.

The libuv thread pool executes selected blocking or CPU-intensive native operations away from the event-loop thread.

• Common users include many filesystem APIs, dns.lookup, crypto operations, and zlib.
• Completion is reported back so the associated callback or Promise can continue on the event-loop thread.
• Network socket I/O normally relies on operating-system readiness rather than one pool thread per connection.

A callback is a function passed to another operation to be invoked when work completes or an event occurs.

• The initiating function can return before an asynchronous callback runs.
• The callback receives completion data, an error, or event-specific arguments according to the API.
• Callbacks are also used for synchronous iteration, so the API contract determines whether invocation is asynchronous.

An error-first callback receives the error as its first argument and success data in later arguments.

• A null or absent first argument indicates that the operation succeeded.
• A non-null error should normally end the success path and be handled or propagated.
• Many older Node.js APIs follow the form callback(error, result), which can be adapted to Promises with utilities such as promisify.

Callback hell is deeply nested asynchronous control flow that makes sequencing, errors, and cleanup difficult to follow.

• Named functions and early returns can flatten callback-based code.
• Promises express sequences through returned chains and central catch handling.
• async and await provide sequential-looking syntax while preserving Promise-based asynchrony.

A Promise is pending until it becomes fulfilled with a value or rejected with a reason.

• Fulfillment and rejection are the two settled states.
• Once settled, a Promise cannot change to another state or value.
• Handlers can be attached before or after settlement and still run asynchronously as microtasks.

then handles fulfillment, catch handles rejection, and finally runs cleanup-like code after either outcome.

• Each method returns a new Promise, enabling further composition.
• A value returned from a handler fulfills the next Promise, while a thrown error rejects it.
• finally normally preserves the previous value or error unless its callback throws or returns a rejected Promise.

Returning from a then handler connects its result to the next Promise in the chain.

• Returning a plain value fulfills the next step with that value.
• Returning a Promise makes the chain wait for and adopt that Promise's outcome.
• Forgetting the return can let the outer chain continue with undefined before nested work finishes.

Promise.all fulfills when every input fulfills and rejects on the first observed rejection, while Promise.allSettled reports every outcome.

• Promise.all preserves input order in its fulfilled result array.
• Its early rejection does not automatically cancel the other underlying operations.
• allSettled returns status objects for fulfilled and rejected inputs, which is useful when every result matters.

An async function always returns a Promise for its eventual result.

• Returning a plain value fulfills that Promise with the value.
• Throwing inside the function rejects the returned Promise.
• The function body may use await to suspend its own continuation without blocking the event-loop thread.