What does this script print, and why? console.log('A'); new Promise((resolve) => { console.log('B'); resolve(); console.log('C'); }).then(() => console.log('D')); console.log('E');

## The output ``` A B C E D ``` Two separate misconceptions have to be cleared to get this right, and interviewers use this shape precisely because it separates them. ## The executor runs synchronously `new Promise(executor)` calls `executor` immediately, on the current call stack, before the constructor returns the promise object. There is no queueing and no deferral. That is why `B` prints between `A` and `E` — the executor body is just part of the top-level script's straight-line execution. This has a practical consequence beyond the puzzle: any expensive or blocking work you put in an executor body blocks the current turn exactly as it would anywhere else. Wrapping a synchronous computation in `new Promise` does not make it asynchronous. ```js new Promise((resolve) => { // still blocks the caller — a promise wrapper is not a thread const total = heavyLoop(); resolve(total); }); ``` ## resolve() is a function call, not a return `resolve` is an ordinary function the constructor handed you. Calling it transitions the promise from pending to fulfilled and records the value. It does **not**: - stop the executor — the rest of the body runs, so `C` prints; - run any reaction callbacks — none are registered yet at that instant; - do anything at all on a second call, since a promise settles once and later `resolve`/`reject` calls are ignored. A common bug follows from the first point: code after `resolve()` keeps running and can throw. Once a promise is settled, a later throw in the executor is swallowed rather than rejecting the promise, so the error disappears. Writing `return resolve(value);` is the usual defensive habit. ## The reaction is always asynchronous By the time `.then(() => console.log('D'))` executes, the promise is already fulfilled. It is tempting to think the callback can therefore run right away — the value exists, nothing is pending. The specification forbids it: a reaction is always delivered as a **promise job** on the microtask queue, never synchronously on the registering stack. That guarantee is deliberate. If callbacks sometimes ran synchronously and sometimes later, every caller of an API returning a promise would have to defend against both, and code could observe half-initialized state depending on the resolution timing. Promises trade a little latency for a uniform rule: your callback runs on a clean stack, after the current synchronous work is done. So `D` waits. `E` prints as part of the script. The script ends, the stack empties, the microtask checkpoint drains the queue, and `D` prints last. ## Tracing it as columns | now (synchronous) | microtasks | |---|---| | A | | | B (executor body) | | | C (after resolve) | | | E | D | Read the left column top to bottom, then the right one — that is the output. ## Variants an interviewer may bolt on - **Resolve later.** Move `resolve()` into a `setTimeout` and `D` moves after the timer callback, because the reaction can only be queued once the promise settles. - **Register `.then` twice.** Both reactions are queued at registration time, in registration order, and both run in the same drain. - **Add `setTimeout(() => console.log('T'), 0)` before the promise.** `T` prints after `D`: microtasks drain before the loop takes the timer task. - **Reject instead of resolve.** With `.then` alone and no rejection handler you get an unhandled rejection; the printed synchronous order is unchanged. ## What the interviewer is grading Not the five letters — the two sentences behind them: *the executor is synchronous* and *reactions are never synchronous*. A candidate who says both, then reads the trace off, has demonstrated the model. A candidate who guesses `A B C D E` has usually merged "the promise is already resolved" with "so the callback runs now", which is exactly the confusion that produces real bugs in initialization code.