Another day, another "coding interviews are broken" post on HN, the same old replies. So here's mine. - A vast number of people masquerade as "programmers", "e

Another day, another "coding interviews are broken" post on HN, the same old replies. So here's mine. - A vast number of people masquerade as "programmers", "engineers" or "developers" who couldn't code their way out of a paper bag. If you don't believe me, you haven't conducted interviews. - This was the key motivation behind FizzBuzz. Passing it doesn't mean you're a great programmer. Failing it means you're almost certainly not. So the ability to turn a super simple "algorithm" into code in [language of your choice] is an incredibly useful negative filter. - Interviewers and companies fall into the trap of thinking "this problem is too simple; let's make it harder". In doing so you devalue the negative filter and gain NOTHING as a positive filter. Worse it can turn into a gamble as to whether you happen to know the particular trick for that problem. Tortoise and hare or O(log n) bit reversing fall into this category; - Taking a problem and being able to reframe it in terms of standard data structures and algorithms like recognizing it's a particular graph problem is an incredibly useful skill. These don't always need to be turned into code. I'll say it again: the biggest problem is people try to make whiteboard problems "hard" making them a useless signal. I'll add: - I'm dead against "take home" tests. I don't have time for that. This seems like a great way of getting mediocre candidates. Like, what makes you think if someone can't do it they won't "cheat"? - Talking about robust systems design isn't done often enough; Here's another thing I've pondered: how much of coding interviews and the notion of "cultural fit" is really thinly-veiled discrimination? I expect quite a lot and I expect this to blow up at some point.