JavaScript Event Loop Interview Questions

The four components of the event loop

1. Call Stack — LIFO stack of execution contexts. Each function call pushes a frame; return pops it. When the stack is empty, the engine is idle and the event loop picks the next task.
2. Web APIs (Browser Host Environment) — the browser's parallel capabilities outside the JS thread: setTimeout, fetch, addEventListener, requestAnimationFrame. When they complete, they push callbacks into the appropriate queue.
3. Macrotask Queue (Task Queue) — FIFO queue. The event loop picks ONE macrotask per cycle. What goes here: setTimeout, setInterval, setImmediate (Node), I/O callbacks, postMessage, MessageChannel.
4. Microtask Queue (Job Queue) — higher priority. FULLY DRAINED after every task before the next macrotask. What goes here: Promise.then/catch/finally, queueMicrotask(), MutationObserver, async/await continuations.

The event loop algorithm — exactly, step by step

1. Execute the oldest task from the macrotask queue (or the initial script on page load)
2. After the task finishes (call stack empty): drain the entire microtask queue
   • Execute each microtask in order
   • If a microtask queues another microtask — execute it immediately (still in this drain)
   • Keep going until the microtask queue is completely empty
3. Browser only: if a rendering frame is due (~every 16.67ms at 60fps), run requestAnimationFrame callbacks, then paint/composite the frame
4. Return to step 1 — pick the next macrotask

What goes where — the complete classification table

The fundamental rule — microtasks always win over macrotasks

console.log('1 — sync')
 
setTimeout(() => console.log('2 — setTimeout'), 0)
 
Promise.resolve()
  .then(() => console.log('3 — promise 1'))
  .then(() => console.log('4 — promise 2'))
 
console.log('5 — sync')
 
// Output:
// 1 — sync
// 5 — sync
// 3 — promise 1     ← microtask, drains before setTimeout
// 4 — promise 2     ← microtask queued by promise 1
// 2 — setTimeout    ← macrotask, last

Step-by-step trace:

1. Script starts (first macrotask). Call stack: [main script]
2. '1 — sync' logs → pops
3. setTimeout → Web API registers 0ms timer → callback queued to macrotask queue
4. Promise.resolve() already resolved → .then('promise 1') queued to microtask queue
5. '5 — sync' logs → pops. Script ends. Call stack empty.
6. Drain microtasks: 'promise 1' runs → .then('promise 2') queued → 'promise 2' runs → microtask queue empty
7. Pick next macrotask: setTimeout callback → '2 — setTimeout'

Chained .then — understanding multi-tick microtask ordering

// Critical: returning a Promise from .then adds 2 extra microtask ticks
Promise.resolve()
  .then(() => {
    console.log('A')
    return Promise.resolve('B')   // returning a PROMISE from .then
  })
  .then((v) => console.log(v))   // delayed by 2 extra ticks
 
Promise.resolve()
  .then(() => console.log('C'))
  .then(() => console.log('D'))
 
// Output: A, C, D, B

When a .then callback returns a plain value, the next .then is queued immediately (1 microtask tick). When it returns a Promise, JavaScript must invoke a PromiseResolveThenableJob to unwrap it — adding 2 extra microtask ticks before the next .then fires. This causes A, C, D, B rather than A, B, C, D.

This is a senior-level question asked at Google, Atlassian, and CRED.

async/await — what it compiles to

async function main() {
  console.log('A')
  await Promise.resolve()   // suspends here
  console.log('B')          // runs as microtask continuation
}
 
main()
console.log('C')
 
// Output: A, C, B

await x is approximately Promise.resolve(x).then(restOfFunction). The async function suspends, returns a pending Promise to the caller, and the caller continues synchronously. When the awaited value resolves, the rest of the function is queued as a microtask.

// Multi-await trace
async function a() {
  console.log('a1')
  await b()
  console.log('a2')
}
async function b() {
  console.log('b1')
  await null
  console.log('b2')
}
 
a()
console.log('sync')
 
// Output: a1, b1, sync, b2, a2
// a1: sync. b1: sync (b called from a). await null: b suspends → a suspends (b returned pending promise).
// 'sync': runs. Microtask: b resumes → 'b2' → b resolves → a's continuation queued → 'a2'

The hardest event loop question — mixed macro and micro

console.log('1')
 
