Build a Search Bar with History | Interview Question

Q: Build a Search Bar with History

**Target Audience:** Frontend developers preparing for a machine coding round. Assumes basic React state and events; `localStorage` and focus management are explained from zero. **Difficulty:** Medium > **How to read this doc:** Every idea is explained in plain language first, then tagged with 📌 Interview term: so you also learn the exact words an interviewer listens for. The Verified output was produced by running the solution on React 19.3.1 in jsdom, with a driver that typed, pressed keys, fired storage events and moved focus. ## 1. Why This Even Matters — A Story First Think of the sticky notes on a pharmacist's counter: the five prescriptions people asked about most recently. When a regular comes back, the pharmacist glances at the notes instead of starting from scratch. Nobody writes the same name twice; a returning name just moves to the top note. When the notes run out, the oldest is thrown away. A search bar with history is those sticky notes. The interesting

The problem

Question presented to candidate: "Add recent searches to our article search. When someone submits a query, remember it. When they click into the box, show their last five searches; picking one runs it again. The list should survive a page reload, should not contain duplicates, and should be usable from the keyboard."

Requirements:

Submitting (Enter or the Search button) runs the search and records the term: trimmed, newest first, case-insensitive de-duplication (a repeat moves to the top), capped at 5.
Persist the list in localStorage; survive corrupt or missing data and storage that throws.
Clicking the input opens a "Recent searches" dropdown, filtered by what is typed; each row re-runs its search and has a remove (×) button; there is a "Clear all".
Keyboard: Down arrow moves into the list, Up / Down move between rows, Delete removes the focused row, Escape closes and returns to the input.
Close on a press outside or when focus leaves the widget; follow changes made in another tab.

What a strong answer should cover:

Pure helper functions (addToHistory, parseHistory) separate from the UI, so dedupe and cap logic are testable on their own.
Defensive localStorage access: try/catch around reads and writes, validating the parsed JSON shape.
One commit() path that updates state and storage together, instead of an effect that writes storage on every render.
Focus management: where focus goes after a row is removed, and why real focus moving between buttons is used here instead of aria-activedescendant.
Outside-press and focus-leave closing, and the storage event for cross-tab sync.

Clarifying questions expected:

"Is history per device (localStorage) or per account (server)? Should it sync across tabs?"
"How many entries, and should 'React' and 'react' count as the same search?"
"Should the dropdown open on focus, on click, or only when the user presses Down?"

Code / implementation expected: Yes. A working component with persisted, de-duplicated, capped history and keyboard support.

React
Search
Storage

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: Frontend developers preparing for a machine coding round. Assumes basic React state and events; localStorage and focus management are explained from zero. Difficulty: Medium

How to read this doc: Every idea is explained in plain language first, then tagged with 📌 Interview term: so you also learn the exact words an interviewer listens for. The Verified output was produced by running the solution on React 19.3.1 in jsdom, with a driver that typed, pressed keys, fired storage events and moved focus.

1. Why This Even Matters — A Story First

Think of the sticky notes on a pharmacist's counter: the five prescriptions people asked about most recently. When a regular comes back, the pharmacist glances at the notes instead of starting from scratch. Nobody writes the same name twice; a returning name just moves to the top note. When the notes run out, the o

The solution is hidden so you can try first

11 min read · 9 sections

React solution

Every file of the working solution. Open it in the playground to run and change it.

ReactComplete solution

Open in playground

import HistorySearch from "./src/components/HistorySearch";

export default function App() {
  return (
    <main className="page">
      <h1>Article search</h1>
      <HistorySearch />
    </main>
  );
}

Discussion

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

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.