Promise Timeout

Q: Promise Timeout

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** both real outcomes — the fast-promise-wins case and the genuine-timeout case — were actually run, with real elapsed timing, not just described. ## 1. The problem, restated Wrap any promise so that it settles the same way the original would — UNLESS `ms` milliseconds pass first, in which case the wrapped version rejects with a timeout error instead, regardless of what the original eventually does. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Does the original promise's eventual result matter after a timeout? | For most real use cases (an abandoned fetch), the honest answer is "genuinely ignore it" — worth confirming. | | Should the timeout error be identifiable? | Lets calling code distinguish "too slow" from "the real operation itself failed" — a real, useful design choice. | | Is there an existi

The problem

Problem, as an interviewer would state it: "Write promiseTimeout(promise, ms) — it should resolve/reject with whatever promise does, UNLESS ms milliseconds pass first, in which case it should reject with a timeout error instead."

Examples:

Code

await promiseTimeout(fetch(url), 5000); // resolves normally if fast enough
await promiseTimeout(fetch(url), 5000); // rejects with a timeout error if too slow

Clarifying questions expected:

If the timeout fires, does the original (now-abandoned) promise's own eventual result matter at all, or should it just be ignored?
Should the timeout error be a specific, identifiable type/message, so callers can distinguish "timed out" from "the operation itself failed"?
Is there a real, existing building block in this bank that already solves "whichever settles first wins"?

Code / implementation expected: Yes — real, direct proof of both outcomes: a fast promise correctly beating a timeout, and a genuinely slower promise correctly triggering it.

async

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Easy

How to read this doc: both real outcomes — the fast-promise-wins case and the genuine-timeout case — were actually run, with real elapsed timing, not just described.

1. The problem, restated

Wrap any promise so that it settles the same way the original would — UNLESS ms milliseconds pass first, in which case the wrapped version rejects with a timeout error instead, regardless of what the original eventually does.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Does the original promise's eventual result matter after a timeout?	For most real use cases (an abandoned fetch), the honest answer is "genuinely ignore it" — worth confirming.
Should the timeout error be identifiable?	Lets calling code distinguish "too

The solution is hidden so you can try first

6 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: promiseTimeout() correctly lets a fast promise win, and correctly times out a genuinely slower one — verified directly