Hiring Programmers
I picked up a blog post by Frank Wiles of Revolution Systems today through Slashdot. I haven't ever posted any thoughts or experiences about software engineering management because I feel like I'm still very immature in the field and I want to wait until I at least think I know what I'm talking about before I start to express my opinions. However, I've spent the last two years- even when I was a programmer and wasn't managing anything- forming opinions on this subject so I think it may be an appropriate time to weigh in.
Frank stated a lot of things in his article and I'm only going to mention the things I really agree on and the things I really disagree on. The first thing I disagree with him on is something that I think he almost got right, but not quite. He says what you want is to hire expert programmers and I don't necessarily think that's correct. I agree more with Joel Spolksy's description that you need to hire superstars.
I can't speak for Joel, but to me the word "superstar" and the word "expert programmer" don't go hand in hand. If you've got a superstar who is also an expert programmer, then that's fantastic. However, if you've got an expert programmer who is not a superstar, I would keep looking because you're going to end up overpaying for someone who may technically know the ins and outs of your language, but isn't necessarily going to end up innovating and coming up with the creative solutions that your team needs to make incredible software.
There are two questions that spring from this. First, how do you find the superstars and the second is how do you know you have a superstar? The latter leads me to the first thing I agree with Frank on, and it's something that I've completely changed my mind on in the last 6 months. From the interviewing and hiring that I've done, it's pretty clear that you don't have to hire a programmer in a specific language. The reason is that watching how well someone learns a language will tell you a lot about whether they're a superstar or not. If you have an expert Perl programmer in a Java position but they aren't solving difficult problems in Java in a few weeks, you've got a problem. This is especially true in a smaller company where the Java programmers are probably also working in HTML and CSS on a daily basis, as well as maintaining the little bit of ASP code that the company hasn't managed to quite move off of yet.
The harder question is the former, how do you find the superstars? When I moved within Adaptavant from a Java programmer to a Development Manager, the first thing I did was I took most of the interview packet and threw it out the window. It wasn't that the questions individually were bad (whoever constructed it knew enough to base most of it off of Joel's guide to interviews), it's just that the packet together did not find out what we needed to know. I knew this after seeing obvious hiring mistakes. In fact, I knew the packet was faulty on my interview, as I came to the interview without having seen any Java code in over a year and could barely make any sense of the sample code that they randomly had me read. And I still got the job!
It took several iterations and even throwing out the packet a second time before I started to realize that I was finally starting to hire superstars. I got lucky a few times before then (which helped me see who I was ultimately trying find) and certainly got unlucky several times, but I've finally reached a state where I can consistently find people who I know are up to the task at hand.
I quickly realized, based on a pretty bad experience early on, that I'm looking for smart people, so I should ask some questions that any smart person can answer. There is a certain type of person who has the patience and the thought-organizational skills to unwind the knot that is a logic problem. These are the problems that come up all the time while trying to diagnose the source of a bug somewhere deep in someone else's code (or your own, actually), so you need someone who can solve problems in a completely abstract way. I took a few questions from Michael Pryor's site and that has worked extremely well. I tried the problems myself first and now I always use myself as a baseline- I know I can only hire people that are at least as smart as me, because I can do this job.
Another key is really to ask very few premeditated questions. I don't even have a clipboard with me when I do most interviews anymore. There will be questions that you'll probably think you might end up asking on basically all the interviews, but overall the first objective should be to probe what they say they know. The funny thing is that if you ask all your candidates to rate themselves on a 1-10 scale in any array of categories (which I would highly suggest doing), the ones who rate themselves higher are making up for something. I have never seen a good Java programmer rate themselves above a 6 and I have never seen a bad Java programmer rate themselves below an 8.
So probe. What was the software package you were writing? What parts did you work on? If you worked on the controller, how did it work? Did you use Struts? How does that work? Is it better than an alternative? Why is it better? What IDE did you use? What were the most useful features? Are there advantages to using something simpler? How does it integrate with your version control software? Did you use version control software? Why did you? How did your code get deployed? Could you deploy it yourself? What were the commands? Why were there that many steps? Could you have simplified it? The key is that superstars know what's going on behind the scenes while everyone else just knows the commands to get it to work. If you find someone who doesn't know whats going on behind the scenes, it's going to be 100x more difficult to teach them the commands for the next procedure, while the superstar should be able to guess.
One thing you should keep in mind, which Frank doesn't seem to agree with, is that while you can't find cheap superstars, you can find cheap future superstars, and that can work out. I don't set my own budget, but I always get a great employee. There are a multitude of problems associated with hiring cheap help- don't get me wrong- but you don't have to spend $120,000 a year to get a great programmer (the bad news is that if you've really found a great programmer, you probably can't keep them for more than about a year).
Ultimately, though, Frank's message is a good one. There were other items that I disagreed with (for instance, I'm positive I can put together a more productive team working inside an office for the same amount of money as it would cost to have a less productive team that telecommutes), but nothing that warrants more blogging. His overarching message is that you can't hire mediocre people and that is 100% true. If you have a great idea and a $300,000 budget, don't spend it on 10 grad students. Get one person who knows how to find, keep, and manage a team, and have them hire up to 3 more people. Your team will be more organized, will write maintainable code, will care about what they're doing, and will surprise you with the amount they're able to accomplish.
Comments
To play the Devil's advocate: Don't underestimate the value of experience. There is a lot of programming that you can get through just being clever (or being a Superstar, since that's the term) but more of it is based on applying reusable bits of knowledge that you simply don't know about unless you've done it a hundred times before.
A Superstar can do it well before they're experienced, but they can do it better afterwards. That's what you pay the $100K+ for.
But of course I do agree with you in general, as you know.