MediumFrontend5 min read

Implement throttle(func, wait, {leading, trailing})

Q: Implement throttle(func, wait, {leading, trailing})

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the key distinguishing claim from debounce — that throttle keeps firing at a steady rate DURING continuous activity rather than waiting for it to stop — was verified directly with a real, sustained 260ms burst of calls every 20ms. ## 1. The problem, restated `throttle(fn, wait, options)` returns a wrapped function guaranteeing `fn` is invoked at most once per `wait` ms, even while being called continuously — unlike debounce, it does NOT wait for calls to stop. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Must the LAST call of a burst be captured? | The real, standard "trailing edge" behavior — otherwise a final, important call could be silently dropped. | | Fixed window from the first call? | Yes — this is the real, defining difference from debounce, which resets its window on every call. | | F

1.0k views

90 of 154

The problem

Problem, as an interviewer would state it: "Implement throttle(fn, wait, options) — guarantee fn runs at most once every wait ms, even under continuous, rapid calls, with configurable leading/trailing edges."

Examples:

Code

const t = throttle(onScroll, 100);
window.addEventListener("scroll", t);
// fires at most once per 100ms while scrolling continuously, not once per pixel

Clarifying questions expected:

Does the FINAL call of a continuous burst need to be captured (trailing edge), or is it acceptable to drop it?
Should the first call fire immediately (leading edge), or only after the first full window?
Is wait a fixed window from the FIRST call, or does it reset on every subsequent call (which would make this debounce, not throttle)?

Code / implementation expected: Yes — real, direct proof via a timed burst that both the leading and trailing edges fire correctly and calls are correctly rate-limited.

throttle
timers
leading-trailing

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 key distinguishing claim from debounce — that throttle keeps firing at a steady rate DURING continuous activity rather than waiting for it to stop — was verified directly with a real, sustained 260ms burst of calls every 20ms.

1. The problem, restated

throttle(fn, wait, options) returns a wrapped function guaranteeing fn is invoked at most once per wait ms, even while being called continuously — unlike debounce, it does NOT wait for calls to stop.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Must the LAST call of a burst be captured?	The real, standard "trailing edge" behavior — otherwise a final, important call could be silently dropped.
Fixed window from the first call?	Yes

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: throttle() correctly rate-limits a continuous burst while still capturing the leading and trailing edges

Practice

Discussion

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

No comments yet. Share how you would answer it.

Question 90 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→

Build an Undo/Redo Command Stack for a Text Editor

Continue