JavaScript Promises & Async Interview Questions

What is a Promise and what are its states?

A promise is an object that stands in for a value you do not have yet. It begins pending, and moves exactly once to either fulfilled with a value or rejected with a reason. That transition is irreversible — a settled promise can never change state or value again, which is what makes promises safe to pass around and attach handlers to at any time, even after they have already resolved.

The three handlers are `.then` for the fulfilled value, `.catch` for a rejection, and `.finally` for cleanup that must run either way. Each returns a new promise, which is why they chain — and why a value returned from inside a `.then` becomes the input of the next one.

How does async/await relate to promises?

It is syntax over the same mechanism, not a replacement. An `async` function always returns a promise, even if you return a plain value — that value gets wrapped. `await` pauses the function until the promise it is given settles, then either produces the value or throws the rejection reason. Nothing is blocked: the function suspends and the thread goes back to doing other work.

Why do promise callbacks run before setTimeout?

This is the question that separates people who use promises from people who understand them. The event loop keeps two queues. Promise callbacks go into the microtask queue; `setTimeout`, `setInterval` and I/O callbacks go into the macrotask queue. After the current synchronous code finishes, the engine drains the entire microtask queue before it touches a single macrotask — and it does so again after every macrotask.

The practical consequence is that a runaway chain of microtasks can starve the macrotask queue entirely — including rendering, which happens between macrotasks. A recursive `Promise.resolve().then(loop)` will freeze the tab, while the same loop written with `setTimeout` will not. That is a good follow-up to have ready.

Promise.all vs allSettled vs race vs any

All four take an iterable of promises and return one promise, and the difference is entirely in when they settle. `Promise.all` is the default choice when you need everything to succeed — it fails fast, rejecting the moment any input rejects, and discards the results that did arrive. `Promise.allSettled` never rejects; it waits for every promise and gives you an array of status objects, which is what you want when the tasks are independent.

A detail worth knowing: none of these cancel anything. `Promise.all` rejecting does not stop the other requests — they keep running and their results are simply thrown away. Promises have no cancellation built in, which is why the abort question below comes up next so often.

How do you run async work in parallel instead of one at a time?

This is the single most common real-world async bug, and it is easy to spot once you know the shape. Awaiting inside a loop, or awaiting each call on its own line, makes independent requests run one after another. The total time becomes the sum instead of the maximum.

How do you handle errors in async code?

With `await`, a rejected promise throws, so ordinary `try/catch` works and reads naturally. With chains, `.catch` handles anything rejected earlier in the chain. The rule that catches people out is placement: a `.catch` only sees rejections from links above it, so a handler attached before the failing step will never fire.

That `fetch` behaviour is worth memorising because it is asked directly: fetch only rejects on a network-level failure — DNS, offline, CORS. Any HTTP response, including 404 and 500, is a successful fetch as far as the promise is concerned. Axios differs here, which is one of the reasons teams reach for it.

What is an unhandled promise rejection?

A promise that rejects with no rejection handler attached. In browsers it fires an `unhandledrejection` event on `window` and logs an error; in Node it terminates the process by default from version 15 onward. The subtle version is a promise you created, never awaited and never caught — the work still runs, the failure still happens, and nothing in your code hears about it.

How do you add a timeout or cancel a request?

Promises cannot be cancelled — once started, the work runs to completion. What you can do is stop caring about the result, or ask the underlying operation to abort. `Promise.race` handles the first; `AbortController` handles the second and is the correct answer for anything network-based.

There is one more cancellation pattern worth having ready, because it comes up whenever React is in the conversation. When a component unmounts while a request is still in flight, the response arrives for a component that no longer exists. AbortController in the effect's cleanup is the clean fix; a boolean flag that the cleanup flips, checked before calling setState, is the older approach and still works. Either answer is fine as long as you name the problem — a state update on an unmounted component, and a request nobody will ever read.

What is promise chaining, and what does a .then return?

Every `.then` returns a new promise resolved with whatever its callback returned. Return a plain value and the next `.then` receives it; return a promise and the chain waits for it to settle before continuing — this flattening is what keeps chains from nesting. Return nothing and the next link receives `undefined`, which is the source of a lot of confused debugging.

Chaining is also where the difference between returning and throwing matters. Throwing inside a `.then` callback rejects the promise that callback returned, which sends control to the next `.catch` down the chain — exactly as if the original operation had failed. That is what lets you validate a response mid-chain and have the failure land in one place, rather than checking a status flag at every step.

What is a microtask, and how does it differ from a macrotask?

A microtask is work queued to run at the end of the current operation, before the engine yields. Promise callbacks, `queueMicrotask` and `MutationObserver` callbacks are microtasks. Macrotasks are whole units of work scheduled by the environment: timers, I/O, UI events. The loop is: run one macrotask, drain every microtask, render if needed, repeat.

Knowing the two queues also explains a rendering behaviour people find mysterious. The browser can only paint between macrotasks, after the microtask queue is empty. So a long synchronous loop freezes the page, and so does an unbounded chain of microtasks — but work split across `setTimeout` calls lets frames through, because each timer callback is a separate macrotask with a render opportunity after it. That is the reasoning behind chunking expensive work, and it is the same reasoning behind React's scheduler yielding to the browser.

If you get one follow-up on this topic it will usually be an output-ordering puzzle: some mix of synchronous logs, a `setTimeout`, an `async` function called but not awaited, and a `.then`. Work it in the same order every time — everything synchronous first, including the body of an async function up to its first `await`, then the whole microtask queue, then one macrotask. Saying that procedure aloud while you solve it is worth more than getting the answer quickly and silently.