Debug a Frontend Component That Shows Wrong API Results

Quick Overview

A front-end debugging question in which a React component that fetches data sometimes shows results that do not match the current input, even though each API response is correct. It tests how the candidate reproduces a timing-dependent bug, finds the root cause, fixes it in the effect, handles cancellation errors, and verifies the fix with a deterministic test.

Debug a Frontend Component That Shows Wrong API Results

Company: Tradedesk

Role: Frontend Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Onsite

A front-end component sends an API request whenever its input changes and displays the response. Users report that the results on screen are sometimes wrong: they do not match what is currently typed. Yet when each request is checked on its own, the API returns the correct data for that request. Find out why the component shows wrong results, fix it, and explain how you would confirm the fix. The interview's actual code was not reported. The React component below is a representative reconstruction to debug. ```tsx import { useEffect, useState } from "react"; type Result = { id: string; name: string }; export function SearchResults() { const [query, setQuery] = useState(""); const [results, setResults] = useState<Result[]>([]); const [error, setError] = useState<string | null>(null); useEffect(() => { if (!query) { setResults([]); return; } fetch(`/api/search?q=${encodeURIComponent(query)}`) .then(res => res.json()) .then(data => setResults(data.results)) .catch(() => setError("Search failed")); }, [query]); return ( <div> <input value={query} onChange={e => setQuery(e.target.value)} /> {error && <p>{error}</p>} <ul> {results.map(r => ( <li key={r.id}>{r.name}</li> ))} </ul> </div> ); } ``` ```hint Compare send order with arrival order Use the network panel with throttling while typing quickly, and compare the order in which requests are sent with the order in which their responses update the state. ``` ### Constraints and Clarifications - The endpoint is correct for every individual request; the problem is in the client. - When typing stops, the screen must end up showing the results for the final input, and it must never switch to results for an earlier input. Keeping the previous results visible while new ones load is acceptable. - The fix should use standard browser APIs and must not add unnecessary network traffic. ### Clarifying Questions - Can the backend be changed, for example to return the query it answered? - Is it acceptable to wait until typing pauses before searching, or must results follow each keystroke? - Should the user ever see an error for a request whose results are no longer needed? ### What a Strong Answer Covers - A reliable way to reproduce the bug and confirm the diagnosis before changing any code. - The root cause, explained in terms of this component's code and the timing of its state updates. - A fix placed at the right point in the component's lifecycle, including any new error paths the fix itself introduces. - Other defects in the same code that affect what the user sees. - Alternative fixes and their trade-offs, plus a deterministic automated test for the fix. ### Follow-up Questions 1. Would waiting for a pause in typing before searching fix the problem on its own? Why or why not? 2. How would you write an automated test that reproduces this bug deterministically, without relying on real network timing? 3. Does your fix reduce the work the server does, or does it only change what the client displays? 4. How would the same fix look outside React, for example in a plain class that wraps a search input?

Overview: A front-end debugging question in which a React component that fetches data sometimes shows results that do not match the current input, even though each API response is correct. It tests how the candidate reproduces a timing-dependent bug, finds the root cause, fixes it in the effect, handles cancellation errors, and verifies the fix with a deterministic test.

|Home/Software Engineering Fundamentals/Tradedesk
Tradedesk logo
Tradedesk
Sep 15, 2026
mediumFrontend EngineerOnsiteSoftware Engineering Fundamentals
0
0

A front-end component sends an API request whenever its input changes and displays the response. Users report that the results on screen are sometimes wrong: they do not match what is currently typed. Yet when each request is checked on its own, the API returns the correct data for that request. Find out why the component shows wrong results, fix it, and explain how you would confirm the fix.

The interview's actual code was not reported. The React component below is a representative reconstruction to debug.

import { useEffect, useState } from "react";

type Result = { id: string; name: string };

export function SearchResults() {
  const [query, setQuery] = useState("");
  const [results, setResults] = useState<Result[]>([]);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    if (!query) {
      setResults([]);
      return;
    }
    fetch(`/api/search?q=${encodeURIComponent(query)}`)
      .then(res => res.json())
      .then(data => setResults(data.results))
      .catch(() => setError("Search failed"));
  }, [query]);

  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      {error && <p>{error}</p>}
      <ul>
        {results.map(r => (
          <li key={r.id}>{r.name}</li>
        ))}
      </ul>
    </div>
  );
}

Constraints and Clarifications

  • The endpoint is correct for every individual request; the problem is in the client.
  • When typing stops, the screen must end up showing the results for the final input, and it must never switch to results for an earlier input. Keeping the previous results visible while new ones load is acceptable.
  • The fix should use standard browser APIs and must not add unnecessary network traffic.

Clarifying Questions Guidance

  • Can the backend be changed, for example to return the query it answered?
  • Is it acceptable to wait until typing pauses before searching, or must results follow each keystroke?
  • Should the user ever see an error for a request whose results are no longer needed?

What a Strong Answer Covers Guidance

  • A reliable way to reproduce the bug and confirm the diagnosis before changing any code.
  • The root cause, explained in terms of this component's code and the timing of its state updates.
  • A fix placed at the right point in the component's lifecycle, including any new error paths the fix itself introduces.
  • Other defects in the same code that affect what the user sees.
  • Alternative fixes and their trade-offs, plus a deterministic automated test for the fix.

Follow-up Questions Guidance

  1. Would waiting for a pause in typing before searching fix the problem on its own? Why or why not?
  2. How would you write an automated test that reproduces this bug deterministically, without relying on real network timing?
  3. Does your fix reduce the work the server does, or does it only change what the client displays?
  4. How would the same fix look outside React, for example in a plain class that wraps a search input?
Loading comments...