- 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'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.