What the Event Loop Actually Means in an Interview

When someone asks you to explain the event loop, they are not asking for a Wikipedia summary. They are asking: can you reason about asynchronous code without running it?

That distinction matters. Get it right and the rest of the round changes tone.

The model in one sentence

JavaScript runs one thing at a time. Anything that takes "a while" is handed off to the runtime, which calls you back later by placing a task on a queue. The event loop is the rule that decides which queued task runs next.

That's it. Everything else is detail.

The two queues that matter

There are two queues in the browser you need to name out loud:

1. The microtask queue — promises, queueMicrotask, MutationObserver.
2. The macrotask queue — setTimeout, setInterval, I/O, UI events.

The rule: after every task, the engine drains the entire microtask queue before touching the next macrotask. This is the part people get wrong in interviews.

A question that traps everyone

console.log("1");
setTimeout(() => console.log("2"), 0);
Promise.resolve().then(() => console.log("3"));
console.log("4");

The order is 1, 4, 3, 2. If you can say why without hesitation, you've passed the question. The reason: microtasks (the promise) drain before the next macrotask (the timeout).

What to say when you don't know

If the interviewer pushes into Node's process.nextTick or browser rendering phases and you're unsure, say so plainly: "I know microtasks run before macrotasks. I'm less sure where rendering fits — I'd guess between tasks." That answer wins respect. Bluffing loses it.