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.