What does this script print, and why? setTimeout(() => { console.log('timer 1'); Promise.resolve().then(() => console.log('microtask in timer 1')); }, 0); setTimeout(() => console.log('timer 2'), 0);

## The output ``` timer 1 microtask in timer 1 timer 2 ``` ## Why both timers run in that order The two `setTimeout` calls register two independent callbacks with the same delay. They are enqueued in registration order, and the runtime takes one task per turn, so `timer 1`'s callback runs first and `timer 2`'s second. Nothing subtle there — the subtlety is what fits *between* them. ## The checkpoint happens after every task, not once per script Many people internalize the basic puzzle as "synchronous code, then promises, then timers" and stop there. That phrasing is a special case of the real rule: **whenever the call stack empties, the microtask queue is drained completely before the next task is taken.** The end of the top-level script is only the first time the stack empties; the end of every callback is another. So the trace is: 1. Task A runs the first timer callback. It prints `timer 1` and enqueues a promise reaction. 2. The callback returns; the stack is empty. Checkpoint: drain microtasks, printing `microtask in timer 1`. 3. The loop takes the next task — the second timer callback — printing `timer 2`. ## Why this matters beyond the whiteboard This is the rule that makes promise-based code inside a callback behave predictably. If you write: ```js elementHandler(() => { updateModel(); Promise.resolve().then(flushChanges); }); ``` you can rely on `flushChanges` running before any other queued callback observes the model — the checkpoint acts as a "finish what you started" boundary at the end of each unit of work. Frameworks and libraries use exactly this property to batch: do the cheap synchronous mutations now, queue a microtask, and let it perform the single expensive follow-up before anything else runs. It also means a chain started inside a callback completes entirely there: ```js setTimeout(() => { Promise.resolve() .then(() => console.log('a')) .then(() => console.log('b')); }, 0); setTimeout(() => console.log('c'), 0); ``` prints `a`, `b`, `c`. The second `.then` is queued while the first microtask is running, and microtasks queued during a drain are part of the same drain. Only genuinely asynchronous waits — another timer, real I/O — push work past the boundary. ## The mirror-image variant Swap the nesting and the reasoning inverts: ```js Promise.resolve().then(() => { console.log('microtask'); setTimeout(() => console.log('timer from microtask'), 0); }); setTimeout(() => console.log('outer timer'), 0); ``` Here the microtask runs first (before any task), but the timer it schedules is queued *behind* the timer that was already registered, so the output is `microtask`, `outer timer`, `timer from microtask`. Tasks queued later go to the back of the line; microtasks queued later still run in the current drain. Being able to explain both directions is what separates a memorized answer from an understood one. ## Tracing method Keep the three columns, but redraw the microtask column after every task rather than once. Each time a callback returns, ask: did it queue microtasks? Drain them before moving to the next task row. That single discipline handles almost every nested variant an interviewer can construct. ## What a weak answer looks like The common wrong output is `timer 1`, `timer 2`, `microtask in timer 1`, produced by reasoning "all the timers were registered first, so they all run before any promise work". Registration order does not group callbacks across queues; the checkpoint boundary does.