JavaScript Event Loop Interview Questions

The moving parts

The JavaScript runtime has four pieces that work together:

1. Call Stack — where code executes. Synchronous, one frame at a time, LIFO (last in, first out). When the stack is empty, the event loop checks the queues.
2. Web APIs / C++ APIs — provided by the browser or Node.js (not JavaScript). Handles timers, network requests, I/O, DOM events. When they complete, they push callbacks into a queue.
3. Microtask Queue — high-priority callbacks. Fed by Promises (.then/.catch/.finally), queueMicrotask(), and MutationObserver. Drained completely before any macrotask runs.
4. Macrotask Queue (Task Queue / Callback Queue) — regular-priority callbacks. Fed by setTimeout, setInterval, setImmediate (Node.js), requestAnimationFrame (browser), and I/O handlers. One task is taken per event loop cycle.

The event loop algorithm — exact order

This is the precise sequence the event loop runs, over and over:

1. Pick one macrotask from the macrotask queue and push it onto the call stack. Run it to completion.
2. When the call stack empties, drain the entire microtask queue — run every microtask, including any new microtasks queued by the microtasks themselves, until the queue is empty.
3. If needed, render the browser frame (browser only — between each macrotask).
4. Return to step 1 — pick the next macrotask.

The critical rule: all microtasks run before the next macrotask, no matter how many microtasks are queued.

Call stack walkthrough

function third()  { console.log('third')  }
function second() { third();  console.log('second') }
function first()  { second(); console.log('first')  }

first()

// Call stack frames (top = currently executing):
// 1. [first]              — first() called
// 2. [second, first]      — second() called inside first
// 3. [third, second, first] — third() called inside second
// 4. [second, first]      — third() returns, logs 'third'
// 5. [first]              — second() returns, logs 'second'
// 6. []                   — first() returns, logs 'first'
//
// Output: 'third', 'second', 'first'

setTimeout(fn, 0) — not "immediate"

setTimeout(fn, 0) does not run immediately. It schedules fn as a macrotask. The current synchronous code, then all microtasks, run first:

console.log('1 — sync start')

setTimeout(() => console.log('2 — setTimeout'), 0)

console.log('3 — sync end')

// Output:
// 1 — sync start
// 3 — sync end
// 2 — setTimeout
//
// setTimeout fires AFTER the current call stack clears

Promises — microtasks, not macrotasks

console.log('1 — start')

setTimeout(() => console.log('2 — setTimeout'), 0)

Promise.resolve()
  .then(() => console.log('3 — promise 1'))
  .then(() => console.log('4 — promise 2'))

console.log('5 — end')

// Output:
// 1 — start
// 5 — end
// 3 — promise 1    ← microtask before setTimeout
// 4 — promise 2    ← microtask before setTimeout
// 2 — setTimeout   ← macrotask last
//
// Why: synchronous runs first → call stack clears →
// microtask queue drained (both promises) → macrotask runs

The full priority order — a complex example

console.log('1')

setTimeout(() => console.log('2'), 0)

Promise.resolve().then(() => {
  console.log('3')
  setTimeout(() => console.log('4'), 0)
})

Promise.resolve().then(() => console.log('5'))

console.log('6')

// Let's trace exactly:
// Sync:        1, 6
// After sync, microtask queue has: [log 3 + inner setTimeout, log 5]
// Microtask 1: logs 3, schedules setTimeout(log 4) → macrotask queue: [log 2, log 4]
// Microtask 2: logs 5
// Microtask queue empty → run macrotask: log 2
// Run macrotask: log 4
//
// Final output: 1, 6, 3, 5, 2, 4

queueMicrotask() — explicit microtask scheduling

console.log('sync 1')

queueMicrotask(() => console.log('microtask'))

console.log('sync 2')

// Output: sync 1, sync 2, microtask
// queueMicrotask is identical in priority to Promise.then

Starvation — when microtasks block macrotasks forever

Because microtasks drain completely before any macrotask runs, an infinite microtask loop will freeze the page:

// This freezes the browser — the macrotask queue never gets a turn
function runForever() {
  Promise.resolve().then(runForever)
}
runForever()

// Compare: this doesn't freeze — each setTimeout is a macrotask,
// so the browser gets to render and process events between each call
function runYieldingly() {
  setTimeout(runYieldingly, 0)
}
runYieldingly()

Node.js specifics — extra queues

Node.js has two additional queue types not in browsers:

// process.nextTick() — runs before any other microtask
// Technically its own queue, checked before the Promise microtask queue

console.log('1 — sync')

setTimeout(() => console.log('2 — setTimeout'), 0)

Promise.resolve().then(() => console.log('3 — promise'))

process.nextTick(() => console.log('4 — nextTick'))

console.log('5 — sync end')

// Node.js output:
// 1 — sync
// 5 — sync end
// 4 — nextTick      ← nextTick queue runs before Promise microtasks
// 3 — promise
// 2 — setTimeout

// setImmediate() — macrotask scheduled to run in the check phase
// Runs after I/O callbacks, before timers in the same iteration
// In practice: setImmediate fires before setTimeout(fn, 0) in I/O callbacks

async/await is event loop sugar

Every await is a yield point. After awaiting, the rest of the async function resumes as a microtask:

async function fetchAndLog() {
  console.log('A — before await')
  const result = await Promise.resolve('data')
  console.log('B — after await:', result)  // this is a microtask callback
}

console.log('1 — before call')
fetchAndLog()
console.log('2 — after call')

// Output:
// 1 — before call
// A — before await   ← runs synchronously up to the await
// 2 — after call     ← resumes synchronous code after fetchAndLog() yields
// B — after await: data  ← microtask resumes the async function

requestAnimationFrame — the rendering queue

// Browser only — runs before the next paint, after macrotasks
// Sits between the macrotask and the next macrotask in the rendering step

requestAnimationFrame(() => {
  // Guaranteed to run before the next frame is painted
  // Use for smooth animations — not setTimeout
  element.style.transform = `translateX(${x}px)`
})

The complete priority order (browser)

// From highest to lowest priority:
// 1. Current synchronous code (call stack)
// 2. process.nextTick callbacks (Node.js only)
// 3. Promise microtasks (.then, .catch, .finally, queueMicrotask)
// 4. requestAnimationFrame callbacks (before next paint)
// 5. setTimeout / setInterval / I/O callbacks (macrotasks)
// 6. setImmediate (Node.js, in I/O context)