This is a great way of hiring, but unfortunately it doesn't fit in all scenarios.
First, this model alone doesn't scale. Big companies interview hundreds of candidates every week. It's not possible to design and evaluate a weekend project for each one of them. This doesn't mean that they can't have projects, but early filters are needed. That leads to the classic phone and F2F interviews to rule out those who can't code. If you freeze in one of those because of the pressure, you're out.
Second, for simple developer positions, such weekend projects might be very good. But if you are trying to hire a senior developer who is going to solve problems at big scale, then the ability to create a simple movie catalog doesn't tell you anything. And there are no big scale weekend projects. You have to ask about algorithms, data structures and other CS topics. These things are important!
Bottom line, this is a nice hiring technique suitable for small companies at a small scale. But it might not be that useful for big companies.
Sorry but this is simply not true. After a while we decided to do exactly the thing that the article describes as our preliminary interviewing process at Amazon. We also had extensive onsite interviews, however we did not ask candidates to code at the whiteboard. Btw, when you work for such companies it is expected that you spend 10% of your time on hiring. Getting hiring right is one of the most important things that you need to do at the scale of Amazon, Google and all of these large companies. Having a single bad hire can bring down the performance of an entire team.
I'm curious if you have any statistics about the different interview styles/processes. Obviously it's hard to figure out the false negatives (good engineers you didn't hire) but how about false positives?
Also, is homework assignment now a part of the standard interview process at Amazon or is this just your team/department?
Which is a bummer. When I interviewed at Amazon a few years ago, it was a day of coding on the whiteboard. Turned out I didn't have the Java experience that group wanted, and I'm allergic to pager duty so that was a non-starter for me.
You are right about the scalability of the process, but not about the rest. It seems possible to design weekend projects that would be way better for evaluating senior engineers than asking them to do CS brain-teasers on whiteboards. CS topics are important, but the typical interview is not great at identifying who is good at using CS to solve real production problems. It seems like the typical interview doesn't have many false positives but a lot of false negatives.
The common approach for big companies is to declare that false positives are way worse than false negatives, but if the problem is that you can't find enough developers to fill your roles, it may be better to have false positives coupled with a trial period or something similar.
Even if you design only one project. You still have to evaluate them, have a discussion, etc. That takes time. It doesn't scale to hundreds of interviews per week.
Glassdoor wouldn't really help someone cheat in this situation. It's not a quick answer, it's a code discussed with the interviewer after finishing it. It would be fairly easy to tell whether someone had copied their code.
First, this model alone doesn't scale. Big companies interview hundreds of candidates every week. It's not possible to design and evaluate a weekend project for each one of them. This doesn't mean that they can't have projects, but early filters are needed. That leads to the classic phone and F2F interviews to rule out those who can't code. If you freeze in one of those because of the pressure, you're out.
Second, for simple developer positions, such weekend projects might be very good. But if you are trying to hire a senior developer who is going to solve problems at big scale, then the ability to create a simple movie catalog doesn't tell you anything. And there are no big scale weekend projects. You have to ask about algorithms, data structures and other CS topics. These things are important!
Bottom line, this is a nice hiring technique suitable for small companies at a small scale. But it might not be that useful for big companies.