As I’ve grown more senior in age and rank I’ve come to realise just how important it is to carry on the selection process after the interview, during probation, and managing performance throughout your hire’s entire journey. It just feels so incredibly imprecise relying on a few hours of meetings to gauge if someone is good or not, and the probationary period is crucial for correcting mistakes. Frankly, we also can’t afford to say no accidentally to someone who would turn out to be a great hire.
I’m seeing this now through the lens of hiring at a 100 person org, but I’ve done hundreds of interviews as a FAANG employee too. The difference there, I would say, and what GOOG try to do is to shoot for the moon and get hiring nailed at the interview process. This comes at the expense of rejecting nine out of ten candidates because the candidate firehouse is free flowing and plentiful: something I don’t have at my much more normal startup.
I’ve don’t think I’ve ever seen engineers complain about the rejection rate of Google’s interview process. The more common criticism/meme regards the laziness of running candidates through a unidimensional leetcode gauntlet. Half joking, but why even have engineers run these interviews at all? A proctor could get the same job done at a fraction of the cost. If a proctor can run the interview process, then how valuable is the signal?
I’m seeing this now through the lens of hiring at a 100 person org, but I’ve done hundreds of interviews as a FAANG employee too. The difference there, I would say, and what GOOG try to do is to shoot for the moon and get hiring nailed at the interview process. This comes at the expense of rejecting nine out of ten candidates because the candidate firehouse is free flowing and plentiful: something I don’t have at my much more normal startup.