Frontend interview answer

Explain the JavaScript Event Loop

HighHardJavascript

By FrontendAtlas Team · Updated Apr 8, 2026

Interview quick answer

JavaScript runs on a single thread, but the real production pitfall is queue ordering: synchronous work runs first, then microtasks drain before the next macrotask, which is why long Promise chains can starve rendering and confuse debugging.

Interview focus

This JavaScript interview question tests whether you can explain JavaScript Event Loop: microtasks, macrotasks, and rendering debug, connect it to production trade-offs, and handle common follow-up questions.

JavaScript Event Loop: microtasks, macrotasks, and rendering debug explanation without falling back to memorized definitions
Event Loop and Async reasoning, edge cases, and production failure modes
How you would answer the most likely JavaScript interview follow-up

Practice more JavaScript interview questions

Interview answer drill

Use this JavaScript interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice more JavaScript interview questions Follow JavaScript mastery study plan Open Essential 60

Full interview answer

The Big Picture

The event loop matters most when you have to debug async UI behavior that still feels blocked. JavaScript runs on a single thread, so the runtime decides whether to keep draining microtasks, take the next macrotask, or finally let the browser paint.

That under-the-hood order is the real production pitfall: many developers assume any async boundary yields rendering time, but a long microtask chain can still freeze the screen.

The Three Main Parts

The JavaScript runtime manages execution using three core parts: the Call Stack, Task Queues, and the Event Loop.

Component	Purpose	Examples / Details
Call Stack	Where synchronous code runs, line by line. If a function takes too long here, everything else waits (blocking).	`console.log`, loops, math operations, synchronous functions
Task Queues (two types)	Where async tasks wait until the stack is clear — split into Microtask and Macrotask queues.	Async callbacks, Promises, timers, I/O events
Microtask Queue	Smaller, high-priority tasks that run immediately after the stack is clear.	`Promise.then`, `queueMicrotask`, `process.nextTick`
Macrotask Queue	Larger, lower-priority tasks that can yield to the browser for rendering between runs.	`setTimeout`, DOM events, I/O, `setInterval`

Call Stack and Task Queues at a glance.

The Event Loop

The event loop constantly checks:

Is the call stack empty?

Any microtasks waiting? → Run all of them.

Take one macrotask and run it.

Then the cycle repeats forever.

JAVASCRIPT

console.log('A');

setTimeout(() => console.log('B (macrotask)'));

Promise.resolve()
  .then(() => console.log('C (microtask)'))
  .then(() => console.log('D (microtask)'));

console.log('E');

// Output:
// A
// E
// C
// D
// B

Why this order?

A and E → run first (synchronous stack).

Then the event loop runs all microtasks → C, D.

Finally, the next macrotask runs → B.

That’s why Promises always run before timers, even when scheduled “at the same time.”

Production debugging example
You set spinner.hidden = false, then immediately queue a long Promise chain. The UI still feels frozen because microtasks drain before the browser gets a paint opportunity.

JAVASCRIPT

button.addEventListener('click', () => {
  spinner.hidden = false;

  Promise.resolve().then(() => {
    for (let i = 0; i < 50000; i += 1) {
      queueMicrotask(() => {});
    }
  });

  // Spinner may still not paint before the microtasks finish.
});

Paint-first fix
If the user must see the UI update first, split heavy work into a macrotask or a frame callback. The follow-up rule is simple: await Promise.resolve() still stays in microtask territory, so it does not guarantee a paint.

JAVASCRIPT

button.addEventListener('click', () => {
  spinner.hidden = false;

  requestAnimationFrame(() => {
    setTimeout(runHeavyWork, 0);
  });
});

Microtasks vs. Macrotasks (Summary)

Type	Examples	Runs When	Priority
Microtask	`Promise.then`, `queueMicrotask`	After the current call stack, before rendering	High
Macrotask	`setTimeout`, `setInterval`, DOM events	After microtasks, allows rendering	Normal

Microtasks run before macrotasks within each event loop cycle.

After each macrotask, all microtasks are drained before the next one starts. That’s why too many microtasks (like recursive Promises) can block rendering.

JAVASCRIPT

function loop() {
  Promise.resolve().then(loop); // microtask recursion
}
loop(); // browser freezes — it never yields control back

In Node.js

The event loop runs through several phases:

timers → pending callbacks → poll → check → close callbacks

Microtasks (Promise.then, process.nextTick) run after each phase, unlike browsers where they run once per loop.

JAVASCRIPT

setTimeout(() => console.log('timer'));
setImmediate(() => console.log('immediate'));
Promise.resolve().then(() => console.log('microtask'));

// Common order:
// microtask → timer → immediate

Still so complicated?

Imagine you’re the only cashier at a store. You serve one customer at a time (the call stack). When a customer needs to grab something, you tell them to step aside (macrotask). But before you call the next one, you handle quick questions like ‘Can I get a receipt?’ (microtasks). You repeat this all day — that’s the event loop!

Summary

JavaScript executes synchronously on a single thread.

The event loop coordinates between the stack and queues.

Microtasks (Promises) always run before macrotasks (timers).

Too many microtasks can freeze rendering.

Use macrotasks for deferred work and microtasks for quick follow-ups.