,,Hard questions do filter out bad engineers, but they also filter out good engineers (that is, they have a high false-negative rate). Easy questions, in contrast, produce fewer false-negatives but more false-positives''
The philosophy at Google is that it's better to filter out 3 good engineers than to let in a bad one. The consequence of this is that it's really hard to get kicked out of Google.
The other part (whether it's more important to work on long easier questions to see how the candidate works on a large code base) is orthogonal reasoning, and that part may be true, depending on what type of engineers somebody is looking for.
The philosophy at Google is that it's better to filter out 3 good engineers than to let in a bad one.
Corollary: "If I follow (what I've heard to be) Google's hiring practices (despite not having their brand recognition or candidate pool or a comparable engineering environment to offer) -- then my company is on the way to becoming another Google!"
Sure, it's something not to be copied by a small company. But it's important to understand for good developers that they can be great and still fail the process (they just have to prepare again adn reapply)
> The philosophy at Google is that it's better to filter out 3 good engineers than to let in a bad one.
Google's problem nowadays is that they have such strict standards only for grunt developers, but not for management. In fact, it looks like that it's more like opposite, i.e. it's better letting in/promoting 3 bad managers/directors than 1 good one.
This is sadly true, but even more true for PMs, the average engineering skill required to be inside the organization went down. When Eric Schmidt was selected as the CEO, having a strong engineering background was a requirement for him, and he was great at connecting with engineers inside the organization (probably not that great with connecting with sales, they had to accept that Google was an engineering driven organization in the past, now it's a mix).
> The philosophy at Google is that it's better to filter out 3 good engineers than to let in a bad one.
Just fire the bad ones. You're going to get bad ones anyway. At larger companies you might never notice whether someone is good or bad.
From the way they structure their interviews, it seems like they'll still get plenty of bad ones - it's just they'll get bad ones that are great at algorithms, with unknown skill at everything else (like the actual work done).
Who and what decides what a bad software engineer is (note this is very different than deciding who is a good)? Is it a manager? Managers are single people so shouldn't be the sole deciding point. So you need to gather feedback, aggregate it and decide what constitutes bad. Then have that feedback reviewed by independent people to ensure that no one is being unfair. That takes time and bureaucracy.
For me not being afraid to get kicked out of my workplace was a good thing. Also most of my colleagues were amazing, I miss talking to them, but at the same time I don't miss what the top management has become.
The philosophy at Google is that it's better to filter out 3 good engineers than to let in a bad one. The consequence of this is that it's really hard to get kicked out of Google.
The other part (whether it's more important to work on long easier questions to see how the candidate works on a large code base) is orthogonal reasoning, and that part may be true, depending on what type of engineers somebody is looking for.