Node.js Backend Developer Top 100 Interview Questions

They share the thread pool. File system operations, dns.lookup, asynchronous crypto and compression all queue for the same small set of threads, four by default, so a burst of one kind of work delays all the others.

How to confirm it:

• Latency rises for operations that use the pool, while pure network calls stay fast.
• Event loop delay may be low, because the main thread is idle while it waits for pool results.

How to fix it:

1. Raise the pool size with UV_THREADPOOL_SIZE, set before startup, typically up to the number of cores.
2. Reduce heavy work: cache results, lower compression levels, or move password hashing to a dedicated authentication service or worker pool.
3. Rate-limit expensive endpoints such as login, which also protects against brute-force attempts.
4. Avoid host name lookups per request: reuse connections, or cache DNS results.

A bigger pool helps only when cores are available; if all cores are already busy, more threads just compete for them.

Clients keep WebSocket connections to stateless Node.js gateway processes, messages are stored durably first and then fanned out through a broker to every gateway holding a recipient's connection.

flowchart LR
  A["Client"] -->|WebSocket| B["Gateway process"]
  B --> C["Message service"]
  C --> D["Durable message store"]
  C --> E["Pub-sub broker"]
  E --> F["Other gateway processes"]
  F --> G["Recipients' connections"]
  C --> H["Offline notification queue"]

Key decisions:

• Authenticate on connect, and check membership for every room or conversation a client joins.
• Persist before delivering, so a crash never loses a message that was acknowledged to the sender.
• Message IDs and ordering: assign a per-conversation sequence number, so clients can detect gaps, reorder and fetch missed messages after reconnecting.
• Fan-out: the broker routes each message to the gateways where recipients are connected, keyed by conversation.
• Presence and typing indicators: keep them in a fast, expiring store and accept that they are approximate.
• Offline users: queue push notifications.
• Back-pressure: disconnect clients whose send buffers grow too large.

Scale gateways horizontally, and reconnect clients gradually during deploys to avoid a reconnection storm.

This is an aggregation layer, sometimes called a backend for frontend. Node.js fits it well, because the work is mostly waiting on other services. The design goals are calling dependencies in parallel, bounding the total time and returning useful partial results.

flowchart TD
  A["Client request"] --> B["Aggregation service"]
  B --> C["Profile service"]
  B --> D["Orders service"]
  B --> E["Recommendations service"]
  C --> F["Combine results within deadline"]
  D --> F
  E --> F
  F --> G["Response with optional sections"]

Design points:

1. Parallel calls: start independent requests together, so total time is roughly the slowest call rather than the sum.
2. Overall deadline: give the request a time budget and pass each call an abort signal derived from it.
3. Required versus optional: fail the request if a required source fails, but omit optional sections, such as recommendations, and mark them as unavailable.
4. Caching: cache slow-changing data, such as profiles, with short expiry, and coalesce concurrent loads.
5. Circuit breakers: stop calling a failing dependency for a while, returning the optional fallback immediately.
6. Connection reuse: keep-alive agents per dependency.
7. Shape for the client: return exactly what the screen needs, which reduces payload size and client logic.

Migrate gradually from the edges inward, keeping behavior identical at each step and relying on tests, rather than rewriting everything at once.

1. Add tests around critical flows first, especially error handling, since that is where behavior most often changes.
2. Wrap callback functions with util.promisify, or use the promise versions of core modules, so new code can await them immediately.
3. Convert leaf functions first, those that call nothing else in the codebase, then move up the call tree.
4. Keep both interfaces temporarily where many callers exist, so callers can migrate one at a time.
5. Watch for behavior changes:
   • Errors thrown in async functions become rejections, which need await or .catch in callers.
   • Callbacks that were called twice by mistake now silently ignore the second call.
   • Sequential awaits can make independent operations slower than parallel callbacks were.
6. Lint for floating promises, so a missing await is caught in review.
7. Remove the old interfaces once nothing uses them.

Ship each step separately and watch error rates, so a regression is easy to trace to one small change.

A process can run JavaScript on only one core, so its ceiling is set by the CPU time each request spends on the main thread, not by how long the request waits on I/O.

• max_requests_per_second = 1 / cpu_seconds_per_request
• processes_needed = ceil(target_rate / (max_requests_per_second × target_utilization))

What each term means:

• cpu_seconds_per_request: main-thread time per request, such as parsing, validation, serialization and business logic. Time spent waiting on the database does not count.
• target_utilization: how busy you let each process get, usually 60% to 70%, because event loop delay rises sharply near 100%.

