Question 1

What is a Promise in JavaScript?

Accepted Answer

A Promise is an object representing the eventual fulfillment or rejection of an asynchronous operation, with states pending, fulfilled, or rejected. Promises provide a standard composable abstraction for async results. Once settled, a promise's state is immutable. Consumers attach .then, .catch, and .finally handlers, which themselves return promises enabling chaining. Creating with new Promise((resolve, reject) => ...) should not do heavy sync work beyond starting async ops. Prefer returning promises from APIs over mixed callback styles. Promises integrate with async/await and the microtask queue.

Question 2

How does promise chaining work, and what happens if a .then handler returns a value vs a promise?

Accepted Answer

Each .then returns a new promise; returned values fulfill it, thrown errors reject it, and returned promises adopt that promise's state. Chaining avoids nesting by passing results along. If you return a plain value, the next .then receives it. If you return a thenable/promise, the chain waits for it (assimilation). If you omit a return, the next handler gets undefined. Throwing or returning Promise.reject rejects the downstream chain until a .catch. Always return/throw intentionally inside handlers to keep control flow clear.

Question 3

How should errors be handled with Promises vs async/await?

Accepted Answer

Use .catch / trailing rejection handlers on chains; use try/catch around await. Always ensure rejections are handled to avoid unhandledrejection. Rejected promises propagate down the chain until caught. Mixing styles is fine: await turns rejections into exceptions. try/catch does not catch errors inside a floating promise without await. .finally runs on settle for cleanup but does not absorb errors unless it throws/rejects. In browsers/Node, unhandled rejections emit events and may crash Node depending on version/settings. Prefer catching at meaningful boundaries and rethrowing with context.

Question 4

Compare Promise.all, Promise.allSettled, Promise.race, and Promise.any.

Accepted Answer

all fulfills when all fulfill (fails fast); allSettled waits for all outcomes; race settles with the first settle; any fulfills with first fulfill (AggregateError if all reject). Use all for dependent parallel success. Use allSettled when you need every result including failures (dashboards). Use race for timeouts (race([fetch, timeoutPromise])) or first-done wins. Use any when any success is enough among mirrors. Know that all/race short-circuit differently. For large sets, consider concurrency limits instead of unbounded all.

Question 5

What is a thenable, and how would you safely promisify a callback API?

Accepted Answer

A thenable is any object with a .then method; Promise resolution assimilates thenables. Promisify with new Promise and forward err/result exactly once. The Promises/A+ assimilation rule means returning/resolving a thenable links states — useful and sometimes surprising if a non-promise object accidentally has then. To promisify: new Promise((resolve, reject) => api(arg, (err, data) => err ? reject(err) : resolve(data))). Guard against double callbacks. Prefer Node util.promisify when available. Do not wrap an existing promise in another unnecessary new Promise (promise constructor anti-pattern).

Question 6

Implement or design a promise pool that runs at most N async tasks at a time.

Accepted Answer

Keep a queue of task factories, start up to N, and start the next when one finishes; return results in input order if required. APIs often need bounded concurrency for rate limits and memory. Pattern: map items to async functions, maintain active count, dequeue when slots free. Preserve order with result index array. Decide error policy: fail fast (cancel remaining) vs collect errors. Use AbortSignal for cancellation. Libraries exist (p-limit, p-map), but interviews may ask for a sketch. Discuss fairness and starvation under mixed task durations.

Question 7

You lead multiple teams shipping JS SDKs. What standards would you set for Promise-based APIs?

Accepted Answer

Always return promises (no mixed callback-required APIs), never throw sync after starting async, document rejection types, support AbortSignal, and avoid deferred anti-patterns. Conventions: functions return Promise; use async/await internally; reject with Error subclasses (typed codes); do not sometimes return values and sometimes promises; support cancellation via signal; provide timeouts as options; no floating promises in examples; expose using/disposables where resources need cleanup. Ban promise constructor anti-pattern in reviews. Provide dual error strategies carefully (Result vs throw) but pick one per layer. Versioning: changing rejection shapes is a breaking change. Add lint rules for floating promises in TS (no-floating-promises). Align logging of unhandledrejections in apps consuming the SDK.

Promises JavaScript Interview Questions

Other JavaScript interview topics