Nearshore Hiring

Node.js Developer Interview Questions: Full Hiring Guide

Brian Hunt
Brian Hunt
CEO & Founder, Kore BPO
August 20, 2026 12 min read Reviewed 2026
Engineering manager conducting a Node.js developer technical interview via video call
Quick Answer
What are the best Node.js developer interview questions?

The best Node.js interview questions cover four areas: event loop and async behavior (how Promises, microtasks, and the callback queue interact), REST API and architecture design (routing structure, middleware chains, error handling), database patterns (connection pooling, N+1 queries, transaction management), and a live coding segment with a practical backend task. Behavioral questions about async collaboration matter especially for nearshore roles.

Always include at least one live coding segment, not just verbal questions
Avoid algorithm puzzles that test CS theory unrelated to daily Node.js work
For nearshore candidates, assess written English separately from spoken fluency
Download our Node.js JD template to pair with this interview guide

Interviewing Node.js developers is harder than it looks. The ecosystem is broad, the experience levels are wide, and the gap between a developer who has completed Node.js tutorials and one who has built production APIs serving millions of requests is enormous. A poor interview process produces one of two bad outcomes: you hire someone who cannot do the job, or you reject candidates who are genuinely excellent because your questions were not calibrated to assess what actually matters.

This guide gives you a complete interview framework with specific questions, sample strong and weak answers, and a scoring rubric you can hand to any engineer on your team to run a consistent, high-signal interview process. The questions are calibrated for mid-level and senior Node.js roles. For junior roles, skip the system design section and focus on fundamentals and coding.

Section 1: Event Loop and Async Questions

The event loop is the most misunderstood aspect of Node.js, and misunderstanding it causes real production bugs: unhandled promise rejections, memory leaks from unclosed streams, blocking the event loop with synchronous CPU work, and incorrect assumptions about execution order. These questions separate candidates who know Node.js conceptually from those who have debugged real async problems.

Q1 • Mid-Level
“Explain what happens when you call setTimeout(fn, 0) in a Node.js process. Why does it not execute immediately?”
Strong answer: setTimeout with a 0ms delay queues the callback in the timers phase of the event loop. JavaScript is single-threaded, and the current call stack must empty before the event loop can proceed to the timers phase. So even with 0ms delay, the callback executes after all synchronous code in the current tick completes. Microtasks from resolved Promises and queueMicrotask() also execute before the timers phase. A candidate who mentions the event loop phases (timers, pending callbacks, idle/prepare, poll, check, close) is demonstrating depth beyond surface knowledge.
Mid-Level
Q2 • Mid-Level
“What is the difference between Promise.all() and Promise.allSettled()? Give a real use case for each.”
Strong answer: Promise.all() rejects immediately if any promise in the array rejects (fail-fast). Promise.allSettled() waits for all promises to complete regardless of outcome and returns an array of result objects with status and value or reason. Use Promise.all() when all operations must succeed for the result to be valid (e.g., fetching three required data sources to compose a response). Use Promise.allSettled() when you need the results from all operations even if some fail (e.g., sending notifications to multiple channels where partial success is acceptable).
Mid-Level

Debugging and Error Handling

Q3 • Senior
“Your Node.js API has intermittent high-latency spikes every few minutes. The database query times are normal. What would you investigate first?”
Strong answer: Intermittent spikes with normal DB times typically indicate event loop blocking from synchronous CPU work. I would start by using clinic.js or Node’s built-in –prof flag to get a CPU flame graph. Common causes include synchronous JSON.parse() on very large payloads, regular expression backtracking (catastrophic backtracking), or synchronous cryptography operations. Another cause is garbage collection pressure: if the process is allocating large objects rapidly, GC pauses can produce latency spikes. I would also check if there is any setInterval cleanup happening that blocks the poll phase.
Senior
Senior Node.js developer explaining async patterns and event loop behavior during technical interview
Q4 • Mid-Level
“How do you handle errors in async/await code? What happens if you forget to use try/catch?”
Strong answer: Without try/catch, rejected promises in async functions become unhandled promise rejections. In Node.js 15 and later, unhandled rejections terminate the process by default, which is the correct behavior to surface bugs rather than silently swallowing errors. In production, you should wrap route handlers in an error boundary or use an Express error-handling middleware (four-argument function with err, req, res, next) so unhandled errors return structured error responses rather than crashing. For cleanup patterns, using finally blocks for resource cleanup (closing database connections, releasing locks) prevents leaks when an error is thrown mid-operation.
Mid-Level

