Se a vaga pede REST / HTTP, vale saber responder isso. A resposta está em inglês de propósito, porque é assim que você vai precisar falar.
Offset (LIMIT 20 OFFSET 4000): simple, allows "jump to page 200". Problems: gets SLOWER as offset grows (the DB still walks past every skipped row) and items shift if rows are inserted mid-browse.
Cursor (WHERE (created_at, id) < (:last_created_at, :last_id) ORDER BY created_at DESC, id DESC LIMIT 20, backed by an index on (created_at, id)): the client sends a pointer to the last item it saw. The id breaks timestamp ties. With created_at alone, rows sharing the boundary timestamp get skipped. With a matching index, the database can seek near the boundary instead of discarding every preceding row. It is not a universal O(1) guarantee. Mutating sort keys can still skip or repeat rows, and an ordinary cursor does not create a fixed snapshot. A good fit for feeds and infinite scroll.
Say: "Use offset when page-number navigation and dataset size justify it. Use a stable cursor and matching index for large sequential scans. Define what concurrent changes are allowed to do."
Ler é o primeiro passo. No app, essa pergunta vira flashcard com repetição espaçada, e o módulo tem quiz e simulado para testar o que ficou.
Treinar essa pergunta no app