setTimeout(() => {
  console.log('2')
  Promise.resolve().then(() => console.log('3'))
}, 0)
 
Promise.resolve()
  .then(() => {
    console.log('4')
    setTimeout(() => console.log('5'), 0)
  })
 
setTimeout(() => console.log('6'), 0)
 
console.log('7')
 
// Output: 1, 7, 4, 2, 3, 6, 5

Trace:

1. Sync: '1', register timer-2, queue microtask-4, register timer-6, '7'
2. Macrotask queue: [timer-2, timer-6]
3. Microtask: '4' runs → registers timer-5. Macrotask queue now: [timer-2, timer-6, timer-5]
4. Macrotask: timer-2 → '2' → queues microtask-3
5. Drain microtasks: '3'
6. Macrotask: timer-6 → '6'
7. Macrotask: timer-5 → '5' (added last, runs last)

queueMicrotask — explicit microtask scheduling

console.log('start')
 
queueMicrotask(() => console.log('microtask'))
setTimeout(() => console.log('timeout'), 0)
 
console.log('end')
 
// Output: start, end, microtask, timeout

queueMicrotask() explicitly schedules a microtask without allocating a Promise object — slightly cheaper than Promise.resolve().then(fn). Useful for deferring work until after the current task without yielding to macrotasks.

Starving the macrotask queue — infinite microtask recursion

function flood() {
  Promise.resolve().then(flood)   // microtask queues another microtask → infinite
}
setTimeout(() => console.log('never runs'), 0)
flood()
// The setTimeout callback NEVER fires
// Microtask queue never empties → macrotask queue never gets picked

This freezes the browser (or hangs the Node process). No user interactions, no renders, no macrotasks — ever. This is why infinite async recursion should use setTimeout to yield:

async function yieldingLoop() {
  while (shouldContinue()) {
    doWorkChunk()
    await new Promise(r => setTimeout(r, 0))   // yield to event loop — allow renders and input
  }
}

requestAnimationFrame — the rendering checkpoint

requestAnimationFrame(() => console.log('rAF'))
setTimeout(() => console.log('setTimeout 16ms'), 16)
Promise.resolve().then(() => console.log('promise'))
 
// Approximate output:
// promise      ← microtask, always first
// rAF          ← fires before next browser paint (~16.67ms from last frame)
// setTimeout   ← macrotask, fires when timer expires

rAF callbacks execute at the start of each browser frame (after microtasks drain, before the frame is painted). They are not macrotasks — they have their own animation frame callback queue. The precise order each frame: macrotask → drain microtasks → rAF callbacks → paint. Using rAF for animations ensures they are synchronised to the display refresh cycle. setTimeout is not synchronised — it causes jank.

The 60fps budget — JavaScript blocks rendering

The browser targets 60 frames per second = one frame every 16.67ms. Within each frame: JavaScript runs → style → layout → paint → composite. If JavaScript alone takes longer than ~10ms, the frame budget is blown and the browser drops a frame. Tasks longer than 50ms are classified as Long Tasks and appear as jank.

// Blocking — 300ms of sync work, page completely frozen
function blockingWork() {
  let sum = 0
  for (let i = 0; i < 1_000_000_000; i++) sum += i
  return sum
}
 
// Non-blocking — yield every 100k iterations via setTimeout
async function chunkedWork() {
  let sum = 0
  for (let i = 0; i < 1_000_000_000; i++) {
    sum += i
    if (i % 100_000 === 0) {
      await new Promise(r => setTimeout(r, 0))   // yield to event loop
    }
  }
  return sum
}

setTimeout — delay is a minimum, not a guarantee

const start = Date.now()
setTimeout(() => {
  console.log(Date.now() - start + 'ms')  // at least 0ms, but usually 1-5ms
}, 0)
 
// The HTML spec requires a minimum 4ms for nested setTimeout (5+ levels deep)
function nested(n) {
  if (n > 8) return
  setTimeout(() => {
    console.log('depth', n)   // depths 1-4: ~0ms. depth 5+: ~4ms minimum per HTML spec
    nested(n + 1)
  }, 0)
}
nested(1)

setTimeout 0ms fires as fast as the event loop allows — after the current call stack empties and all microtasks drain. If a synchronous function takes 500ms, your setTimeout(fn, 0) fires 500ms+ later.

setInterval drift and the fix

