HardFrontendAsked in 20247 min read

Throttled API poll client

Q: Throttled API poll client

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Hard > **How to read this doc:** the entire real point of this question — that a slow real fetch must not allow OVERLAPPING requests to fire on subsequent poll ticks — was verified directly: with a deliberately slow first fetch spanning multiple poll intervals, 2 real ticks were explicitly logged as SKIPPED rather than triggering redundant concurrent requests. ## 1. The problem, restated `setInterval`-based polling naively fires on a fixed schedule REGARDLESS of whether the previous fetch has actually finished — if a real fetch genuinely takes longer than the poll interval (a real, common occurrence under server load or network trouble), this can cause multiple overlapping requests to be in flight simultaneously. A correct poller must GUARD against this, skipping a tick rather than starting a redundant, overlapping request. ## 2. Clarifying questions a strong candidate asks | Quest

2.3k views

137 of 154

The problem

Problem, as an interviewer would state it: "Build a client that polls a real endpoint at a fixed interval — WITHOUT letting requests overlap if a previous one is still in flight when the next tick occurs."

Examples:

Code

const poller = createPoller({ intervalMs: 5000, fetchFn, onData });
poller.start(); // polls every 5s, but skips a tick if the previous fetch is still running

Clarifying questions expected:

If a fetch takes LONGER than the poll interval, should the next tick be skipped entirely, or queued to run immediately once the current one finishes?
Should the very first poll fire immediately on start(), or only after waiting one full interval?
What happens to data received out of order, if two requests somehow DID overlap?

Code / implementation expected: Yes — real, direct proof with a deliberately slow first fetch spanning multiple poll intervals, confirming ticks are correctly SKIPPED rather than firing overlapping requests.

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

How to read this doc: the entire real point of this question — that a slow real fetch must not allow OVERLAPPING requests to fire on subsequent poll ticks — was verified directly: with a deliberately slow first fetch spanning multiple poll intervals, 2 real ticks were explicitly logged as SKIPPED rather than triggering redundant concurrent requests.

1. The problem, restated

setInterval-based polling naively fires on a fixed schedule REGARDLESS of whether the previous fetch has actually finished — if a real fetch genuinely takes longer than the poll interval (a real, common occurrence under server load or network trouble), this can cause multiple overlapping requests to be in flight simultaneously. A correct poller must GUARD against this, skipping a tick rather than sta

The solution is hidden so you can try first

7 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: a deliberately slow first fetch causes 2 real polling ticks to be correctly skipped, rather than overlapping requests firing

Practice

Discussion

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

No comments yet. Share how you would answer it.

Question 137 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 nextHard→

JSON.parse Polyfill

Continue