I’ve made both really good and really bad decisions when hiring programmers so even I would take my own advice with a grain of salt. Nevertheless, I thought I’d Jot down a few Ideas about my trials with this.
When you are trying to evaluate programmers there are lots of things you might consider. For me, these things fall into one of the following categories:
- Attitude/Personality
- Talent/Intellect
- Experience
Attitude is extremely important to the success of the team but Its even more important to your happiness as a manager. Nothing sucks worse than dealing with people who are an pain the ass. People that are difficult can divide your team and consume all of your time as you try force people to work together.
There is alot of talk about trying to avoid the cowboy programmer mentality where one programmer appoints himself lord over the code or a section of it and resists anyone else who is making a change to it. And while this can be a problem, I think it depends on the specifics of the person, the code in question, and the team. It can be ok if someone is defensive of their code depending on what is motivating this. When they don’t want to listen to anyone else because they are self-conscious about the code and don’t want to deal with the inevitable criticism, this can be destructive to both the team and the code. However sometimes the issue is that the programmer is rightly confident and simply doesn’t want to listen to other people’s “suggestions” when they have more knowledge and experience. Good management is often being able to tell the difference.
The more common attitude problem is just people who don’t care about their work. These people are essentially either immature or selfish and just don’t get what it is that they are paid to do. Often they don’t feel like they should be burdened with actually working during the day preferring instead to chat with their friends or worse yet, the other members of the team. Nothing is wrong with a little office cooler chat or even IM’ing a few funny websites around during the day. But people who are constantly on the phone, on Ebay, or just milling around from office to office need to look for a new line of work.
These are generally the same people who don’t really care about quality either. They check in code that’s not tested because its not really their job to “do QA”. I’ve heard of people like this who have reformed but I’ve not experienced it much. On balance I think that if you have someone like this on your team your best bet is to encourage them to seek other opportunities.
The other thing you want is someone with a real desire to do the work. Some people like programming and for some its just a job. Its really rare to find someone who really loves the work who doesn’t also code in their spare time. But you have to be careful. There is a difference between people who like to program and people who like to talk about programming. Sometimes this doesn’t show up till after the person is hired. People who talk eloquently about different programming paradigms and books they have read during the interview will sometimes keep up this conversation after they are hired.
Talent is the raw ability of someone to translate concepts into working code. This is not generally a learned talent. Most people who are good at programming are good from when they first start. I can only think of one case I can remember where someone who was mediocre for a long time became great. I’m not sure why some people have it and some don’t. It certainly has alot to do with raw intelligence but its more than that. I have met plenty of smart people who can’t code well even though they tried but I haven’t met any great coders who weren’t pretty sharp overall.
While its fun to work with people who are truly gifted, there are a few things to watch out for. Talent can often cover for a lack of experience but the covering almost always has a few holes. I often make the mistake of thinking they know more than they do since they seem so competent. It does feel good sometimes though when the old guy can teach the new kid a trick or two.
The other thing to be concerned about are Zealots who think they know the best way to do everything. While this certainly isn’t exclusively a problem with talented coders, they are the ones where this creates the most problem. This is because they are often talented enough to make things work “the wrong way”. In software there’s is almost always at least 3 ways to do something but in a Team its important to have some consistency of methods. A talented Zealot coder will often rebel against this “needless” conformity and back it up with lots of great working code that doesn’t fit the model of the rest of the code.
Experience probably has the biggest impact one how valuable the person will be over the life of the project and especially at the end. While your younger coders may be the ones knocking out the highest line counts early on, closing the project out requires people who know what it means to ship a product. Shipping isn’t just about sleep deprivation, it requires making alot of decisions about how to make fixes in the least risky way and dealing with spikes in your bug count without panicking or getting angry with QA.
Experience can be alot of things that aren’t on a resume. One of the best hires I have ever made was someone who hadn’t had a job programming before. In Interviews I like to ask people about programming projects they have done that weren’t for a job or a class. This person had developed his own Open Source application, released it on the internet and had a community of users he was supporting with updated versions, documentation, etc. He knew alot more about the actual development process than the average graduate.
Some people can have too much experience. Someone who’s resume is full of different jobs might have done alot of things or they might have done alot of nothing. Lots of job changing is usually indicative of lots of unhappiness. People who left unhappy from their last few jobs are usually destined to leave unhappy from their next one.
In closing, I’ll list my favorite interview questions. There are websites full of challenging puzzles to ask prospective employees. These are not like those.
- What kind of computer do you have?
- Wrong Answer: Any Brand name
- Right Answer: Motherboard specs
- What is your favorite movie?
- Wrong Answer: Any Star Trek Movie
- Right Answer: Anything not Sci-Fi
Leave a Reply