Hacker News Reader

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?

Sorry but no stats. Amazon has different hiring procedures for different teams. This was for a particular team in one branch.

> This was for a particular team in one branch.

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.

> It's not possible to design and evaluate a weekend project for each one of them

Can't you just design and evaluate one project that they can all do?

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.

It's absolutely doable to evaluate one hundred take home tests in a week. It is a full time job though.

That will only work briefly because of glassdoor interview posts. However that might only mean tweaking it slightly every week or two.

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.