When to use it:

• To estimate how many processes or containers a target load needs.
• To see the impact of optimizing hot code: halving CPU time per request doubles the ceiling.

Measure CPU time per request under load with profiling or event loop utilization, and confirm the estimate with a load test, since garbage collection and thread-pool work add overhead.

Avoid parsing or serializing huge documents in one synchronous call on the main thread. Limit sizes, stream the data in smaller pieces, or move the work to a worker thread.

• Limit request bodies: set a body size limit in the parser and reject larger payloads with status 413, so one request cannot freeze the process.
• Paginate responses: return pages instead of entire collections.
• Stream formats: newline-delimited JSON, one object per line, can be produced and consumed incrementally with streams.
• Streaming parsers: for huge inbound documents, a streaming JSON parser processes values as they arrive.
• Worker threads: when a large document must be handled whole, parse or build it in a worker; transfer the raw bytes to the worker rather than copying a big object.
• Batch imports: accept large uploads as files, process them in a background job, and report progress.

Measure first: time JSON.parse and JSON.stringify on realistic payloads. A few hundred kilobytes is usually fine; tens of megabytes on the request path is not.

Interview tip: mention that the cost is not only the slow request itself, but every other request that waits behind it on the same event loop.

A JavaScript Map remembers insertion order, so it can act as both the lookup table and the recency list. Deleting and re-inserting a key on each access moves it to the newest end, and the first key in iteration order is always the least recently used.

• get: if the key exists, delete it and set it again, then return the value.
• set: delete any existing entry, set the new value, and if the size exceeds the capacity, delete the first key from map.keys().
• Validation: reject a capacity that is not a positive integer.

Production considerations:

• Add expiry times per entry when cached data can change.
• Size by memory, not just count, if values vary greatly in size.
• Coalesce concurrent loads for the same key, so a miss does not trigger duplicate work.
• Each process holds its own cache, so expect different contents across processes.

All operations are constant time on average, which makes this a clean answer to a classic interview exercise.

Create a readable stream for the file, wrap it with readline.createInterface, and loop over lines with for await. Memory stays small however large the file is, and line breaks split across chunks are handled for you.

1. Stream the input: fs.createReadStream(path) reads the file in chunks; in tests, Readable.from turns strings into a stream.
2. Read lines: readline emits complete lines; set crlfDelay: Infinity so Windows-style line endings count as one break.
3. Parse strictly: match each line against a pattern and count malformed lines instead of crashing.
4. Aggregate in a Map: accumulate counts, sums and errors per key as each line arrives.
5. Report once the loop finishes.

Scaling further:

• Compressed logs can be streamed through a decompression stage in the same pipeline.
• Several files can be processed in parallel with worker threads, then merged.
• For continuous logs, the same code can read from a socket or queue instead of a file.

Choose the copy method by what the object contains. Spread syntax copies only the top level; JSON round-tripping loses types; structuredClone makes a true deep copy of most data types.

• Spread or Object.assign: a shallow copy. Nested objects are still shared, so changing one through the copy changes the original.
• JSON.parse(JSON.stringify(x)): a deep copy of plain data only. Dates become strings, Map and Set become empty objects, undefined disappears and BigInt throws.
• structuredClone(x): built in, it deep-copies dates, maps, sets, typed arrays and circular references. It throws on functions and does not keep class instances' prototypes.

When to copy at all:

• Copy request or configuration objects before modifying them, so other code is not affected.
• In hot paths, avoid deep copies of large objects; build a new object with only the fields you need.
• Freezing shared configuration with Object.freeze, recursively if needed, prevents accidental changes without copying.

Walk the object recursively, building a path from each key. When a value is a non-empty plain object, recurse with the longer path; otherwise record the value under the full path.

Decisions to make explicit:

• Arrays: keep them as values, or expand them with index keys such as features.0; keeping them is simpler and usually what configuration and logging need.
• Empty objects: keep them as values, so no key silently disappears.
• Special values: treat null, dates and other non-plain objects as leaf values.
• Dangerous keys: when flattening or unflattening user input, skip __proto__ and constructor to avoid prototype pollution.

Where it is useful:

• Turning nested configuration into environment-style keys.
• Building log fields or search index fields from nested documents.
• Comparing two configurations key by key.

Recursion depth is bounded by the object's nesting, which is small for real data, but untrusted input should have a depth limit.