Section 2: API Design and Architecture Questions

The API design section reveals whether a candidate thinks in terms of maintainability, client contracts, and operational concerns, or only in terms of making individual endpoints work. Good API design questions have no single correct answer, which makes the candidate’s reasoning more informative than the answer itself.

Q5 • Mid-Level
“How would you structure authentication middleware in an Express application? Walk me through the middleware chain.”
Strong answer: Authentication middleware should be a function that receives req, res, and next. It extracts the JWT from the Authorization header, verifies the signature and expiration, attaches the decoded user payload to req.user, then calls next(). If verification fails, it should call next(new AuthenticationError()) and let the global error handler respond with 401. Apply it as a router-level middleware to protected route groups rather than globally, so public routes like health checks and auth endpoints skip it. A strong candidate will also mention that the secret should come from environment variables and that the middleware should handle edge cases: missing header, malformed token, expired token, and token with invalid signature as distinct failure modes returning specific error messages.
Mid-Level

Scaling and Infrastructure

Q6 • Senior
“You need to design a Node.js backend that handles 50,000 concurrent WebSocket connections for a real-time notification system. How do you approach this?”
Strong answer: 50,000 concurrent WebSocket connections per process is feasible in Node because each connection is handled by the event loop without blocking. However, I would horizontally scale this behind a load balancer with sticky sessions or a Redis-based pub/sub adapter (using Socket.IO’s Redis adapter or native ws with a Redis channel broadcast pattern) so multiple Node instances can publish to any connected client. I would use the ws library rather than Socket.IO for raw performance at this scale, implement heartbeats with pong handlers to detect stale connections and clean up, and monitor memory per connection. Connection cleanup is critical: without explicit close event handling and cleanup, stale connections accumulate and leak memory over time.
Senior

Skip the sourcing. Get pre-screened Node.js candidates.

Kore BPO delivers pre-vetted nearshore Node.js developers from Costa Rica ready for your technical interview.

Get Candidates

Section 3: Database and Performance Questions

Node.js APIs almost always sit in front of a database, and the quality of the database integration layer often determines whether a production application is fast and reliable or slow and fragile. These questions assess real production experience with database interaction patterns.

Q7 • Mid-Level
“Explain the N+1 query problem in the context of a Node.js REST API. How do you detect it and fix it?”
Strong answer: The N+1 problem occurs when a query returns N records and then executes an additional query for each record. For example, fetching a list of 100 users and then querying their profiles in a loop results in 101 database round trips. In Node.js with an ORM like Prisma or TypeORM, N+1 is often invisible in the code but shows up in slow endpoints. Detect it by enabling query logging or using an APM tool to count queries per request. Fix it with eager loading (Prisma’s include or TypeORM’s relations with leftJoinAndSelect), or by batching lookups using DataLoader’s approach of collecting IDs from the current tick and issuing one query for all of them.
Mid-Level

Connection Pooling

Q8 • Senior
“How do you implement database connection pooling in a Node.js application and what are the risks of misconfiguring it?”
Strong answer: Connection pooling reuses established database connections instead of opening a new connection on every request. In Node.js, pg (node-postgres) and Prisma both pool connections by default. The pool size should be configured to match the database server’s max_connections minus connections reserved for admin tasks, divided by the number of application instances. Risks of misconfiguration: too small a pool causes request queuing and timeout errors under load. Too large a pool exhausts database server connections and crashes the database. In serverless deployments (Lambda, Vercel), standard connection pooling is problematic because each function invocation can create its own pool. Prisma recommends using pgBouncer in transaction mode for serverless. I would also set idle timeout and connection lifetime to prevent stale connections.
Senior

Section 4: Live Coding Assessment

The live coding segment is the highest-signal part of the Node.js interview. It reveals how candidates think through problems, how they handle ambiguity, and whether they write production-quality code or tutorial-quality code. The right problem is practical, scoped to 30 to 45 minutes, and tests real Node.js skills.

