Today's editorial was originally published on June 8, 2011. It is being re-run because Steve is on vacation.

I think that most of the developers or data professionals out there have been through a variety of types of interviews in their careers. You might have had technical interviews that asked you to write code, or maybe you've been quizzed on SQL Server trivia or asked to explain methods and properties. Maybe you've had interviews with managers that had you define a few database terms. Perhaps you've just had someone ask you the ten common interview questions without requiring you to demonstrate any technical knowledge.

No matter what you've experienced, I think that many people would agree that the hiring process needs work. It does a poor job of actually predicting if the new employee can produce quality code or manage servers. Why is that?

Many companies have really tried to solve this. From the famous "How would you move Mt. Fuji?" questions at Microsoft to the common CS type questions at Google. Joel Spolsky has his own guerilla guide, which I assume has worked well for him, though on a much smaller scale. I think, however, that for the most part no one has come up with a good way to solve this issue.

A friend sent me this piece recently: Why the New Guy Can't Code. It's a little heavy handed, but there was one quote in there that I thought made sense: "don't interview anyone who hasn't accomplished anything. Ever." It's so easy to set up your own website, design a database on your personal machine, even put an app out for sale, that there's no excuse not to make some effort to accomplish something. Craig Farrall talked about building something in Looking for Work in SQL Server, as did Brandie Tarvin in Changing Career Gears. It's also one of the things I talk about at the Modern Resume: show people what you've done.

I don't know that we'll ever find a fool proof way to hire great employees, but hiring people that have proven themselves in the past, and can point to something they've done, is good start.