Problem
Build an in-memory index over home Listing records (id, city, price, beds). getById(id) returns the matching Listing in O(1), or null if absent. search(city, maxPrice) returns the ids of listings in that city priced at or below maxPrice, cheapest first, ties broken by id ascending. Re-adding the same id must update the existing record, not duplicate it.
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: model records and serve two access
patterns — a point lookup and a filtered, ranked query. Restate it first — "So
getById has to be O(1), and search is a city + price-ceiling filter sorted by
price then id, and adding a known id is an upsert?"
What this problem does not test (say so out loud): pagination, multi-field
filters (beds, geo radius), full-text matching, and a precomputed sorted index per
city are out of scope here — but a senior names that the linear scan in search is
the obvious scaling cost and that a per-city price-sorted structure is the next step.
Tests
- ○by_id
- ○by_id_missing
- ○search_filter
- ○search_rank
- + 2 hidden tests — revealed once the visible ones pass