The three states of a JavaScript Promise

WHAT THIS TESTS This checks foundational understanding of how Promises model asynchronous outcomes and their immutable lifecycle, which underpins all async/await reasoning.

A GOOD ANSWER COVERS A Promise begins in the pending state. It then settles exactly once into either fulfilled, carrying a result value, or rejected, carrying an error reason. Settling is permanent: a fulfilled or rejected Promise can never change state again, and a second call to resolve or reject is ignored. You create a Promise with the new Promise constructor, passing an executor function that receives resolve and reject; you call resolve with the value on success or reject with an error on failure. To consume the outcome you attach then with a callback for the fulfilled value and catch with a callback for the rejection reason. Both then and catch return new Promises, which is what enables chaining, and their callbacks always run asynchronously as microtasks, never synchronously inside the current call.

COMMON WRONG ANSWERS Claiming a Promise can revert to pending or settle multiple times, that then callbacks run synchronously, or that catch handles errors thrown anywhere rather than rejections propagated down the chain. Forgetting that finally runs regardless of outcome.

LIKELY FOLLOW-UPS How chaining propagates values and errors, how returning a Promise inside then flattens it, the relationship to async/await, and where the microtask queue fits.

ONE CONCRETE EXAMPLE Wrapping a callback-based timer: new Promise resolves after a delay by calling resolve inside setTimeout. Consumers attach then to react to the value and catch to handle any rejection. Even if the executor calls resolve immediately and synchronously, the attached then callback still runs later as a microtask, after the current synchronous code finishes, which is why a log placed after the then call prints before the then callback.