Problem
Build a HomeSearch over Home records (id, price, beds). search(minPrice, maxPrice, minBeds, sort, page, size) returns one page of matching homes. Filter to homes whose price is within [minPrice, maxPrice] inclusive and whose beds are at least minBeds; sort by price ascending ("price_asc") or descending ("price_desc"); then paginate with a 0-based page index and a page size. Order the filter -> sort -> paginate so the page is a slice of the fully sorted result, not of the raw list.
Restate the problem in one sentence and list the edge cases — before writing any code.
Then keep talking — restate the problem + the edge cases in your own words.
“Let me make sure I understand the problem, then I'll walk through my approach.”
checking microphone…
Self-check
Hints / what this doesn't test
This is an Opendoor-flavored applied problem: the bread-and-butter "search results page" — filter a catalog, order it, hand back one page. Restate the contract before you touch code — "So the price range is inclusive on both ends, beds is a floor not an exact match, and the page is a slice of the sorted, filtered list — I sort the whole match set first, then cut the page out of it?" That ordering is the whole problem; paginating before sorting is the classic wrong answer.
What this problem does not test (say so out loud): multi-field sort keys (price then beds), full-text or geo filters, an upsert/dedup path, and a stable cursor (keyset) for pagination are all out of scope here — but a senior names that offset-based paging re-scans and re-sorts the whole catalog every call, that results can shift under the user if the catalog mutates between pages, and that a pre-sorted per-key index or a cursor is the real scaling move.
Tests
- ○filter_by_price_range
- ○filter_by_beds
- ○sort_price_desc
- ○pagination_page_2
- + 2 hidden tests — revealed once the visible ones pass