Recommended Coding Problem: Async Aggregation Endpoint

Ask the candidate to implement a single Express route that: (1) accepts a user ID as a URL parameter, (2) fetches the user’s profile and their recent orders in parallel from two separate mocked async functions you provide, (3) handles partial failures gracefully (if orders fail, return user data with an empty orders array and an error flag), and (4) returns a structured JSON response with appropriate HTTP status codes. Provide the mock async functions so the candidate is not writing data access logic from scratch.

What to evaluate: Look for Promise.all() or Promise.allSettled() usage, try/catch structure, correct HTTP status code selection (200, 404, 500), input validation for the user ID parameter, and response shape consistency. The best candidates also add a comment explaining their Promise.allSettled choice and the tradeoff against Promise.all().

Node.js developer writing code during a live coding assessment in a shared editor

What Good Code Looks Like

A strong candidate will reach for destructuring assignment from Promise.allSettled’s result array, use a consistent error shape in the response, and validate that the userId is a valid integer before making any async calls. They will not hardcode status codes as magic numbers and will use named constants or an enum. They may suggest that in a real codebase this logic would be in a service layer rather than directly in the route handler. All of these observations are good signals to record on the scoring rubric.

Red Flags in Live Coding

Watch for: nested then().then() chains instead of async/await (suggests unfamiliarity with modern patterns), missing error handling entirely (suggests tutorial experience only), hardcoded mock data in the response (suggests misunderstanding of the task), and inability to explain code choices when asked follow-up questions (suggests copied patterns without understanding).

Section 5: Behavioral Questions for Nearshore Roles

For nearshore placements specifically, behavioral questions assess two things that technical questions cannot: how the candidate communicates complex technical situations in written English, and how they handle the collaboration challenges inherent in distributed team work. These questions are not soft or optional. Poor scores on this section predict friction and integration problems even for technically excellent candidates.

Behavioral Q1
“Tell me about a time your code change caused a production incident. What happened and what did you do?”
What to listen for: Candidates who have production experience will have a specific story. The quality of the answer reveals ownership (did they say “my code” or “the team’s code”), their incident response process (monitoring, rollback, postmortem), and their attitude toward failure. Strong candidates describe what they learned and changed in their process. Red flag: a candidate who has never caused any production incident and has been in production systems for 3+ years. That is not a good sign; it suggests they are either not contributing meaningfully or not being honest.
Behavioral Q2
“How do you handle code review feedback that you disagree with?”
What to listen for: Candidates should describe a process that involves understanding the reviewer’s reasoning first, asking clarifying questions, and then either being convinced or articulating their own perspective with evidence. Strong candidates see code review as a technical discussion, not a judgment. Weak candidates describe either capitulating to avoid conflict or doubling down on their own approach without engagement. For nearshore roles, the ability to articulate technical disagreement in writing (since asynchronous code review is the default) is particularly important.

Async Communication

Behavioral Q3
“Describe how you would keep your US-based team informed about a feature you are building over a one-week sprint with minimal live meetings.”
What to listen for: This question reveals async communication discipline, which is the core competency for nearshore collaboration. Strong answers describe daily written status updates in Slack with specific progress, blockers, and next steps, plus opening a draft pull request early for visibility. They may mention using Loom or Loom-style video messages for complex technical explanations. Weak answers describe waiting until the PR is complete to share anything, or relying entirely on standup calls for communication. The best candidates proactively surface blockers before they become delays rather than waiting to be asked.
Panel of engineering team members conducting a structured Node.js developer behavioral interview

Section 6: Scoring Framework

Consistent scoring requires a structured rubric. Use this framework across all interviews for the same role to ensure candidates are evaluated on the same criteria regardless of which team member runs the interview.

CategoryWeightExcellent (4)Acceptable (2-3)Poor (0-1)
Event Loop / Async25%Explains all phases, microtasks, practical debuggingKnows async/await and Promises, weak on internalsCannot explain event loop basics
API and Architecture25%Discusses tradeoffs, patterns, operational concernsKnows how to build endpoints, limited design thinkingOnly task-level thinking, no architecture sense
Database and Performance20%Diagnoses N+1, connection pooling, query optimizationKnows basic ORM usage, limited debugging depthCannot explain connection pooling or query issues
Live Coding20%Clean code, error handling, explains choicesWorking code with gaps in error handling or styleCannot complete task or missing critical functionality
Communication10%Clear, concise, asks good clarifying questionsUnderstandable but verbose or occasional confusionUnclear explanations, does not ask questions

