To predict asynchronous JavaScript output, first finish the current synchronous work, then reason about promise reactions and later tasks. Do not read a timer delay as a promise that its callback will run at an exact wall-clock time.

The worked ordering example is for an ordinary browser script. Node has additional scheduling details, so a browser answer should not silently become a universal claim about every JavaScript host.

Which line runs first?

const events = [];
events.push("start");
setTimeout(() => {
  events.push("timer");
  console.assert(events.join(",") === "start,end,promise,after,timer");
}, 0);
Promise.resolve()
  .then(() => events.push("promise"))
  .then(() => events.push("after"));
events.push("end");

The synchronous start and end entries are recorded before the promise reactions run. The reactions in the chain then add promise and after. The timer callback runs in a later task. A zero delay does not insert it between the two synchronous statements.

Why does a second then wait for the first?

A then call returns a new promise. The next handler follows that promise's result. If a handler returns another promise, the chain adopts its eventual outcome. If it throws, the chain moves onto the rejection path until a suitable handler deals with it.

This is why missing a return can change behavior. Starting asynchronous work inside a handler without returning or awaiting it can leave the outer chain unable to represent that work's completion or failure.

Does an async function always wait for everything inside it?

No. It returns a promise for its own completion. Work deliberately started and left unawaited can outlive that completion. The async keyword does not discover every promise created in the function and automatically join them.

async function recover() {
  try {
    return await Promise.reject(new Error("sample failure"));
  } catch {
    return "handled";
  }
}
recover().then(value => console.assert(value === "handled"));

The await places the rejection on the function's try/catch path. Without reasoning about where an error is observed, it is easy to write a catch that never handles the asynchronous failure you intended it to handle.

What does Promise.all guarantee?

Its successful result preserves the order of the input values, rather than the order in which the operations happened to finish. A rejection causes the combined promise to reject. It does not automatically cancel every other underlying operation.

If the work has side effects, discuss how those effects are managed when another operation fails. A combined promise is a completion abstraction, not a distributed transaction.

Can microtasks delay later tasks?

Yes. Repeatedly adding more work to the microtask queue can delay progress to later tasks. That is a reason to avoid turning a scheduling explanation into a rule that promises are always better for responsiveness than other mechanisms.

Also separate scheduling from elapsed time. This example checks a relative order, not a benchmark. Browser load, background-tab policies and other work can affect when a timer actually runs.

A reliable output-tracing method

  1. Write down the current synchronous statements in order.
  2. Mark each handler that is registered for later execution.
  3. Follow the dependencies between promises.
  4. Separate the browser's tasks from promise-related microtasks.
  5. Check errors and unfinished operations as well as successful values.

For your next attempt, make the first then return a promise resolved by a timer. Predict the ordering again. Explain which dependency changed rather than assuming the original sequence survives every modification.

References and next practice

developer.mozilla.org — js promise · developer.mozilla.org — js execution

Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud