Hiring continues to be a favourite whipping boy on HN and honestly I kind of wish it would die because it's the same arguments every time: - Inconsistent inter

Hiring continues to be a favourite whipping boy on HN and honestly I kind of wish it would die because it's the same arguments every time: - Inconsistent interviews - Luck of the draw questions - "I don't do well coding on a whiteboard" (often framed as "coding on a whiteboard proves nothing") - Bad experience with the process - Etc Personally I don't mind coding on a whiteboard but only if you understand why you're asking a candidate to do it and what you hope to gain. Unfortunately many (IMHO) get this part wrong. Obviously FizzBuzz was influential here. And I honestly think FizzBuzz is the right way to think about live coding tests because it's simple. It's deceptively simple such that anyone competent easily falls into the trap of thinking the question needs to be harder and this is a problem with many FAAMG interviewers. On the other side I think there are people who don't realize how many people are masquerading as programmers who can't program a for loop in their language of choice. It's actually hard to believe for anyone semi-competent unless you've witnessed it but it's true. FizzBuzz is a simple problem aimed at providing an early negative signal on a candidate. Every word of that was deliberate and important. It's simple so anyone remotely competent will pass it within minutes and you can move on. This doesn't mean that if you ace it you're a good engineer ie there is ZERO positive signal here. The negative signal is if you can't solve this simple problem in your language of choice because then you almost certainly aren't a good engineer and you (the interviewer/employer) can stop wasting your time. This is why it's so important it's a simple problem because a hard problem adds very little positive signal and greatly reduces the negative signal. Some people are bad under pressure with hard problems. Some questions are a matter of knowing the trick. Finding cycles in a graph is trivial if you are familiar with the tortoise and hare algorithm. If not you may figure it out from first principles but if you don't it doesn't mean you're a bad programmer or you shouldn't be hired. That's the problem. On the other side some like to lambast interview processes if they have a nonzero false negative rate. These stories usually go "I referred excellent engineer X and they bombed out on a random coding question" or similar. This happens but getting a false negative doesn't invalidate the system. It's important to remember to that the goals of the employer and the candidate are different. The candidate's goals are to try to get a positive signal to the employer. The employer's goals are to minimize time spent per candidate (since this is expensive) while hiring a sufficient number of qualified candidates with a minimum of false positives. Again, every word of that is important. False positives are expensive. If you have a pool of 100 people to fill 10 roles and 20 are will work out then, as the employer, you don't often care which of those 20 you get, as long as you get 10 of them. There's an effort-reward curve between getting 10/20 qualified candidates vs the best 10. Lastly, this is also why there is an interview slate of 4+ interviews. A single bad interview does not kill your chances. I'd say Google's biggest problem is interviewer dead wood. These are people who have their pet questions, which were banned years ago (as either being too well known and/or just being a bad question) but they keep asking it anyway. Or they know <pick your language> and then force the candidate to use it and then mark them down for not knowing it (when the candidate never claimed to know it). Part of the delays in Google hiring too are some people will do an interview and won't submit feedback for 1 or even 2 weeks, a process I personally found inexcusable and infuriating. But interviewing is one of those things that everyone is expected to do, which needs to change as many people are either bad at it or just don't really care. I would also say, if anything, Google (and this probably applies to most if not all big tech companies) doesn't filter often and early enough. I saw candidates who never should've made it passed a phone screen. In some cases I saw the phone screen feedback (as part of the whole packet) and I honestly don't know why it didn't end there. My own theory was that recruiters largely controlled this and they had quotas to meet of phone screens, onsite interviews and hires and this just ended up wasting a lot of interviewers' time. But that was just a theory. Disclaimer: Xoogler