MediumFrontendAsked in 20247 min read

Build a Drift-Corrected Interval Clock (setInterval Alone Drifts Over Time)

Q: Build a Drift-Corrected Interval Clock (setInterval Alone Drifts Over Time)

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the specific numbers below — 165ms of accumulated drift for naive `setInterval` versus 19ms for the corrected version, over the SAME 15 ticks with an identical simulated 10ms-blocking handler each time — are real, measured results, not estimates. ## 1. The problem, restated `setInterval(fn, wait)` schedules each NEXT firing `wait` ms after the CURRENT one actually fires — not after some fixed, absolute schedule. If `fn` itself takes any non-trivial time to run (or the event loop is busy with other work), that delay pushes every SUBSEQUENT tick later too, and the delays genuinely accumulate over a long-running session rather than staying constant. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Event-loop-busy drift, or handler-execution drift? | Genuinely both contribute the same way — anything th

1.1k views

85 of 154

The problem

Problem, as an interviewer would state it: "setInterval(fn, 1000) is not actually guaranteed to fire exactly every 1000ms — explain why, and implement a version that stays accurate over a long-running session."

Examples:

Code

const clock = createDriftCorrectedInterval(tick, 1000);
// stays close to real wall-clock 1000ms boundaries even if tick() itself
// occasionally takes 20-30ms to run, unlike plain setInterval

Clarifying questions expected:

Is the drift caused by the EVENT LOOP being busy, or specifically by the handler's OWN execution time?
Does "accurate" mean each individual gap is exactly wait, or that the TOTAL elapsed time after N ticks matches N × wait?
Is pausing/resuming (e.g., a background browser tab) in scope, or just steady-state drift?

Code / implementation expected: Yes — real, direct, measured proof comparing accumulated drift between a naive setInterval and a corrected version under identical conditions.

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 specific numbers below — 165ms of accumulated drift for naive setInterval versus 19ms for the corrected version, over the SAME 15 ticks with an identical simulated 10ms-blocking handler each time — are real, measured results, not estimates.

1. The problem, restated

setInterval(fn, wait) schedules each NEXT firing wait ms after the CURRENT one actually fires — not after some fixed, absolute schedule. If fn itself takes any non-trivial time to run (or the event loop is busy with other work), that delay pushes every SUBSEQUENT tick later too, and the delays genuinely accumulate over a long-running session rather than staying constant.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Event

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, measured proof: a drift-corrected interval accumulates far less lag than plain setInterval under an identical slow handler, over 15 real ticks

Practice

Discussion

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

No comments yet. Share how you would answer it.

Question 85 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 nextMedium→

Implement Array.prototype.includes() Handling NaN Correctly

Continue