03 / 17

Explain the three states of a Promise.

Difficulty: 3/10
promise lifecycle, async handling, error propagation

pending, fulfilled and rejected are three states of a promise.

  1. 1

    Pending: The initial state, when the Promise is neither fulfilled nor rejected.

  2. 2

    Fulfilled: The state when the asynchronous operation completes successfully.

  3. 3

    Rejected: The state when the asynchronous operation encounters an error.

Scenario Questions

0-2 years experience

  1. 1If you call fetch('/api') and then chain .then(...).catch(...), what state is the promise in right after the fetch call returns?
  2. 2How would you use a promise to wait for two independent async operations to finish before proceeding?
  3. 3What happens if you return a value from a .then handler—what state does the new promise enter?

2-5 years experience

  1. 1You have a function that returns a promise, but sometimes it never resolves and the UI hangs. How would you debug which promise state is stuck?
  2. 2When integrating a third‑party library that sometimes rejects with an error object, how do you decide whether to handle the rejection inside the library call or propagate it? Explain the impact on promise states.
  3. 3Suppose you need to implement a timeout for a network request using Promise.race. How do the states of the original request promise affect the outcome?

5-8 years experience

  1. 1In a large microservice, you need to orchestrate many async calls that may succeed or fail. How would you design a wrapper around promises to ensure failures are captured without leaving dangling pending promises?
  2. 2Your team is refactoring a callback‑heavy codebase to use async/await. What edge cases around promise states must you watch for to avoid memory leaks or unhandled rejections at scale?
  3. 3Explain how you would instrument promise lifecycle events (pending, fulfilled, rejected) in production to monitor latency and error rates.

8+ years experience

  1. 1Your organization is moving from a legacy promise library to native ES6 promises across dozens of services. What architectural considerations and migration strategy would you propose to handle differing promise states and ensure backward compatibility?
  2. 2When designing a cross‑team event‑driven system that relies on promises for async processing, how do you reason about the global state of promises to avoid cascading failures and maintain observability?
  3. 3If you need to guarantee exactly‑once processing in a distributed pipeline that uses promises, how do you handle the transition between pending, fulfilled, and rejected states to enforce idempotency?

Follow-up Questions

  • Can you walk me through what happens internally when a promise moves from pending to fulfilled?
  • How would you test that a promise correctly rejects under error conditions?
  • What are the risks of forgetting to handle a rejected promise in production code?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.