I don't really understand this point of view, because implementing a Sieve of Eratosthenes is not particularly difficult.
I really don't know where to start with your comment. All I can suggest is that you sit in on about a dozen interviews by someone who actually knows how to interview and learn from that process. The thing about interviewing is that it is really just about due diligence. You are verifying that what someone represents on their resume is likely to be true. I think it's great that you are passionate about algorithms and various Sieves. You are a piece of a puzzle in a team. Someone who loves algorithms will pair well with someone who loves standard CRUD, as well as a UI designer. You are not looking for someone who knows exactly what you do plus more, you are looking for a team member.
Interviewing on "what you'll actually be doing" is also problematic, since most work is simple stuff that won't demonstrate the difficult edge cases.
Why not let your inferior-sounding candidate handle all of the CRUD and you can tackle those fun edge cases? For hacker news, I'm not sensing a lot of hacking going on here.
I am 100% positive that I can ask someone 10 questions that they don't know the answer to, and subsequently make them look like a fool. I can do this to PHD's, it's not hard. Get over yourself and start looking at candidates as potential team members, rather than opponents or competition.
I didn't get the impression OP thought that he was too good to implement a linked list in JS. Rather, he was looking for a company that was too good to spend interview time on a question containing low signal.
Like, the question itself is boring and cookie cutter. Why not implement a linked list or a tree in SQL (much more interesting for everyone)? Or a simple query language in JavaScript (a bit more practical)? Or tell have them do a code review of a simple webapp, have them critique it, then have them refactor it with you (much higher signal overall question)?
If your goal with an interview is to see how much bureaucratic bullshit a programmer is willing to put up with, by all means have them write linked lists. Have them write 5, one for each person interviewing them. If not, think about what you're trying to figure out about the person and craft the questions to suss out who it is you're talking to. "Program a linked list" is uncreative, and won't let you know very much.
You're missing the point of the linked list. A simple coding test like "program a linked list" during an interview is just a negative filter. Someone who can't write a linked list certainly is not a good programmer.
Parent was in no way suggesting he/she was "too good to implement a linked list". The point being made was that being a logic problem solving performing monkey doesn't really say much about your practical abilities in real world apps.
I believe the person is saying that it is okay to asked linked lists questions, but you must also ask practical questions.
In your case, why not ask about linked lists, and then ask why in a CRUD app the models are ending up in a mixed up state when you add a second application server?
