| Interviews are hard because programming is an incredibly complex task with few qualified candidates. Any programming challenge other than the most basic questions is going to have a long-tail distribution in the time it takes a person to answer them. It's easy to get hung up on something stupid, especially in a high-pressure situation like an interview. We've all had moments where we missed something "obvious" for weeks on the job. In college they solved the time-pressure problem in tough classes by making the homework really hard and the tests really easy (like the take-home project OP suggested), but that relies on an honor code and the fact that getting a good grade on your homework is not nearly as important as landing a job. Also a lot of great programmers don't want to deal with your bullshit project because they're getting recruited by a million other companies. If some new metrics end up in widespread use, most of the people that pass the test are going to be ones that gamed the system (e.g., added a bunch of GitHub projects), just like the majority of people that get really hard coding puzzles have seen the trick to solving them before. No matter what you'll end up with low true positive/negative rates for any test you do. I think the right way to deal with this is to come up with a bunch of orthogonal tests and then choose candidates that pass a bunch of them. Have them debug a program, have them do web programming, have them talk about a project they did, give them a project to do if you can, etc. The main thing I learned after doing hundreds of interviews is that I have a limited view on how to judge a programmer, and that view translates only so well to the question of "how much value will this person add to our company right now." So yeah, TLDR, I don't think the status quo is great but I don't think any of the solutions proposed over the years are better. |