Every question below is one that gets asked. What we have added is the part that usually goes unsaid: what a strong answer actually demonstrates. Career1 scores interviews for a living, so this is the difference we see between an answer that lands and one that was rehearsed.
How this interview usually runs
Most companies run some version of these stages. Smaller teams often fold two of them into one conversation.
-
01
Screening call
The services you have built and run, at what scale, and whether you write TypeScript.
-
02
Coding exercise
Live or take-home, in JavaScript or TypeScript, and often async: calling an API with limits, processing a stream, or a small endpoint with tests.
-
03
System design or debugging
Design an API or a queue worker, or work out why a described service is slow. The trade-offs you talk through matter more than the diagram.
-
04
Experience deep dive
A production problem you debugged, followed with questions until the details run out.
The event loop and async
-
What happens when you block the event loop, and how would you notice?
What a strong answer shows: The difference between reading about it and living it. Strong answers mention latency climbing across every request, not just the slow one.
-
Explain the difference between process.nextTick and setImmediate.
What a strong answer shows: Precision. Almost everyone knows the phases exist; fewer can say which runs first and why that ever mattered to them.
-
You have 500 records to process through an async API. How do you do it?
What a strong answer shows: Whether you reach for Promise.all on all 500 and take down the downstream service, or talk about batching and concurrency limits.
-
How do you handle an unhandled promise rejection in production?
What a strong answer shows: That you know it terminates the process by default in current Node versions, and that logging it and moving on is not a strategy.
-
What is the difference between Promise.all, Promise.allSettled and Promise.race?
What a strong answer shows: That Promise.all rejects on the first failure while the other promises keep running, and when allSettled is the honest choice. The follow-up is usually how you would cancel the rest.
-
How do you cancel a slow request or operation?
What a strong answer shows: AbortController and AbortSignal, including AbortSignal.timeout, passed through to fetch or the database client, rather than ignoring a result that is still being computed.
Streams, memory and performance
-
When would you use a stream instead of reading a whole file?
What a strong answer shows: Understanding of memory pressure. The best answers come with a story about a file that got bigger than anyone planned for.
-
What is backpressure in Node streams?
What a strong answer shows: That a writable stream signals it is full by returning false from write(), and that stream.pipeline() handles backpressure, errors and cleanup for you. People who piped a fast source into a slow destination have watched memory climb.
-
A Node service leaks memory over a few days. How do you find it?
What a strong answer shows: Method: heap snapshots, comparing over time, and the usual suspects like closures over request scope and unbounded caches.
-
How do you find which part of a slow endpoint is slow?
What a strong answer shows: Measurement before theory: timings or traces around database and external calls, a CPU profile from --cpu-prof or the inspector, and event loop delay from perf_hooks.
-
How would you scale a Node service across CPU cores?
What a strong answer shows: Whether you know your JavaScript runs on a single thread, and can talk about cluster, worker threads, or simply running more containers.
-
A CPU-heavy task such as resizing images slows every request. What are your options?
What a strong answer shows: Getting the work off the main thread: worker threads, a queue with a separate worker process, or a service built for it, weighed against the operational cost of each.
APIs and data
-
How do you spot and fix N+1 queries in a Node API?
What a strong answer shows: Having seen one in a query log: batching with an IN query or a dataloader pattern, and checking the SQL your ORM generates rather than trusting it.
-
How do you make a payment or webhook handler safe to receive twice?
What a strong answer shows: Idempotency keys stored under a unique constraint, and knowing that retries from clients and webhook providers are normal, not an edge case.
-
How do you manage database connections when the service scales horizontally?
What a strong answer shows: Pool size multiplied by instance count against the database's connection limit, including the moment during a deploy when old and new instances both hold connections.
-
How would you add rate limiting to a public API?
What a strong answer shows: Where the counter lives once there is more than one instance, usually Redis or the gateway, which algorithm, and what the client gets back: a 429 with a Retry-After header.
Security
-
How do you handle secrets and configuration in a Node service?
What a strong answer shows: Environment variables or a secrets manager rather than the repository, validation at start-up so a missing value fails fast, and never logging the whole config object.
-
How do you keep npm dependencies from becoming a security problem?
What a strong answer shows: A committed lockfile installed with npm ci, reading audit results with judgement rather than panic, and awareness of supply chain attacks such as malicious install scripts and typosquatted packages.
Working in a real codebase
-
How do you decide between CommonJS and ES modules on a new service?
What a strong answer shows: Awareness of tooling reality rather than fashion, including what breaks in your test runner.
-
What does your error handling look like across an Express or Fastify app?
What a strong answer shows: Whether errors are handled in one place or scattered, and whether the client gets something useful.
-
How do you shut a Node service down gracefully?
What a strong answer shows: Handling SIGTERM: stop accepting connections, let in-flight requests finish within a deadline, close pools, then exit. Anyone deploying on Kubernetes has lost requests by skipping this.
-
What do you log in a production Node service, and how?
What a strong answer shows: Structured logs with a request ID carried through async calls, for example with AsyncLocalStorage, levels that mean something, and no tokens or personal data in the output.
Now practise it out loud
Reading questions is the easy half. Career1's AI interviewer asks questions like these by voice and follows up when an answer is thin. It takes about eight minutes and costs nothing.
Practise first, in private: once a week, no video and no score, with written feedback that is never shared with companies. When you are ready, the vetting interview is a separate single attempt, no retakes: it is recorded, scored and becomes a profile companies can find. You can hide that profile at any time.
Practise this interview freeQuestions people ask
What Node.js topics come up most in interviews?
The event loop, async patterns and their failure modes, streams, and how you debugged something slow in production. Framework specifics come up far less than candidates expect, because teams assume you can learn their framework.
How technical are Node interviews, really?
Usually one conversation about your experience, one live or take-home coding exercise, and one system design or debugging discussion. The debugging conversation is where most candidates separate, because it cannot be crammed.
Should I mention TypeScript in a Node interview?
Yes, if you have used it. Most teams hiring Node developers now write TypeScript, and how you talk about typing an existing JavaScript codebase is a useful signal in itself.
Do I need to know Express, Fastify or NestJS specifically?
Knowing one well is enough for most roles. Interviewers care more about whether you understand what a framework does for you: routing, middleware order, validation and error handling.
What do reviewers look for in a Node take-home project?
Error handling, structure, tests and a README that explains your decisions, read as closely as the features. A smaller project that is finished and robust beats a larger one that breaks on bad input.
Other roles
Preparing for the general questions too? Common interview questions and what they test.
Hiring instead of interviewing? See how Career1 vets applicants for you.