25 Node.js interview questions
Structure the Node.js interview loop around evidence, not trivia. Start with a short recruiter or hiring manager screen to confirm remote working habits, product context, and recent Node.js experience. Use a technical screen to discuss one real service they built: runtime version, framework, database, deployment, observability, and failure modes. Follow with a practical exercise in Node.js 22 or 24 LTS using TypeScript, tests, and a small API or worker. Add a debugging session that covers async behavior, latency, memory, and production logs. For senior candidates, include system design focused on Node.js constraints. End with a team interview on ownership, code review, incident response, and communication.
Junior Node.js questions
Fundamentals, learning speed and how they debug.
01You are adding a new endpoint to an existing Express or Fastify service. How would you structure validation, error handling, and tests so the endpoint is safe to release?
Listen for: A strong answer separates request validation from business logic, mentions schema validation such as Zod, TypeBox, or JSON Schema, and returns consistent error shapes without leaking internals. They should test success, invalid input, and downstream failures using node:test, Vitest, Jest, or Supertest, and understand why happy-path-only tests are weak.
Red flag: They put validation directly in the controller and rely on manual testing or console output.
02A Node.js API sometimes returns duplicate records after a user clicks submit twice. How would you investigate and fix it?
Listen for: Look for practical reasoning about idempotency, database constraints, request retries, and UI double-submit behavior. They should suggest checking logs and request IDs, adding a unique key or idempotency token, handling constraint violations cleanly, and writing tests that simulate repeated calls rather than adding a simple delay.
Red flag: They only suggest disabling the button in the frontend and do not address server-side correctness.
03How do promises, async/await, and unhandled rejections affect reliability in a Node.js service?
Listen for: They should explain that async/await is syntax over promises, errors must be awaited or returned, and unhandled rejections can escape request handlers or background jobs. Good candidates mention centralized error middleware, wrapping async tasks, logging context, graceful shutdown, and tests that assert rejected paths are handled.
Red flag: They believe try/catch around the server startup catches all asynchronous errors.
04You notice a route works locally but fails in a container. What checks would you make before changing code?
Listen for: A good answer covers environment variables, working directory, Node version, lockfile install behavior, network hostnames, ports, file permissions, and platform differences. They should compare local and container commands, inspect logs, reproduce with the same image, and avoid assuming Docker is broken or rewriting the route.
Red flag: They immediately change application code without checking configuration, runtime, or build artifacts.
05How would you use TypeScript in a Node.js project without letting types give a false sense of safety?
Listen for: They should distinguish compile-time types from runtime validation, mention strict settings, typed configuration, request schemas, and avoiding broad any usage. Strong answers include using inferred types from validation schemas, checking external data at boundaries, and keeping build, test, and lint steps in CI.
Red flag: They say TypeScript removes the need to validate API input or database results.
06A test suite for a Node.js service is slow and flaky. What would you look at first?
Listen for: Listen for isolation and determinism: fake timers where appropriate, stable test data, no shared mutable state, cleanup of sockets and timers, and controlled dependencies. They may use Testcontainers for integration tests, mocks for narrow unit tests, and parallelization only after fixing order dependence and resource leaks.
Red flag: They propose deleting flaky tests or adding arbitrary sleeps as the main fix.
Mid-level Node.js questions
Independent delivery, trade-offs and code quality.
07A production Node.js API has rising p95 latency but CPU looks normal. How would you debug it?
Listen for: Strong candidates look beyond CPU: database queries, connection pool saturation, DNS, TLS, downstream APIs, event loop delay, garbage collection, and queueing. They should use metrics, traces, structured logs, and controlled reproduction. Good answers mention timeouts, cancellation, connection reuse, and separating server latency from client/network latency.
Red flag: They focus only on adding more Node.js instances before identifying the bottleneck.
08How do you design outbound HTTP calls in Node.js so one slow dependency does not degrade the whole service?
Listen for: Look for timeouts, retries with backoff and jitter, circuit breakers or bulkheads where appropriate, per-dependency budgets, AbortController, and undici or built-in fetch behavior. They should avoid retrying non-idempotent operations blindly and should propagate correlation IDs, classify errors, and expose useful metrics.
Red flag: They rely on the default fetch behavior and retry every failed request indefinitely.
09You need to process background jobs in a Node.js service. What trade-offs would you consider between doing it in-process and using a queue worker?
Listen for: They should compare durability, retries, scaling, visibility, deployment coupling, and shutdown behavior. Good answers mention BullMQ, RabbitMQ, SQS, or similar tools, idempotent handlers, dead-letter queues, concurrency limits, and graceful handling of SIGTERM so jobs are not lost during deploys.
Red flag: They run long jobs inside request handlers and assume the process will always stay alive.
10How would you manage database access in a Node.js service using PostgreSQL?
Listen for: A strong answer covers connection pooling, migrations, transactions, indexes, query visibility, and choosing an ORM or query builder deliberately, such as Prisma, Drizzle, Kysely, or node-postgres. They should know how pool size interacts with replicas and serverless platforms, and avoid N+1 queries.
Red flag: They open a new database connection per request and leave transaction boundaries vague.
11A memory leak appears after a release. What is your approach in Node.js?
Listen for: Good answers start by narrowing the change, checking RSS versus heap, and observing heap growth across garbage collections. They may use heap snapshots, clinic.js, --inspect, allocation profiling, and review caches, event listeners, closures, timers, streams, and unbounded queues. They should plan rollback if user impact is high.
Red flag: They restart the process more often and call it solved.
12How do you approach API versioning and backward compatibility for a Node.js service used by multiple clients?
Listen for: They should discuss additive changes, deprecation windows, contract tests, schema evolution, and client communication. Strong candidates distinguish URL, header, and feature-flag approaches, keep old behavior tested, and instrument usage before removing fields. They should avoid breaking consumers because TypeScript compilation passes internally.
Red flag: They change response shapes freely because the current frontend has already been updated.
13What should happen during graceful shutdown of a Node.js service running in Kubernetes or another orchestrator?
Listen for: Listen for handling SIGTERM, stopping new requests, allowing in-flight requests to finish within a deadline, closing database and message broker connections, flushing logs and traces, and marking readiness false. Strong answers include job workers, long-lived streams, keep-alive connections, and testing shutdown behavior locally.
Red flag: They assume process.exit() is the correct shutdown strategy.
Senior Node.js questions
Judgement, architecture and raising the team's bar.
14You inherit a large Node.js monolith with slow delivery and mixed code quality. How would you improve it without a risky rewrite?
Listen for: Look for incremental architecture: mapping domains, improving tests around high-change areas, extracting modules before services, tightening boundaries, and reducing deployment risk. Strong answers mention observability, dependency direction, feature flags, strangler patterns, and aligning changes with product work rather than launching a purity-driven rewrite.
Red flag: They propose immediately splitting everything into microservices without understanding domain boundaries or operational cost.
15How do you decide whether a Node.js service should use clustering, worker_threads, separate services, or a different runtime for CPU-heavy work?
Listen for: They should distinguish I/O-bound request handling from CPU-bound tasks, discuss event loop blocking, serialization cost, failure isolation, deployment complexity, and operational ownership. Good answers include profiling first, using worker_threads for contained CPU work, queues for asynchronous processing, and considering native services only with clear evidence.
Red flag: They say Node.js is single-threaded so it cannot handle any high-throughput workload.
16Describe how you would set engineering standards for a Node.js codebase used by several teams.
Listen for: Strong answers balance consistency with autonomy: TypeScript strictness, linting, formatting, dependency policies, shared error handling, logging conventions, testing layers, security checks, and ADRs. They should explain how standards are adopted through templates, code review, CI, examples, and migration plans rather than mandates alone.
Red flag: They rely on personal review preferences instead of documented, automated standards.
17A team wants to adopt a new framework such as NestJS or Fastify for all Node.js services. How would you evaluate that decision?
Listen for: Look for criteria beyond popularity: runtime performance, plugin ecosystem, TypeScript support, learning curve, testability, maintenance, observability integration, migration path, and fit with team patterns. They should run a small production-like spike, document trade-offs, and avoid locking unrelated services into one choice prematurely.
Red flag: They choose based only on what they personally prefer or what is trending.
18How do you design secure secret and configuration handling for Node.js across local development, CI, and production?
Listen for: They should mention typed config loading, environment separation, secret managers, rotation, least privilege, avoiding secrets in logs and bundles, and failing fast on missing required values. Good answers cover local developer ergonomics, CI masking, container runtime injection, and auditing dependencies that read environment variables.
Red flag: They commit .env files or rely on a shared spreadsheet of secrets.
19You are the senior engineer during an incident where a Node.js service is causing elevated error rates. What do you do in the first hour?
Listen for: Strong candidates prioritize impact reduction: establish incident roles, check recent deploys and dependency health, use dashboards and traces, roll back or disable risky features, communicate status, and preserve evidence. They avoid speculative fixes, watch for cascading failures, and create follow-up actions after stabilization.
Red flag: They debug silently for an hour without communicating or considering rollback.
20How would you reduce dependency and supply-chain risk in a Node.js application?
Listen for: Listen for lockfiles, minimal dependencies, trusted maintainers, npm provenance or package signing where available, automated vulnerability scanning, license checks, dependency review in pull requests, and avoiding install scripts when possible. Good answers include patching strategy, transitive dependency awareness, and not blindly upgrading everything during incidents.
Red flag: They treat npm audit output as either always ignorable or always automatically fixable.
System design Node.js questions
Designing real systems end to end.
21Design a Node.js API for a multi-tenant SaaS product with tenant-specific data isolation, rate limits, and audit logs.
Listen for: A strong design identifies tenant resolution, authorization boundaries, database isolation options, per-tenant rate limiting, structured audit events, and observability labels without leaking data. They should discuss connection pools, migrations, background tasks, and how to test tenant isolation. Good answers avoid putting tenant IDs only in client-supplied payloads.
Red flag: They trust a tenantId field from the request body as the main isolation mechanism.
22Design a real-time notifications system in Node.js for web and mobile clients using WebSockets or Server-Sent Events.
Listen for: Look for connection management, authentication refresh, horizontal scaling with Redis, NATS, or a managed pub/sub layer, backpressure, reconnect behavior, and message ordering guarantees. They should choose WebSockets versus SSE deliberately, handle deploys gracefully, and keep durable notifications separate from transient socket delivery.
Red flag: They store all connected users in one process and assume that scales across instances.
23Design a Node.js file ingestion pipeline for large CSV uploads that validates rows and writes accepted records to PostgreSQL.
Listen for: Strong answers use streams, backpressure, temporary object storage, chunked parsing, row-level validation, batched writes, and clear error reporting. They should avoid loading whole files into memory, consider virus scanning and size limits, make processing resumable or idempotent, and expose job status to clients.
Red flag: They read the entire file into memory and process it inside the HTTP request.
24Design a GraphQL gateway or BFF in Node.js that serves several frontends and calls multiple backend services.
Listen for: They should cover schema ownership, authentication propagation, batching and caching with DataLoader or equivalent, timeouts, partial failures, observability, and avoiding the gateway becoming a business-logic dumping ground. Good answers include persisted queries, query depth limits, and contract testing with backend teams.
Red flag: They forward every client request directly to all services without controlling query cost or failure behavior.
25Design a Node.js event-driven order processing service that consumes payment and inventory events and publishes fulfillment commands.
Listen for: A strong answer discusses message schemas, idempotency keys, ordering, retries, dead-letter queues, outbox or inbox patterns, transactional boundaries, and observability. They should identify where exactly-once is unrealistic, design for at-least-once delivery, and make handlers safe under duplicate or delayed events.
Red flag: They assume the broker guarantees exactly-once processing and skip idempotency.
Build and Debug a Small Node.js Orders Service
Create a TypeScript Node.js 24 LTS service with two HTTP endpoints: create an order and fetch order status. Persist data in PostgreSQL or SQLite, validate input at runtime, and include a background worker that simulates payment confirmation from a queue or in-memory job list. Add tests for success, validation errors, duplicate submissions, and worker failure. Provide a README with setup steps, assumptions, and one paragraph explaining how you would deploy and observe it in production. This can be done as a two-to-three-hour take-home or a live pairing exercise with some scaffolding provided.
How to evaluate it
- Clear separation between HTTP handlers, validation, business logic, persistence, and worker code.
- Correct handling of idempotency, duplicate submissions, and failed background work.
- Meaningful automated tests that cover edge cases without brittle sleeps or shared state.
- Practical production thinking: logging, configuration, shutdown, migrations, and observability notes.
- Readable TypeScript with simple dependencies, clear errors, and maintainable project structure.
Rather skip the interview loop?
Every Octogle Node.js engineer has already passed a technical assessment, system design and a live interview with an engineer who has shipped Node.js. Send a brief and get 3–5 scored profiles in 48 hours.