Interview answer drill

Use this JavaScript interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice interview questions Follow JavaScript mastery study plan Practice more JavaScript interview questions

Debounce vs Throttle in JavaScript: Which One Should You Use for Search Inputs?Frontend interview answer

HighIntermediateJavascript

By FrontendAtlas Team · Updated Jan 30, 2026

Interview focus

This JavaScript interview question tests whether you can explain Debounce vs throttle for search input: what is the difference, connect it to production trade-offs, and handle common follow-up questions.

Debounce vs throttle for search input: what is the difference explanation without falling back to memorized docs wording
Debounce and Throttle reasoning, edge cases, and production failure modes
How you would answer the most likely JavaScript interview follow-up

Practice more JavaScript interview questions

Interview quick answer

Debounce and throttle are two core JavaScript performance optimization techniques for controlling how often a function runs in response to frequent events like typing, scrolling, or resizing. A very common frontend interview question is designing a live search input: should you debounce or throttle the API call, and is 200ms a good debounce value?

Full interview answer

The real interview problem

This question is not about definitions. It's about this:

"How do you prevent expensive work from running too often when the user types?"

Typing in a search input can easily trigger 10–20 events per second. Calling an API on each keystroke is wasteful, slow, and can even get you rate-limited.

Debounce vs Throttle — the mental model

Technique	Mental model	What it does
Debounce	"Wait until the user stops typing"	Runs the function only after no events happened for N ms
Throttle	"Run at most once every N ms"	Runs the function at a fixed maximum rate

Both reduce frequency, but they solve different UX problems.

Which one should you use for search?

Almost always: Debounce.

Why?

You only care about the final query

Intermediate keystrokes produce useless requests

Debounce waits until the user pauses, then sends one clean request

Is 200ms a good debounce value?

Usually yes — as a starting point.

Common range: 150–300ms

200ms often feels instant to humans

But still cuts request volume massively

Trade-off:

Too small → still spams API

Too big → UI feels laggy

Senior answer: "We should measure and tune this based on UX and backend cost."

Simple debounce implementation

JAVASCRIPT

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

const onSearch = debounce((query) => {
  fetch(`/api/search?q=${query}`);
}, 200);

The real-world bug: race conditions

Even with debounce, this can happen:

1) User searches "rea"
2) Then quickly searches "react"
3) The "rea" request returns after the "react" request
4) UI shows wrong results

Solution:

Cancel in-flight requests (AbortController)

Or track request IDs and ignore stale responses

When should you use throttle instead?

Throttle is better for continuous signals:

Scroll handlers

Resize events

Mouse move / drag

Analytics sampling

In those cases you want regular updates, not just the final value.

Common mistakes

Using throttle for search → sends half-baked queries

Debouncing too aggressively → UI feels broken

Not cancelling previous requests

Letting stale responses overwrite fresh ones

One-sentence interview answer

"For search inputs I would use debounce, not throttle, because I only care about the final query — and ~200ms is a good starting point that should be tuned based on UX and backend cost, plus I’d handle request cancellation to avoid race conditions."