imho I think the pagination example alone wouldn’t get you hired even if told correctly. In over a decade of experience my “coolest experience” related to pagination is about not using LIMIT and OFFSET because it’s not performant… but that’s 101 knowledge and doesn’t sell.
The pagination was chosen because it was prominently featured in the candidate's resume, and was something that interviewer was familiar with - it's not about "cool experience", but rather conversation starter.
When performing interview, asking about things mentioned on the resume is a pretty good conversation starter. No one wants random trivia, resume entries, especially from the most recent jobs, are absolutely fair game. And if they turn out too simple, we can always dig further based later.
You don't use OFFSET because the btree index just sorts the rows from smallest to largest. It can quickly get the first 30 rows, but it can't quickly figure out where the 30th or the nth row is. When pagination is crawled it will crawl the whole table, so it's important that the worst case performs well.
The fix to this is to paginate by saying "give me 30 rows after X" where X is an unique indexed value, e.g. the primary key of the row. The RDBMS can quickly find X and 30 rows after X in the sorted index.
This makes it hard to implement a "previous page" button but nowadays everything is a feed with just a "show more" button so it doesn't matter much.
Not necessarily "better" but cursor-based pagination, for example, has a different set of trade-offs. It can be more performant, but tends to be trickier to implement.
The easiest alternative is using a where clause and filtering by an ID range. Eg: "WHERE id between 1000 and 1200". But this introduces a ton of limitations with how you can sort and filter, so the general advice of not using LIMIT and OFFSET has a ton of caveats.