// setInterval accumulates drift — callback execution time delays the next fire
setInterval(() => {
  doWork()   // if doWork takes 5ms and interval is 10ms, effective interval becomes 15ms
}, 10)
 
// Drift-compensated pattern using setTimeout
function preciseInterval(fn, interval) {
  let expected = Date.now() + interval
  function tick() {
    const drift = Date.now() - expected
    fn()
    expected += interval
    setTimeout(tick, Math.max(0, interval - drift))   // compensate for drift
  }
  setTimeout(tick, interval)
}

Promise.all — what actually happens in the event loop

// All three fetches START IMMEDIATELY — they all go to Web APIs concurrently
const p1 = fetch('/api/users')      // HTTP request in browser's network layer
const p2 = fetch('/api/posts')      // another concurrent HTTP request
const p3 = fetch('/api/comments')   // and another
 
// JavaScript is free while all three are in-flight
const [users, posts, comments] = await Promise.all([p1, p2, p3])
// Total time ≈ max(t1, t2, t3) — not t1+t2+t3

Promise.all does NOT queue promises sequentially. The async operations (fetch calls) all start in the Web API layer simultaneously. JavaScript yields at await. As each response arrives, its resolve callback is queued. When the last one resolves, Promise.all resolves — and the continuation is a microtask.

Sequential vs parallel async — the most costly interview bug

// SEQUENTIAL — each await waits for the previous. Total = t1 + t2 + t3
async function sequential(ids) {
  const results = []
  for (const id of ids) {
    results.push(await fetchUser(id))   // one at a time
  }
  return results
}
 
// PARALLEL — all start immediately. Total = max(t1, t2, t3)
async function parallel(ids) {
  return Promise.all(ids.map(id => fetchUser(id)))   // all at once
}
 
// If each fetchUser takes 100ms:
// sequential([1,2,3]) → ~300ms
// parallel([1,2,3])   → ~100ms

The sequential pattern in for...of with await is one of the most common performance bugs in production code at Razorpay, Swiggy, and Flipkart. Always use Promise.all when operations are independent.

Node.js event loop — phases (different from browser)

Node's event loop has explicit phases powered by libuv:

1. timers — setTimeout and setInterval callbacks whose delay has expired
2. pending callbacks — I/O callbacks deferred from previous iteration
3. idle, prepare — internal libuv use
4. poll — retrieve new I/O events; execute their callbacks; block here if nothing is pending
5. check — setImmediate callbacks
6. close callbacks — 'close' events (e.g. socket.on('close', ...))

Between every phase, Node drains the microtask queue (Promise.then) AND the nextTick queue (process.nextTick — which fires BEFORE Promise microtasks).

Node.js: process.nextTick vs Promise.then vs setImmediate

console.log('start')
 
setImmediate(() => console.log('setImmediate'))
setTimeout(() => console.log('setTimeout'), 0)
Promise.resolve().then(() => console.log('Promise'))
process.nextTick(() => console.log('nextTick'))
 
console.log('end')

// Node.js output:
// start
// end
// nextTick    ← nextTick queue fires before Promise microtasks
// Promise     ← microtask queue
// setTimeout  ← timers phase (may come before setImmediate at top level — non-deterministic)
// setImmediate ← check phase

// Inside an I/O callback: setImmediate ALWAYS before setTimeout
const fs = require('fs')
fs.readFile(__filename, () => {
  setTimeout(() => console.log('timeout'), 0)
  setImmediate(() => console.log('immediate'))
})
// Output: immediate, timeout (guaranteed inside I/O callback)
// Because: we're in poll phase, next phase is check (setImmediate), then timers

Web Workers — truly parallel event loops

// Main thread
const worker = new Worker('worker.js')
worker.postMessage({ nums: largeArray })   // sends to worker's separate event loop
worker.onmessage = (e) => {
  console.log('result:', e.data)           // receives when worker posts back
}
 
// worker.js — completely separate event loop, no DOM, no shared memory (except SharedArrayBuffer)
self.onmessage = (e) => {
  const result = heavyCPUWork(e.data.nums)  // doesn't block main thread
  self.postMessage(result)   // queues a macrotask in main thread's macrotask queue
}

Workers have their own call stack, event loop, and memory. They cannot access the DOM. Communication via postMessage creates a macrotask on the receiving side. This is the only way to perform CPU-intensive work without blocking the main thread.