Node.js Backend Developer Top 100 Interview Questions

Make sure every rejected promise from a handler reaches one central error handler that sends a response. Unhandled, a rejection either crashes the process or leaves the request open until the client times out.

flowchart TD
  A["Async handler throws or rejects"] --> B{"Framework awaits handler promises?"}
  B -->|yes| C["Error passed to error middleware"]
  B -->|no| D["Wrap handler to catch and forward error"]
  D --> C
  C --> E["Log with request ID"]
  E --> F["Send consistent error response"]

• Know your framework: some await handler promises and route rejections to the error handler; older ones need every async handler wrapped in a function that catches and forwards errors.
• One error middleware maps known errors to status codes and unknown ones to a generic 500, and logs the details.
• Never respond twice: if headers are already sent, such as during streaming, end or destroy the response instead.
• Fire-and-forget work started from a handler needs its own .catch, because no one awaits it.
• Timeouts: set server request timeouts, so a handler that never responds cannot hold a connection forever.

Compress text responses such as JSON, HTML and CSV above a small size threshold when clients accept it; skip already-compressed content and tiny bodies. Compression saves bandwidth and time for clients, but it costs CPU on the server.

• Where to compress: often at a reverse proxy or content delivery layer, which keeps the CPU work off Node.js processes. Compress in Node.js when there is no such layer.
• Thread pool: the asynchronous zlib functions run on the thread pool, so heavy compression competes with file and crypto work; the synchronous versions block the event loop.
• Streaming: compression fits in a stream pipeline, so large responses stay in constant memory.
• Levels: higher compression levels give small extra savings for much more CPU; moderate levels are usually best for dynamic responses.

Security caveat: compressing responses that mix secrets, such as tokens, with attacker-controlled text can leak the secret through response sizes. Avoid compressing such responses, or keep secrets out of compressed bodies.

Node.js suits real-time features well, because each open connection costs little while idle. The challenges are authentication, fan-out across processes, slow clients and keeping connections healthy.

flowchart LR
  A["Client"] -->|upgrade request| B["Node.js process"]
  B --> C["Authenticate and join rooms"]
  D["Other process publishes event"] --> E["Shared message broker"]
  E --> B
  B --> A

• Upgrade handling: a WebSocket starts as an HTTP request that is upgraded; authenticate during that request, using a token or session cookie, and check the origin.
• Fan-out across processes: clients connect to different processes, so publish events through a shared broker channel that every process subscribes to.
• Rooms and permissions: check authorization on every subscription, not just at connect time.
• Slow clients: watch the socket's buffered amount and drop or disconnect clients that fall far behind, so memory cannot grow without limit.
• Heartbeats: send pings to detect dead connections and keep proxies from closing idle ones.
• Load balancing: long-lived connections can stay unevenly spread after scaling; reconnect clients gradually during deploys.

Server-sent events are simpler when updates only flow from server to client, since they use plain HTTP.

REST exposes resources at separate URLs with fixed response shapes. GraphQL exposes one endpoint and a typed schema, and each client sends a query describing exactly the fields it needs, including nested related data.

Risks GraphQL brings, and how to handle them:

• Expensive queries: deeply nested or huge queries can overload the server; enforce depth and complexity limits and paginate lists.
• Many small queries: resolving nested fields per item triggers floods of database queries; use batching loaders.
• Field-level authorization: every resolver must check permissions, since clients can ask for any field in the schema.
• Schema exposure: consider disabling introspection in production for private APIs.

Choose GraphQL when many clients need different shapes of the same data, and REST when resources and access patterns are simple.

Write structured JSON logs, one event per line, to standard output, and let the platform collect and ship them. Include consistent fields so logs can be searched and joined with traces.

• Fields: timestamp, level, message, service name, request ID, route and duration, plus any event-specific details.
• Levels: debug for diagnosis, info for business events, warn for recoverable problems, error for failures; run production at info.
• Performance: fast logging libraries write asynchronously and avoid expensive formatting; console.log with large objects can slow the event loop, and writes to a terminal or file may block.
• Context: read the request ID from AsyncLocalStorage, so every log line carries it automatically.
• Errors: log the error object, including its stack and cause, not just the message.

What not to log: passwords, tokens, authorization headers, full card numbers and unnecessary personal data. Configure redaction paths in the logger as a safety net.

Volume control: sample high-volume debug logs, and avoid logging every successful request body; access logs with timings are usually enough.

