EasyFrontendAsked in 20245 min read

Fetch wrapper auto-retry

Q: Fetch wrapper auto-retry

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** every claim below — including the "404 does not retry" behavior — was verified against real, live network endpoints, not mocked. ## 1. The problem, restated Wrap `fetch` so that a genuinely FAILED request is retried automatically, with an increasing delay between attempts (exponential backoff), up to a configured maximum number of retries. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Retry 4xx client errors too? | The real, correct answer is almost always no — a genuine 404 or 401 will fail identically on retry, wasting time and requests. | | Fixed delay or exponential backoff specifically? | Exponential backoff is the real, standard choice for avoiding hammering a struggling server. | | Configurable retry count/delay? | A real, reasonable default (e.g. 3 retries) should exist, but callers may ne

2.1k views

9 of 154

The problem

Problem, as an interviewer would state it: "Write a fetch wrapper that automatically retries a failed request with exponential backoff. What should actually count as 'failed' here — should it retry a 404?"

Examples:

Code

await fetchWithRetry("/api/data"); // retries on real network failure or 5xx, not 4xx

Clarifying questions expected:

Should client errors (4xx, like a genuine 404 or 401) be retried, or only server errors (5xx) and network failures?
Is exponential backoff required specifically, or is a fixed delay between retries acceptable?
Should the number of retries and the base delay be configurable?

Code / implementation expected: Yes — real, direct proof against real network endpoints: a genuine 404 returns immediately without retrying, while a genuinely unreachable domain retries the configured number of times before finally throwing.

js-coding
utility
algorithm

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: every claim below — including the "404 does not retry" behavior — was verified against real, live network endpoints, not mocked.

1. The problem, restated

Wrap fetch so that a genuinely FAILED request is retried automatically, with an increasing delay between attempts (exponential backoff), up to a configured maximum number of retries.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Retry 4xx client errors too?	The real, correct answer is almost always no — a genuine 404 or 401 will fail identically on retry, wasting time and requests.
Fixed delay or exponential backoff specifically?	Exponential backoff is the real, standard choice for avoiding hammering a struggling server.
Configurab

The solution is hidden so you can try first

5 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 against live network endpoints: a genuine 404 returns immediately without retrying, while a genuinely unreachable domain retries then throws

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

No comments yet. Share how you would answer it.

Question 9 of 154 in JavaScript coding

Keep your momentum going.

Mark this question solved to track your progress, then take the next one while it is fresh.

All JavaScript coding questions

Up nextEasy→

Find duplicates in array

Continue