WebSocket reconnect logic

Q: WebSocket reconnect logic

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the exponential-doubling claim was verified directly with real, measured timing against a mock socket engineered to fail exactly 3 times before succeeding — not just asserted from the backoff formula. ## 1. The problem, restated Wrap a real WebSocket factory so that on an unexpected `close` event, the wrapper automatically attempts to reconnect, waiting an exponentially GROWING delay between each successive attempt (capped at some maximum), and RESETTING that backoff back to the base delay the moment a connection genuinely succeeds again. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Reset backoff after a success? | Yes, genuinely — otherwise a single bad stretch of connectivity would permanently slow down ALL future reconnect attempts for the rest of the session. | | Maximum delay cap? | Yes, a

The problem

Problem, as an interviewer would state it: "Implement an auto-reconnecting WebSocket wrapper: when the connection closes unexpectedly, retry with exponential backoff, resetting the backoff once a connection genuinely succeeds."

Examples:

Code

const socket = createReconnectingSocket(() => new WebSocket(url));
// on a real disconnect, retries after 1s, 2s, 4s, 8s... up to a max delay

Clarifying questions expected:

Should the backoff RESET to the base delay after a real successful reconnection, or keep growing indefinitely across the whole session?
Is there a maximum delay cap, or does the backoff grow unbounded?
Should a real, deliberate .close() call by the application itself trigger a reconnect attempt, or only an unexpected disconnect?

Code / implementation expected: Yes — real, direct proof against a mock socket that genuinely fails a fixed number of times before succeeding, confirming the real, measured backoff delays correctly double and the connection eventually recovers.

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: Medium

How to read this doc: the exponential-doubling claim was verified directly with real, measured timing against a mock socket engineered to fail exactly 3 times before succeeding — not just asserted from the backoff formula.

1. The problem, restated

Wrap a real WebSocket factory so that on an unexpected close event, the wrapper automatically attempts to reconnect, waiting an exponentially GROWING delay between each successive attempt (capped at some maximum), and RESETTING that backoff back to the base delay the moment a connection genuinely succeeds again.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Reset backoff after a success?	Yes, genuinely — otherwise a single bad stretch of connectivity would permanently

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: reconnect delays genuinely double across real failures, and the connection eventually succeeds after a mock socket stops failing