I have to take exception to this because part of what I do for a living is teach tech companies how to hire. The claims are: 1. Performance on our online prog

I have to take exception to this because part of what I do for a living is teach tech companies how to hire. The claims are: 1. Performance on our online programming quiz is a strong predictor of programming interview success 2. Fizz buzz style coding problems are less predictive of ability to do well in a programming interview 3. Interviews where candidates talk about a past programing project are also not very predictive Those claims may be true, but it misses a key point: no matter how well someone performs in an interview, it doesn't mean they'll perform well on the job. In particular, the post talks about hard skills (and does well there), but doesn't talk about soft skills. It's absolutely true that someone can talk a big game about hard problems they faced that they solved, but failed to mention their use of Google or StackOverflow. So unique coding tests can definitely tell us whether or not a candidate can really code (though the tests need to be tailored to the sort of real work the candidate will face). However, programming is a hard skill (one that is easy to teach), and not a soft skill (one that you tend to learn over time or have a natural inclination for). Case in point: early on we made the mistake of hiring a very talented programmer on the basis of his reputation and a brief interview. He was a disaster because he was completely unable to work without a very hard set of requirements. In the very rapidly changing, agile, environment we put him in, he flailed badly because he was good at implementing requirements, but he was very bad at projecting himself into the customer's shoes. Later, we put him on technically demanding tasks which required considerable talent, but had no ambiguity, and he was fine. In fact, he was able to implement tasks that would have been very difficult for other developers who were fine in ambiguous environments. Soft skills are tricky and most employers have no idea how to interview for them. They require an understanding of the actual role someone will be hired for and the set of skills necessary for them to succeed. Are there tight deadlines? If so, can the developer prioritize tasks and make a case for delaying less critical portions beyond the deadline? Is it a rapidly evolving environment which makes it hard to nail down exact behavior? Are you on a team with strong personalities who often disagree and can the dev handle that? Is the developer required to report to non-technical people who have no understanding of technology and can't appreciate what refactoring is? Or here's a fun one for you aspiring managers: we've had one project with a superstar developer who was so monumentally productive and so brilliant at his work that some very talented developers who worked with him nonetheless had negative productivity at times because they spent so much time playing "catch up" with the superstar and understanding how the project was evolving that they spent more time keeping abreast of the code than developing it. The code was "bus sensitive" because one brilliant developer was so competent. How do you manage that? These and other soft skills are part of what you really need to evaluate because depending on your work environment, you'll have these and other soft skills as critical skills that a dev will need, but you almost NEVER see interviewers check for these because very few people are trained in interviews. Pro tip: start reading up about structured interviews. They've been proven via multiple studies to have a strong correlation with employees being successful. Unfortunately, they're harder to conduct and require training to understand them. As a result, companies don't know about them or worse, ignore them, because it costs more money. But what costs you more money in the long run? Taking longer to interview or hiring the wrong person?