Home search: filter, sort, paginate

seniorjava · AI-on
  1. 1Restate the problem in one line
  2. 2Sketch the data model yourself
  3. 3Ask AI for a skeleton ONLY
  4. 4Ask AI for a test plan ONLY
  5. 5Implement the core logic yourself
  6. 6Run the tests — verify, don't trust
  7. 7Ask AI for edge cases you missed
  8. 8Ask AI to review your code
  9. 9Make the final judgment yourself

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.

iThe deal with the pair partner

The AI is deliberately fallible — it gives hints, not solutions, and sometimes proposes wrong code. It cannot touch your editor. Paste what you choose, then Run. Anything AI-derived stays UNVERIFIED until your tests go green.

Self-check

  • filter keeps only homes with minPrice <= price <= maxPrice (both bounds inclusive) and beds >= minBeds
  • sort honors price_asc vs price_desc, with a deterministic tie-break (id ascending) so equal prices have a stable order
  • pagination slices the SORTED, FILTERED list: page is 0-based, the slice is [page*size, page*size + size)
  • an out-of-range page (past the end) returns an empty list rather than throwing
  • you named the cost (this scans + sorts every call) and what you would add for scale (a pre-sorted or indexed structure, a stable cursor instead of offset pages)
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.

Solution.javaauto-runs ~0.8s after you pause
unverifiedEdited since last clean run — run to verify.

Tests

○ Not run yet — edit the code or press Run
  • filter_by_price_range
  • filter_by_beds
  • sort_price_desc
  • pagination_page_2
  • + 2 hidden tests — revealed once the visible ones pass

Pair partner (병신 모드 · 버그 잡기)

gpt-4o-mini

Ask for a skeleton or a test plan — not the answer. Then implement the core yourself and come back for edge cases. Remember: the partner is fallible. Verify everything by running it.

The partner sees your editor but cannot change it. Copy any suggestion in by hand, then Run to verify.

AI랑 먼저 페어하고 눌러