[bko]

Thank you for this. Some people are critical of coding tests but I do this there is a point: namely to weed out people who can't code.

Am I the only one that interviewed people with lengthy resumes full of programming experience and when I asked them to do a simple programming exercise they fell flat on their face? I've seen experience in C, gave them take home two hour exam and they couldn't even get anything to compile. What he meant was he took a class a few years back.

You see it in other domains with extensive Excel experience and the guy gets hired and never heard of a vlookup.

I think some of the stuff is overkill but you need to select for people that know how to program.

I for one am glad they exist because I don't have a CS degree but learned on my own. I lucked into this profession through an online leetcode style screener and your book helped me immensely,so thank you

[BeetleB]

> namely to weed out people who can't code.

You don't need Leetcode style tests to weed those out. Much simpler problems will do it.

[stmw]

I think we may have disagreement on what Leetcode means in this context -- but it has to be complicated and varied enough that simply memorizing the solution is not sufficient. It being interesting is a bonus for other parts of the technical interview.

[BeetleB]

Sure but there are varying degrees. I often ask people to write a factorial function. Quite a few fail at this basic task.

[stmw]

We agree - this is why programming interviews - whiteboard, virtual or something else - are here to stay.

[stmw]

You are not the only one. I've interviewed probably 1000's of engineers and it is striking how often one runs into candidates that can't code... or ones that operate at a level far below what you would expect.

[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?"