[bornfreddy]

Meh. There is a world of difference between 1337code problems and anything one encounters in the real life. Judging someone by that 1h slot on a domain they haven't worked on for decades doesn't paint the right picture. It does tell a lot about the priorities of the company though, so there's that.

[stmw]

I think it paints part of a picture - obviously you shouldn't hire just based on top score in an algorithmic interview. But if I interview someone for a JOB WRITING CODE with decades of experience and they refuse to write code and can't explain the difference between a linked list and an array, that's a good argument for reconsidering hiring them...

[bornfreddy]

Sure, explain. Write? Not sure about that. The main question is what kind of code they are supposed to write. Have you actually used a linked list in a company setting? I know the difference, but can't say I've used it... ever, in a company setting. I guess if I worked for Redis or similar this would be base requirement, but for 98% of software development jobs I don't see where this could be useful.

My experience is the opposite - developers eager to squeeze every last drop, using some exotic data structure [*] or sorting algorithm which takes way too long to implement and makes code review a nightmare. For a feature that doesn't need it.

[*] not saying that linked list is exotic, it is just rarely needed in $DAYJOB in my experience.

[stmw]

Yes, I have used a linked list in a company setting, both in writing code and in technically leading things where understanding the behavior of linked lists vs arrays was important. But again, it's not the only criteria in these kinds of interviews IF CONDUCTED WELL - the specific experience you cite, of "developers eager to squeeze every last drop... makes code review a nightmare. For a feature that doesn't need it" is also part of what you're looking for. And you can ask a candidate who does that "hey, that seems unnecessary here and hard to undrstand, why are you doing that?"