Score each category independently on a 1 to 4 scale, multiply by the weight, and sum for a total score out of 4. A score of 3.2 or above is a strong hire recommendation. Between 2.5 and 3.2 is conditional, depending on which category the weakness is in. Below 2.5 is a pass for a mid-level or senior role.

The biggest interview mistake we see clients make is asking too many conceptual questions and not enough practical ones. Node.js is a production runtime. The interview should feel like a production problem, not a pop quiz.

Frequently Asked Questions

Interview Format and Assessment

How long should a Node.js technical interview be?

90 to 120 minutes total split across two sessions works best. Session 1 (60 minutes): concept questions and live coding. Session 2 (45 minutes): system design for senior roles, plus behavioral questions for all levels. Running everything in a single long session creates fatigue that makes both the candidate and the interviewer perform worse. Splitting sessions also lets you decide after session 1 whether session 2 is worth scheduling.

Should I ask LeetCode-style algorithm questions in a Node.js interview?

Only if algorithm work is a significant part of the job. Most Node.js backend roles do not involve sorting algorithms, graph traversal, or dynamic programming in daily work. Asking these questions selects for candidates who have practiced competitive programming problems, not necessarily those who write good production Node.js APIs. Use practical backend tasks instead. The exception is if you are hiring for a role involving search, data processing pipelines, or compiler/interpreter work where algorithmic thinking is genuinely core to the job.

How do I assess TypeScript depth in a Node.js interview?

Ask the candidate to add TypeScript types to the live coding problem. Specifically, ask them to type the response shape with a generic Result type that handles both success and error cases. Strong TypeScript depth shows up in use of generics, utility types (Partial, Omit, Pick, Record), discriminated unions for error handling, and awareness of strict mode implications. Weak TypeScript depth shows up as using “any” everywhere, incorrect return type annotations, or inability to type async function return values correctly.

Evaluating Candidates

What are the biggest red flags in a Node.js developer interview?

The top red flags are: inability to explain the event loop in any meaningful way (suggests shallow Node.js exposure), missing error handling entirely in live code, inability to discuss a real production system they have built (suggests tutorial-level experience), describing async/await as “making code synchronous” (a fundamental misunderstanding), and reluctance to ask clarifying questions during the coding task (suggests either overconfidence or inability to handle ambiguity).

Nearshore-Specific Evaluation

How do I evaluate English fluency for nearshore Node.js candidates?

Evaluate written and spoken English separately. For written fluency, include a take-home exercise that requires a written explanation of a technical decision. Read it for clarity, structure, and whether the meaning is unambiguous. For spoken fluency, the interview itself is the assessment. Note whether you need to ask for repetition frequently, whether the candidate can explain technical concepts clearly in English under mild pressure, and whether their vocabulary for technical subjects is sufficient. Accent is not a concern; clarity and comprehension are.

Should nearshore Node.js candidates do the same technical interview as domestic candidates?

Yes, the technical content should be identical. The additional evaluation layer for nearshore candidates is async communication style and time zone overlap expectations, which you assess through the behavioral section rather than by reducing the technical bar. Applying a lower technical standard to nearshore candidates is both unfair to the candidates and counterproductive to your hiring goals. The nearshore advantage is cost and timezone alignment, not a different technical standard.

Brian Hunt CEO, Kore BPO
Brian Hunt
CEO & Co-Founder · Kore BPO

Brian Hunt is the CEO of Kore BPO, a US-owned offshore hiring and BPO partner based in Dallas, TX. He has spent his career in consulting, international M&A, and building global offshore teams for growing US companies. Kore BPO has placed over 6,200 hires for 257 clients across accounting, marketing, tech, operations, and more.

Hire Node.js Developers Who Pass This Interview

Kore BPO pre-screens every candidate against these technical criteria before they reach your interview stage.

Get Pre-Screened Candidates

First profiles in 10-14 business days.