Hiring good people is really simple

It really is. There's no magic involved.

Again and again I come across articles from people complaining about the current interview practices. They complain it doesn't give you enough depth into the candidate's ability, personality etc. That it measures the wrong qualities. Or that it just doesn't work and bad people keep coming through the pipeline.

Well, instead of complaining how about you change it? I'm talking about hiring software engineers here so the first rule you should keep in mind is that you need to get them to write code.

Let me spell that out for you: get them to write code.

It's as simple as that. If your hiring process doesn't include this step, just give up and go do something else.

What kind of company are you hiring for?

This is important because it will let you know how to structure your interview process and where to place the "write some code" step. For instance, some companies such as Google, Facebook and ThoughtWorks can't afford bringing in every candidate for on-site interviews. Not with that influx of applications anyway. Such companies put some sort of coding challenge as their first barrier to entry, before you're ever invited into their offices. So keep that in mind.

What should I get them to code?

I'm glad you asked! But I'm afraid the answer is it depends.

Different companies - which in many cases means different projects, business models, cultures and what not - hire inherently different people. You need different skills.

Here is where I think ThoughtWorks gets things right most of the time. The coding challenge the candidate is given is, to a smaller extent, the exact kind of code he's most likely to be writing once he joins. By no means does it mean he's expected to write the same projects over and over. Far from it. It just gives us a fair go on their abilities in a close-to-real setting.

Google, on the other hand, will give a programming challenge over the phone. Pardon the pun but 'google' it and you'll see it often involves puzzles which leads me to assume they solve puzzles everyday - don't get me wrong, they helped solve many computing challenges of our time that I'm thankful for but they have a multitude of projects that need different skill sets and as such I'm not sure it's the best process but, hey, they seem to have the best engineers in the world so it sure works wonders for them.

The bottom line is that this coding challenge should be geared towards finding what your company values, and what it considers to be good code. If puzzles work for you, do that. If you value well tested code, state so in the challenge and evaluate if you're presented with a well written test suite. If you want someone who can learn anything fast, ask them to develop a simple app in a language they don't know. You catch my drift.

What then?

The coding challenge is all well and good and it's an extremely useful tool. However what happens next seems to vary a lot from company to company so I'll share here, from personal experience, what I think really works: have candidates code whatever project you're hiring them for.

Back when I moved from Brazil to Spain in 2008, this is exactly how I got hired.
I was interviewed over the phone by one of the company's owner friends. He's a genius. He had worked at this same company before but moved on to Google later on. That was my first barrier. Once past that, the company simply invited me, with all expenses paid, to spend a week in their offices, working on a real project together with my soon to be co-workers.

This was by far the most thorough interview process I'd ever been through. They actually got to see how I work. How I deal with other people. How I approach real problems. And on the other hand, I also had a great chance to evaluate what I was getting myself into.
After that week was up, the company's CEO gathered the feedback from all my peers and to my delight made me an offer.

I still think this is the only way you can be sure to be hiring the right people. Is it time consuming? Yes. Is it expensive? Maybe. You can save a lot of money by only paying the wrong person to work for a week, than actually hiring them and having to pay for at least a month's worth of work from them. Bad work at that!
I suppose such a process wouldn't work for some companies, mainly Google and Facebook given that even after the first few barriers there are still a lot of applicants left but then again most companies out there aren't like them.

But make no mistake - finding the right person is hard and it takes time. Knowing if someone is that right person, on the other hand, is simple, if you're committed to it.

Conclusion

Obviously this isn't the only way to hire good software engineers. But I do believe it's the only one that is fair to both the company and the candidate and will definitely decrease, if not eliminate, your false positives.

Oh, and I apologize if I sound pedantic but getting them to write code, by whatever means, isn't optional.