Design a Fast Product Search Page: Search Input over an Unbounded Catalog Grid

Design the front end of a product search page. A search input sits at the top, and below it a grid shows the product catalog. When the user types a search term, the grid should show the matching (filtered) products. The catalog has no upper bound on size, so a query can match an unlimited number of products. The interviewer wants two things: the structure of your component tree, and how you make sure results come back quickly after the user types a search term. In the reported interview this was a short discussion of about 10 minutes following a coding exercise, so lead with the decisions that matter most. ### Constraints and Clarifications - The catalog cannot be assumed to fit in the browser; the client can only ever hold a slice of the results. - What each card shows, how many cards fit in a row, and what the backend search API offers were not reported. Ask, or state your assumptions. ### Clarifying Questions - Should results update as the user types, or only when they submit the search? - Does a search API already exist? Does it support paging, sorting and a total count, or do we define its contract? - What does each product card show (for example image, name and price), and how many cards fit in a row? - Infinite scroll or numbered pages? Should the query live in the URL so results can be shared and survive the Back button? - Which devices and network conditions matter most? ### Part 1 — Component tree and state Lay out the components, what each one owns, and how the search term and the results flow between them. ```hint Decide who owns the query The input, the request logic and the grid all depend on the search term. Place that state where everything that needs it can reach it, and ask whether every keystroke should re-render the whole grid. ``` #### What This Part Should Cover - A component hierarchy with clear responsibilities: input, results container, grid, card and status views - Where the query, results, paging position and request status live, and how they flow - Loading, empty and error presentation that does not shift the layout - Keeping the query in sync with the URL ### Part 2 — Fast results for an unbounded catalog How do you make sure the grid shows the right results quickly after the user types, when the result set can be arbitrarily large? ```hint Not every keystroke needs a request Count how many requests a fast typist would trigger, and ask which of those responses the user actually needs to see, including what happens when they come back out of order. ``` ```hint Unbounded means never everything at once Think about how much of the result set a user can see at one time, both in what you fetch and in how many cards you put in the DOM. ``` #### Clarifying Questions for this Part - What does "fast" mean here: time until the first results appear, or time until the grid is complete and stable? - Can results for a query be cached, or does the catalog change too often for that? #### What This Part Should Cover - Controlling request volume and discarding stale responses - Caching and reusing results across repeated or refined queries - Paging through the result set and limiting rendering cost (DOM size, images) - What the backend must provide for fast search over a very large catalog ### What a Strong Answer Covers - Clarifies the typing behavior and the API contract before designing - A clean component tree with a single owner for search state - Correct results under fast typing: no stale results shown and no flicker - Concrete techniques on the client, network and server sides, each with its trade-off - How speed is measured for real users ### Follow-up Questions - The user types "lap", then quickly "laptop", and the response for "lap" arrives last. What does your grid show, and how do you guarantee it is correct? - A user scrolls deep into the results, opens a product, then presses Back. How do you restore where they were? - How would you measure whether search feels fast for real users? - If the catalog were only a few hundred products, what would you design differently?