Hacker News Reader

Comment by dakiol | Hacker News Reader

The guy had to invent “cool” scenarios because companies think they are Google and working in backend doing normal things won’t get you hired. One could easily have prepared the whole interview with AI without failing to explain details (like what data was being paginated) just by lying a bit more. Not lying on your actual knowledge but on what your previous jobs were about. E.g., I have used k8s in pet projects but not at work, but this job ad for a backend position asks knowledge about k8s, so I’ll put k8s as skill under my last job and invent a credible story that I can talk about based on my experience during my pet projects.

I think the message here is: don’t ask for the moon, you are not Google.

View on HN

While I think this view is probably apt in other situations -- and to be clear, I don't know much about the company -- all of the specific techniques mentioned on the candidate's CV and in the article are fairly "garden-variety".

The pagination example seems like a perfectly reasonable thing for both sides to want to talk about, and which becomes relevant at a level of scale much smaller than Google.

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.

What’s the better way to do pagination?

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.

This article looks like a decent overview: https://medium.com/better-programming/understanding-the-offs...

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.

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.

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.

They weren't asking Google questions. They were asking about basic pagination, which is an entry-level topic.

Hard to argue with their interview process when it successfully unmasked someone who didn't have the basic experience to discuss a simple topic.

The message is: good lie is not too far from truth.

Reply on news.ycombinator.com