Design Product Catalog & Search

Search is the front door, and that framing changes what the interviewer is really testing. A shopper almost never browses a catalog of this size; they arrive with an intent, type a few words, and judge the entire store on whether the first page reads their mind. So the job is not to fetch rows that contain a word. It is to take a fuzzy, human query against hundreds of millions of products and put the small handful the shopper wants at the top, fast enough that it feels instant. Retrieval finds the candidates. Ranking decides which of them the shopper sees first. Get either wrong and the best assortment in retail is invisible. Nobody scrolls to page nine.

How hard the round pushes tracks the level. Below senior it often folds into a low-level design or a coding screen, a catalog service with a few endpoints. From senior up it becomes a genuine architecture conversation, usually run by a principal or staff engineer who works as a fellow designer rather than an examiner, and it grows under you. First it is keyword search over a modest catalog. Then it is hundreds of millions of documents and a hundred thousand queries a second. Then the interviewer asks why the item a shopper obviously wants, in stock and popular, is sitting below a perfect keyword match that sold out this morning. The push lands on the parts a retailer feels: relevance, freshness, and the awkward truth that a great match nobody can buy is a bad result.

The Walmart angle

Search is the single highest-traffic surface Walmart runs, so the bar is a retrieval-and-ranking system, not a database with a WHERE clause. The catalog spans first-party goods and a marketplace long tail into the hundreds of millions of listings. It fronts a base of hundreds of millions of weekly shoppers, most of whom start a session by searching. An interviewer here has almost certainly worked on a piece of the real thing, which runs on an inverted-index engine with a semantic-retrieval layer stacked on top.