I'll state the ordering rule, then run an example against it. The engine runs synchronous code on the call stack to completion first. Async results arrive as queued jobs in two tiers: the micro-task queue (promise reactions — .then, the continuation after an await, queueMicrotask) and the macro-task queue (setTimeout, setInterval, I/O callbacks). The rule that decides order: after the current task finishes, the loop drains the entire micro-task queue — including micro-tasks scheduled by other micro-tasks — before it ever picks up the next macro-task. So micro-tasks always jump ahead of the next timer.

Run it: synchronous code runs first; a setTimeout(fn, 0) registers fn as a macro-task; a Promise.resolve().then(g) registers g as a micro-task. When the stack clears, the loop drains micro-tasks, so g runs before fn, even with a 0 ms timeout — because the timeout only governs eligibility, and the macro-task isn't considered until the micro-task queue is empty. That ordering is the thing people get wrong, and it's deterministic, not a race.

The edges. Starving the loop: because the loop drains micro-tasks fully before the next macro-task, a micro-task that keeps scheduling more micro-tasks (or a long synchronous block) never yields — timers and I/O callbacks are starved and the UI freezes; that's why heavy CPU work belongs on a worker, not the main thread. await inside a loop is the other trap, and it's two distinct cases: for…of with an await serializes — each iteration suspends and resumes before the next starts, so N awaited calls run one after another; if they're independent you usually want to start them all and await Promise.all(...) to overlap the I/O. My honest boundary: the macro-task families (timers vs. I/O vs. setImmediate) have a defined phase order in Node that differs from the browser's model, and I'd check the runtime's phase diagram before asserting cross-task ordering beyond the micro/macro rule.