How would you design pagination for a large collection?
Interviewer Expectations for this Question
01
Core Competency
Assesses fundamental understanding of REST API Design conventions, runtime behavior, and memory/performance considerations.
02
Evaluation Criteria
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Comprehensive Model Answer
Verified Solution
Two main approaches:
- Offset pagination:
GET /items?limit=20&offset=40. Simple and allows jumping to a page, but degrades as offsets grow because the database must scan and discard rows, and results shift when items are inserted or deleted. - Cursor (keyset) pagination:
GET /items?limit=20&after=eyJpZCI6MTIzfQ. The cursor encodes the last seen sort key, so the query uses an indexed range scan and stays stable under concurrent writes.
SELECT * FROM items
WHERE (created_at, id) < (:last_created, :last_id)
ORDER BY created_at DESC, id DESC
LIMIT 20;
Use cursor pagination for feeds and large, changing datasets; offset only for small admin tables. Always cap the limit, return a next link or cursor, avoid exposing raw IDs when they leak information, and document the sort order because cursors are only valid for it.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.