Read the raw strings with URLSearchParams, convert each one explicitly, apply defaults for missing values, enforce bounds, and allow only known values for options such as the sort order. Return all problems together, so the client can fix them in one go.

• Strict numbers: check the raw string against a digits-only pattern before converting, because Number('') is 0 and parseInt('20abc') is 20.
• Bounds: cap the page size, for example at 100, so clients cannot request a million rows.
• Allowlists: accept only defined sort fields, which also prevents injecting column names into SQL.
• Defaults: apply them only when a parameter is absent, not when it is invalid.
• Errors: respond with status 400 and the list of problems.

Schema validation libraries do this declaratively, but writing it once by hand shows exactly what they must handle.

Keep a Map from topic to a Set of handler functions. subscribe adds a handler and returns a function that removes it; publish calls every handler for the topic and isolates failures, so one broken subscriber cannot stop the others.

Design points:

• Return an unsubscribe function, which makes cleanup easy and avoids listener leaks.
• Copy the handler set before iterating, so handlers can unsubscribe themselves during delivery.
• Catch errors per handler and log them, then continue with the remaining handlers.
• Synchronous or asynchronous: this version delivers synchronously; for slow handlers, queue the work or await handlers with a concurrency limit.

Limits of an in-process bus:

• Events exist only in memory, so they are lost if the process crashes, and other processes never see them.
• For events that must survive restarts or reach other services, use a durable message broker.

It is still useful for decoupling modules inside one service, such as sending an email and updating stock when an order is created.

Node.js is a strong choice when a service spends most of its time waiting on networks and databases, and when sharing JavaScript between frontend and backend helps the team. It is a weaker choice when most work is heavy computation on the request path.

CPU-heavy work can still fit when it is offloaded to worker threads or a separate service, so the event loop stays free for requests.

Other factors: team experience, existing libraries, the operational tooling already in place, and hiring all matter as much as runtime traits. A well-built Node.js service and a well-built service in another runtime are both usually limited by their database first.

Use the package manager's workspaces feature: one repository holds several packages, such as services and shared libraries, with a single lock file and one install for everything. Shared code is linked locally, so changes are visible immediately without publishing.

Benefits:

• One change can update a shared library and every service that uses it, reviewed together.
• One lock file keeps dependency versions consistent across packages.
• Shared tooling, such as lint rules, formatting and test configuration, lives in one place.

Challenges and how to handle them:

1. Build and test only what changed: compute which packages a change affects, including dependents, so the pipeline stays fast.
2. Clear boundaries: packages should import each other only through their declared entry points, never through relative paths into internals.
3. Versioning: decide whether internal packages are versioned independently or always move together.
4. Deployment: each service's image should include only that service and the packages it depends on.
5. Dependency hoisting: packages may accidentally use dependencies they never declared; strict modes in package managers catch this.

Combine secure defaults at every layer: the network edge, the HTTP layer, the application code, the dependencies and the runtime. No single control is enough.

HTTP layer:

• HTTPS only, security headers, strict CORS allowlists, body size limits and rate limits on sensitive endpoints such as login.

Authentication and authorization:

• Slow password hashing, short-lived tokens or secure session cookies, and authorization checks on every request, including object ownership.

Input and output:

• Schema validation with unknown keys rejected, parameterized queries, protection against prototype pollution, and encoding of any data rendered as HTML.

Dependencies:

• Lock files, clean installs, vulnerability scanning, minimal dependencies and install scripts disabled in builds.

Runtime:

• Non-root user, no inspector port exposed, secrets injected from a secret store, and errors that never reveal stack traces to clients.

Operations:

• Logs without secrets, alerts on authentication failures and unusual traffic, and fast patching of both Node.js and dependencies.

Review this list in threat modeling for each new feature, and test it with automated security scans in the pipeline.

Timers in Node.js are minimum delays, not precise schedules. They also keep the process alive, which matters for clean shutdown and for command-line tools.

• Drift: a callback runs only when the event loop is free, so a busy loop delays it. setInterval does not catch up on missed time, and long-running intervals drift away from wall-clock times.
• Overlapping work: if an interval's callback starts async work that takes longer than the interval, runs pile up. Prefer scheduling the next run with setTimeout after the current one finishes.
• Keeping the process alive: an active timer prevents the process from exiting. timer.unref() lets the process exit if that timer is the only thing left, which suits background refreshers.
• Cleanup: clear timers on shutdown, and in tests, so nothing runs after resources are closed.
• Wall-clock schedules: for "every day at 9", compute the delay from the current time each run, or use a scheduler, because intervals drift and time zones change.

