Most Common Mistakes in Node.js Interviews (And How to Fix Them)

Node.js developers often have more practical experience than their interview performance suggests. They have built production systems, handled real concurrency challenges, and debugged obscure async issues. But interviews require precise articulation of foundational concepts — and experienced developers sometimes stop consciously thinking about these concepts because they simply know them intuitively.

The following are the most common mistakes in Node.js interviews, what correct understanding looks like, and what strong answers sound like to an interviewer.

Mistake 1: Saying "Node.js Is Single-Threaded" Without Qualification

This is the most common and most consequential mistake in Node.js interviews. The statement is both true and dangerously incomplete.

Why candidates say it: It appears in countless tutorials and is technically accurate for the JavaScript execution context.

The complete picture: JavaScript execution in Node.js runs on a single thread — only one piece of JavaScript runs at a time. But the Node.js runtime is not single-threaded. The libuv library underneath Node.js maintains a thread pool (default: 4 threads) for operations the OS cannot handle asynchronously natively. This includes file system operations, DNS resolution in some cases, and crypto operations via the built-in crypto module.

Network I/O, by contrast, is handled by the OS kernel asynchronously and does not consume thread pool threads at all.

For CPU-intensive work, Node.js 12+ introduced Worker Threads, which spawn separate V8 contexts with their own JavaScript execution threads, communicating via MessageChannel.

Strong interview answer: "The JavaScript event loop is single-threaded — only one callback runs at a time, and there is no shared mutable state between JavaScript contexts. But the runtime itself uses libuv's thread pool for blocking I/O operations. For CPU-intensive work, Worker Threads are the right tool: they run separate V8 instances and exchange data via messages or SharedArrayBuffer."

Mistake 2: Getting Queue Priority Wrong

The event loop has multiple queues processed in a specific order per tick. Most candidates know there is a "callback queue" but conflate all async work into one bucket. This leads to wrong answers about execution order — which interviewers test directly.

The actual ordering per event loop tick:

1. Synchronous code on the call stack runs completely first
2. process.nextTick() callbacks — all of them, before anything else async
3. Microtask queue: resolved Promise callbacks (.then, async/await continuations)
4. Macro-task queues, one task per tick: timers (setTimeout/setInterval), pending I/O callbacks, setImmediate callbacks, close callbacks

The diagnostic question every Node.js interviewer uses:

setTimeout(() => console.log('timeout'), 0)
Promise.resolve().then(() => console.log('promise'))
process.nextTick(() => console.log('nextTick'))
console.log('sync')

Output: sync, nextTick, promise, timeout.

Candidates who get sync and timeout right but swap nextTick and promise reveal that they understand Promises but have not internalized process.nextTick's special priority. That distinction matters in practice: process.nextTick is designed for cases where you need to defer something until after the current operation but before any I/O.

The follow-up risk: Recursive process.nextTick() calls — a nextTick that schedules another nextTick — will starve the I/O queue indefinitely. This is a known footgun and a common follow-up question.

Mistake 3: Assuming async/await Means Non-Blocking

Candidates often conflate the async keyword with non-blocking execution. They are not the same thing.

The confusion: async/await is syntax for working with Promises. Whether something is non-blocking depends on what happens inside the async function, not on whether it is declared async.

// This BLOCKS the event loop despite looking async
async function processData(rawData) {
  const result = heavyJsonTransformation(rawData) // synchronous, expensive
  return result
}

// await does not help here — the work inside is synchronous
const output = await processData(largeDataset)

Wrapping synchronous CPU work in an async function accomplishes nothing. The event loop is blocked for the full duration.

What actually blocks the event loop: CPU-intensive synchronous operations (large JSON.parse, synchronous crypto), synchronous file system calls (fs.readFileSync), deeply nested loops over large datasets, and regex operations with catastrophic backtracking potential on user-controlled input.

Strong answer to "how do you keep Node.js responsive under load?": "For I/O, use the async APIs — the runtime handles it in the thread pool or via the OS. For CPU work, use Worker Threads to move computation off the main thread, or break large jobs into chunks yielded with setImmediate so other callbacks can run between chunks. For very heavy computation, offloading to a separate service is often the right architectural call."

Mistake 4: Incomplete Async Error Handling

Error handling across callback, Promise, and async/await patterns is a practical area where conceptual gaps show up directly in code. Interviewers often ask candidates to spot the bugs.

// CALLBACK — error is the first argument, always
fs.readFile('config.json', (err, data) => {
  if (err) throw err         // WRONG: throws in callback context, becomes unhandled
  if (err) return handle(err) // CORRECT
})

// PROMISE — rejection must be caught, always
getData()
  .then(transform)
  .then(save)             // WRONG: rejection from getData() is silently dropped

getData()
  .then(transform)
  .then(save)
  .catch(handleError)    // CORRECT: catches rejections from entire chain

// ASYNC/AWAIT — wrap in try/catch
async function run() {
  try {
    const data = await getData()
    return await save(transform(data))
  } catch (err) {
    handleError(err)
  }
}

The parallel operations tradeoff — a common follow-up:

// Promise.all — fast-fail: if any promise rejects, the entire call rejects immediately
const [users, posts] = await Promise.all([getUsers(), getPosts()])

// Promise.allSettled — all promises run to completion regardless of individual failures
const results = await Promise.allSettled([getUsers(), getPosts()])
// results[0].status === 'fulfilled' | 'rejected'

Knowing when to use allSettled versus all — specifically, that allSettled is right when you need all results even if some fail — signals real async experience beyond tutorial examples.

Mistake 5: Vague Answers About Memory Leaks

"How do you debug a memory leak?" is a standard Node.js interview question. Most candidates say "use profiling tools." That does not demonstrate whether you know what to look for or how the process actually works.

Common sources of memory leaks:

• Event listeners not removed: adding listeners in hot code paths without corresponding .removeListener() calls, especially on long-lived EventEmitter instances
• Closures holding references: async callbacks that close over large data structures after the work is done, preventing garbage collection
• Timers not cleared: setInterval that accumulates state across invocations
• Unbounded caches: in-memory Maps or arrays used as caches without eviction policies
• Streams not consumed: a Readable stream with no data consumer will buffer indefinitely

The actual debugging process:

1. Run the process with --inspect to enable the V8 inspector
2. Connect Chrome DevTools (via chrome://inspect) or the VS Code debugger
3. Take heap snapshots at intervals: immediately on startup, after normal load, after the suspected leak period
4. Use the Comparison view in DevTools memory profiler — objects growing between snapshots are candidates
5. For production, node --heap-prof generates a sampling heap profile; the clinic suite (clinic doctor, clinic heapprofiler) automates analysis with a focused report

Describing this workflow — naming the tools, explaining the comparison approach — is what separates a strong answer from a vague one.

Building This Knowledge

Node.js interview performance correlates strongly with one variable: how often you have had to explain these concepts to someone else. The developer who has mentored junior engineers or written internal documentation almost always performs better than the equally skilled developer who has only ever used Node.js solo.

If you have not had those opportunities, deliberate practice fills the gap. Talk through the event loop until you can explain it precisely and concisely without notes. Write example code for each error-handling pattern. Debug a real memory leak scenario in a test environment.

Practice Node.js interview questions with AI feedback on Zavnia

Read: How to prepare when your first round is an AI interviewer