Expose request metrics that show user experience, runtime metrics that show Node.js-specific saturation, and separate health checks for "is the process alive" and "can it serve traffic".

Request metrics:

• Request count, error count and a latency histogram, labeled by route template and status code.
• Outgoing call latency and errors per dependency.

Runtime metrics:

• Event loop delay and utilization, the clearest saturation signals for Node.js.
• Heap used, heap total and external memory, to catch leaks and buffer growth.
• Garbage collection counts and durations.
• Active handles and requests, such as open sockets and pending timers.
• Pool usage: database pool waiters and thread-pool saturation where measurable.

Health checks:

• Liveness answers quickly from memory without checking dependencies, so a database outage does not make the orchestrator restart every process.
• Readiness checks that the process can serve, such as having a working database pool, and fails during startup and shutdown so traffic goes elsewhere.

Keep label values bounded, never using user IDs or raw URLs, or the metrics store will be overwhelmed.

Recent Node.js versions include node:test, a test runner with test and describe functions, hooks, mocking and coverage, used together with the node:assert module. Many projects no longer need a third-party test framework.

• Writing tests: test('name', async () => { ... }) registers a test; returning or awaiting a promise lets async tests work naturally.
• Grouping and hooks: describe groups tests, and before, after, beforeEach and afterEach manage setup.
• Assertions: assert.strictEqual, assert.deepStrictEqual and assert.rejects cover most checks; the assert/strict module makes strict comparisons the default.
• Running: node --test discovers test files by naming convention, runs them in separate processes and reports results.
• Extras: watch mode, test filtering by name, built-in mocks for functions and timers, and code coverage reporting.

Good test habits:

1. Keep unit tests fast and free of network calls by injecting dependencies.
2. Test error paths, not just success.
3. Make each test independent, so order and parallelism do not matter.
4. Use realistic integration tests for database code, separate from the fast suite.

Prefer passing dependencies in, through factory functions or constructors, so tests can hand over simple fakes. When you need call tracking, the built-in mock.fn() from node:test creates functions that record every call and can return configured values.

• Dependency injection first: a service created as createOrderService({ repository, notify }) can receive in-memory fakes with no special tooling.
• mock.fn: records arguments, results and call counts through its mock property.
• mock.method: replaces a method on an existing object for the duration of a test and can restore it.
• Timers: mock.timers controls setTimeout, setInterval and Date, so time-based logic runs instantly.
• Module mocking is possible but couples tests to how files import each other; reserve it for code you cannot restructure.

Avoid over-mocking: tests that assert every internal call break whenever the code is refactored, even when behavior is unchanged. Mock at boundaries such as databases, HTTP and email, and assert on outcomes where possible.

Start the real application on a random free port inside the test process, send real HTTP requests to it, and assert on status codes, headers and bodies. This exercises routing, middleware, validation and serialization together.

1. Build the app without listening: export a function that creates the server, so tests can start and stop their own instance.
2. Listen on port 0, which lets the operating system pick a free port, and close the server after the tests.
3. Use realistic dependencies: a real test database with migrations applied catches query and constraint errors that fakes miss.
4. Isolate data: clean tables or use unique IDs per test, so tests can run in parallel.
5. Cover failure paths: invalid input, missing authentication, permission denial and dependency timeouts.
6. Check contracts: compare responses with the documented schema, so clients are not broken by accident.

Keep the suite fast and stable:

• Fake slow third-party APIs with a local stub server instead of calling them.
• Avoid fixed sleeps; wait for conditions or events.
• Run these tests in the pipeline on every change, alongside fast unit tests.

Most teams write code in a typed superset of JavaScript that a compiler checks and then converts, or strips, to plain JavaScript. Others keep plain JavaScript files and add type annotations in documentation comments that a type checker understands.

What static types catch before runtime:

• Calling functions with the wrong arguments or missing properties.
• Forgetting that a value may be null or undefined.
• Misspelled property names and refactoring mistakes across many files.

Running typed code:

• Compile step: the build produces JavaScript files, with source maps so stack traces point to the original lines.
• Type stripping: recent Node.js versions can run files with type annotations directly by removing the types, which needs no build step but does not check types; type checking still runs separately in the pipeline.

Important limits:

1. Types disappear at runtime, so request bodies and other external data still need runtime validation.
2. Escape hatches such as any silently turn checking off.
3. Strict settings catch far more bugs than lenient ones; turn them on early in a project's life.

Schema libraries can derive both runtime validators and static types from one definition, closing the gap between them.