Timeouts on promises: timers/promises provides awaitable timers that accept an abort signal, which makes cancellation clean.

Never let incoming data pile up in memory faster than it can be written. Pause or slow the producer while the writer catches up, using streams with backpressure or a bounded queue.

flowchart LR
  A["Fast producer"] --> B["Bounded queue"]
  B --> C["Batch writer"]
  C --> D["Database"]
  B -->|Full| E["Pause the producer"]
  E -->|"Queue drained"| A

1. Streams: if the source is a stream, such as a file or socket, process it with for await or pipeline; reading the next chunk only after the current batch is written applies backpressure automatically.
2. Batch writes: collect rows into batches of a few hundred and write each batch in one statement, which raises the writer's throughput.
3. Bounded queue: for push-based sources, such as events from a message broker, keep an in-memory queue with a maximum size and stop consuming, or pause the subscription, when it is full.
4. Limit concurrency: allow only a few batches in flight, matched to the database pool size.
5. Observe: track queue length and write latency, and alert when the queue stays near its limit.

Never respond to slow writes by raising memory limits or buffering without bounds; that only delays the crash and loses more data when it happens. If the database is permanently slower than the input, the real fixes are bulk loading, partitioning or more capacity.

Make every process interchangeable: keep no essential state in memory, put shared state in external stores, and make background work safe to run anywhere. Then adding processes or containers adds capacity linearly.

flowchart TD
  A["Load balancer"] --> B["Node.js process 1"]
  A --> C["Node.js process 2"]
  A --> D["Node.js process 3"]
  B --> E["Shared session and cache store"]
  C --> E
  D --> E
  B --> F["Database and object storage"]
  C --> F
  D --> F

• Sessions: store them in a shared store, or use signed tokens, so any process can serve any user.
• Uploads and files: write them to shared object storage, not local disk.
• Caches: in-process caches are fine for performance, but correctness must not depend on them; use a shared cache when every instance must agree.
• Scheduled jobs: run them once across the fleet through a queue or a leader lock, not once per process.
• Rate limits and counters: keep them in a shared store.
• WebSockets: use a broker for fan-out, and sticky routing only where a protocol truly needs it.
• Configuration: inject it from the environment, identically for every instance.
• Database: the shared database becomes the bottleneck, so pool connections carefully and add read replicas or caching as load grows.

Interview tip: a quick test is to ask what breaks if a request's next call lands on a different process; every answer to that question is a scaling problem to fix.

Choose one real project and walk through it as a story: the problem, your role, the key decisions, a hard problem you solved and the measured outcome. Interviewers want evidence of judgment, not a list of packages.

1. Context: what the service did, its users and its scale, such as requests per second or open connections.
2. Your role: what you personally designed or built, separate from the team's work.
3. Decisions: how you structured the code, handled async errors, chose the database and caching approach, and why.
4. A hard problem: an event loop blockage, a memory leak, a race condition or a performance bottleneck, with the evidence that led you to the cause.
5. Quality and operations: tests, deployment, monitoring and how you knew it was healthy.
6. Results: concrete numbers, such as "p99 latency fell from 1.2 seconds to 250 ms" or "memory stayed flat after the leak fix".
7. Reflection: what you would do differently now.

What the interviewer is listening for:

• Understanding of the Node.js runtime model, not just framework usage.
• Trade-off reasoning and honest ownership of mistakes.
• Clear, simple explanations of technical choices.

Tell the incident in order: impact, detection, mitigation, diagnosis, root cause and prevention. Show that you restored service first and investigated with evidence, not guesses.

1. Impact: what users experienced and for how long, such as error rates or failed checkouts.
2. Detection: which alert or report surfaced it, and how quickly.
3. Mitigation: what you did to stop the impact before knowing the cause, such as rolling back, disabling a feature or adding capacity.
4. Diagnosis: the signals you used, such as event loop delay, heap growth, CPU profiles, logs and traces, and the hypotheses you ruled out.
5. Root cause: stated plainly, with contributing factors such as a missing timeout or test.
6. Prevention: the code fixes, alerts, tests and process changes that followed, and how you verified they worked.
7. Lessons: what you learned about the system or about responding under pressure.

What the interviewer is listening for:

• Calm prioritization of recovery over root cause in the first minutes.
• Blameless language that focuses on how the system allowed the failure.
• Follow-through, such as an alert that now catches the same problem early.