Choose the right tool
Wrong choice is a common interview fail. Match the utility to the event pattern and UX expectation.
- Debounce when you want “after typing stops”
- Throttle when you want “steady updates”
- Cancel in-flight work when inputs change
Debounce vs throttle
Debounce vs throttle interview questions
Debounce waits until calls stop for a set delay; throttle allows at most one call per interval while events continue. Frontend interviews test whether you can explain that difference, implement both utilities, and choose the right one for a real UI.
For the common HackerRank-style frontend interview prompt, state the timing contract first, preserve this and arguments, then implement leading and trailing behavior only after the base version works.
After the utility works, practice applying it inside a React machine coding challenge so you can talk about product usage, not only timer mechanics.
Implementation checklist
Closures hold timer state. Be explicit about whether the first call fires immediately and how trailing calls behave.
- clearTimeout / clearInterval hygiene
- Leading and trailing edges
- this and argument forwarding
HackerRank-style follow-ups
After the base utility works, interviewers commonly change the timing contract or ask you to apply it inside a product interaction.
- Leading and trailing options
- cancel() and flush() APIs
- Autocomplete, infinite scroll, and resize handling
Debounce, throttle, and related utilities
ThrottleCore throttle implementation (free).Debounce IIDebounce with interview-level constraints.Throttle leading & trailingEdge-behavior follow-up variant.Memoize ICaching utility often asked nearby.Currying sumClosure fluency companion question.Flatten ArrayCommon JS coding warm-up.Auto-complete (UI)Apply debounce inside a React UI round.Infinite Scroll (UI)Apply throttle/scroll handling in UI.JS polyfill questionsAdjacent language-depth practice.JavaScript interview hubBroader JS interview coverage.
Recommended next pages
FAQ
What is the difference between debounce and throttle?
Debounce waits until events stop for N milliseconds before running (great for search input). Throttle runs at most once per N milliseconds while events continue (great for scroll and resize).
Why do frontend interviews ask debounce/throttle?
They test closures, timers, leading/trailing edge behavior, and whether you can choose the right rate-limiting tool for a UI problem.
Where are these used in real products?
Debounce: typeahead search, form autosave. Throttle: scroll listeners, window resize, mousemove tracking, infinite-scroll checks.
What follow-ups should I expect?
Implement leading vs trailing edges, cancel/flush APIs, and explain how you would use them inside an autocomplete or infinite-scroll component.