Extend Error with classes that carry a stable code and an HTTP status, set name to the class name, and pass the original error as the cause option when wrapping a lower-level failure. Error handlers can then branch on type or code, while logs still show the root cause.

• A base class: AppError holds code, status and any safe details; subclasses such as NotFoundError set defaults.
• cause: new Error(message, { cause }) is standard JavaScript; the full chain appears when the error is logged.
• Stack traces: extending Error captures the stack automatically.
• instanceof checks work across your code, but can fail when two copies of the same package are installed; checking a code property is more robust.

Using them in an API:

1. Throw domain errors in services, never HTTP responses.
2. Map them to responses in one error middleware, sending the code and message but not the cause.
3. Log the whole error, including cause, with the request ID.

Never put secrets or raw database errors in messages that reach clients.

Recent Node.js versions include a permission model, turned on with a command-line flag, that blocks access to sensitive capabilities unless you grant them explicitly. With it enabled, the process cannot read or write files, start child processes, create worker threads or load native add-ons outside what you allow.

• Granting access: separate flags allow reading or writing specific file paths, and enable child processes, workers or add-ons when needed.
• Runtime checks: code can ask whether a permission is granted, and denied operations throw clear errors.
• What it is: a "seat belt" that stops trusted code, including your dependencies, from accidentally touching things it should not.
• What it is not: a sandbox for hostile code; the documentation states it does not provide security guarantees against malicious code.

When to use it:

1. Services that should never write to disk or start processes, where an unexpected attempt signals a bug or a compromised dependency.
2. Command-line tools that process untrusted files and should only read one directory.

Combine it with operating system controls, such as a read-only file system and a non-root user, which enforce limits outside the process itself.

In development, attach a debugger and step through code; in production, rely on structured logs, metrics, traces and diagnostic snapshots, because pausing a live process stops every request it is serving.

Development:

• Start Node.js with --inspect and connect a debugger from an editor or browser developer tools to set breakpoints and inspect variables.
• Use --inspect-brk to pause on the first line, for debugging startup code.
• Enable source maps, so stack traces and breakpoints map to the original source when code is compiled.
• Set NODE_DEBUG for verbose output from specific core modules such as http.

Production:

1. Logs and traces with request IDs locate the failing request and the slow step.
2. Diagnostic reports: Node.js can write a JSON report with stacks, heap statistics and resource usage on a fatal error or on a signal.
3. Heap snapshots and CPU profiles on a single instance removed from traffic diagnose leaks and hot spots.
4. Core dumps capture the full process after a crash, for deep native issues.

Never expose the inspector port publicly; anyone who can reach it can run code in the process.

Fake timers replace setTimeout, setInterval and optionally Date with controllable versions, so a test can move time forward instantly instead of waiting. Tests for expiry, retries, debouncing and scheduling become fast and deterministic.

• Enable and tick: the test enables fake timers, then advances time by a number of milliseconds; any timers due in that period fire synchronously.
• Fake Date: controlling the clock as well makes logic based on timestamps, such as token expiry, testable.
• Reset: restore real timers after each test, so tests do not affect each other.

What to test this way:

• Session or cache expiry after inactivity.
• Retry schedules with backoff.
• Rate limiter windows.
• Timeouts that should fire, and ones that should be cancelled.

Alternative without fakes: inject a clock function and a scheduler into the code, so tests can pass their own. This is often cleaner for business logic, and keeps fake timers for code you cannot easily change.

Cross-origin resource sharing lets a browser page from one origin call your API on another. Configure it to allow only the specific origins, methods and headers your frontends need, and treat it as a browser rule, not as authentication.

• Allowlist origins: compare the request's Origin header with a configured list, and echo back only a matching origin. Never reflect any origin while also allowing credentials.
• Credentials: cookies are sent cross-origin only when the client opts in and the server returns Access-Control-Allow-Credentials: true; a wildcard origin is not allowed in that case.
• Preflight requests: browsers send an OPTIONS request before many cross-origin calls; answer it quickly, and set a max-age so browsers cache the result.
• Vary: Origin: when the allowed origin header changes per request, tell caches the response depends on the origin.
• Allowed headers and methods: list only what the frontend uses.

What CORS does not do: it does not stop non-browser clients, such as scripts, from calling your API, so authentication and authorization are still required. For cookie-based sessions, also protect state-changing requests against cross-site request forgery.

Build a small image with only production dependencies installed from the lock file, run it as a non-root user, and start node directly as the main process so it receives shutdown signals.

1. Multi-stage build: install all dependencies and compile in a build stage, then copy only the output and production dependencies into a slim final image.
2. Clean install from the lock file, omitting development dependencies, so the image contains exactly the reviewed versions.
3. Copy dependency manifests first, then the source, so code changes reuse the cached dependency layer.
4. Set NODE_ENV=production, which many libraries use to enable optimizations and disable debug behavior.
5. Run as a non-root user, which official Node.js base images already provide.
6. Start Node.js directly: some package manager script runners do not forward signals, so graceful shutdown never runs.
7. Exclude local files such as tests, local environment files and installed modules from the build context with an ignore file.
8. Set memory flags that match the container limit.

If the service spawns child processes, add a minimal init process so finished children are reaped and signals are forwarded correctly.

Set the old-generation heap limit with --max-old-space-size to roughly 70% to 80% of the container's memory limit, leaving the rest for everything outside the JavaScript heap. If the heap limit is too high, the container is killed for exceeding its memory before the engine's own collector reacts.

Memory a Node.js process uses besides the old-generation heap:

• The young generation, where new objects start.
• Buffers and other external memory, which can be large for file, network and compression work.
• Compiled code, thread stacks and the thread pool.
• Native add-ons and memory allocator overhead.

Why set it explicitly:

• The default limit depends on the Node.js version and the memory the runtime detects, and older versions did not account for container limits.
• An explicit value makes behavior predictable across environments.

Verify under load: watch resident memory against the limit during a realistic test. Services that handle many large Buffers need a lower heap share; services with mostly small objects can use a higher one.

One saturated core with rising latency across all endpoints almost always means the event loop is busy with synchronous work. Find which code holds the main thread, then move it off the request path or make it cheaper.

1. Confirm saturation: event loop delay and utilization should both be high; if delay is low, look at downstream dependencies instead.
2. Check recent changes: a release that added a large serialization, a new regular expression or a synchronous call is the usual suspect.
3. Capture a CPU profile on one instance under load and read the flame graph from the request handlers down.
4. Look for the classic culprits: synchronous crypto, compression or file calls; huge JSON.stringify or JSON.parse; backtracking regular expressions; loops over large arrays; heavy logging.
5. Fix it: use asynchronous APIs, stream large payloads, paginate, cache results, or move computation to worker threads.
6. Scale as a stopgap: more processes help only if the expensive work is spread across requests, not concentrated in one.

A common cause is a keep-alive timeout mismatch: the load balancer keeps idle connections to Node.js open longer than Node.js does. Node.js closes an idle connection, the load balancer reuses it a moment later, the request fails, and the load balancer reports a 502.

sequenceDiagram
  participant L as Load balancer
  participant N as Node.js server
  L->>N: Request on a kept-alive connection
  N-->>L: Response
  N->>N: Idle timeout passes, server closes socket
  L->>N: Next request reuses the closed connection
  N-->>L: Connection reset
  L->>L: Returns 502 to the client

How to confirm it:

• The errors are rare, happen under moderate traffic after idle gaps, and do not appear in Node.js access logs, because the request never reached the handler.
• Load balancer logs show connection resets from the backend.

How to fix it:

1. Set server.keepAliveTimeout higher than the load balancer's idle timeout.
2. Set server.headersTimeout slightly higher than the keep-alive timeout.
3. Check every layer, including proxies and ingress controllers, since each has its own timeout.

Interview tip: stating that the backend must keep idle connections open longer than the proxy in front of it shows real production experience.

Intermittent resets on outgoing calls often come from reusing a pooled keep-alive socket that the other side has just closed, from overloaded servers dropping connections, or from network devices killing idle connections.

1. Check the timing: resets right after idle periods point to stale keep-alive sockets; resets under heavy load point to the server or a proxy rejecting connections.
2. Align idle timeouts: make the client's idle socket timeout shorter than the server's keep-alive timeout, so the client discards sockets before the server closes them.
3. Retry once for safe requests: a reset on a reused socket before any response is safe to retry for idempotent methods.
4. Bound the pool: too many concurrent sockets can hit the other side's connection limits.
5. Check intermediaries: firewalls and network address translation devices silently drop long-idle connections; TCP keep-alive probes or shorter idle times help.
6. Monitor: track resets, retries and socket counts per dependency, so a rising rate is caught before users notice.

Do not blindly retry non-idempotent requests such as payments, because the server may have processed the request before the connection dropped. Use idempotency keys for those.