The December 15, 2005 issue of SDTimes has an interesting article on hiring tips and practices. On a couple of points, they hit bullseyes, but on some others, I think a hiring manager can do better. One thing is certain, though - if you are a hiring manager, this may be the most important thing you can do to influence the long-term success of your team, so be sure to give hiring the time and attention it deserves.
Read on for more, including specific improvements to the practices in the SDTimes article and some key traits you can look for in candidates.One of the parts of the SDTimes article I agree with in principle is trying to understand whether a candidate can think outside the box. I do not, however, advocate doing this by asking how many cars can fit on Manhattan. In my experience, I've seen some people who would handle that sort of question well, and I've seen some really good people who would completely self-destruct given that sort of non-sensical question.
A lot of this depends on the person and the role you're hiring for. If you're hiring a business analyst or designer, for example, it may be important for that person to be able to grasp the context around specific questions or statements, so for them, the "Manhattan" question might be interesting. For a technical role, however, you want out-of-the box thinking with respect to technical problems. Try putting them in a moon-launch scenario, for instance, and throw some failures at them. I once interviewed someone who came into the interview extremely nervous - to the extent he couldn't answer a question without stuttering and breaking up - and as the questions got technically harder, he got calmer and his answers got better and better. If you want a technical hero, this is your guy.
The SDTimes article also talks about team interviewing. Again, I agree with the article -- almost. I think it's important to point out a precursor to the interview that was left out of the article: the phone screen. Before you bring people in to meet the team, it's important that you've had a conversation with the candidate one-on-one.
Done properly, the phone screen accomplishes two things. First, you minimize waste. You clearly do not want someone coming into an interview unless they're going to be in the running for the job. It sucks a lot of time out of your team to do an interview right, and you don't want to waste that time. You will not get a proper sense for this just by reading a resume, though you should be able to rule some people out this way. Remember: when you complete a phone screen and are ready to schedule an on-site interview, you should legitimately feel that the candidate would be a good fit for the job. If you don't really feel this way, don't waste everyone's time with an interview.
The second thing you can accomplish with a phone screen is to give a candidate a sense of who you are and what you're looking for in a hire. You owe this to a candidate, and it will help them orient themselves for the interview. Given a little background, you can tell which candidates are going to take the time to think about how they can fit in your organization. You also get a chance here to let the candidate get to know you. Remember, you're (hopefully) going to ask this person to work for you, so they're going to be interviewing you, too. For these reasons, the phone screen is important enough that you should do them yourself. I've tried pawning this off on team members, and I'm convinced you don't get the right results from this.
The other problem I've got with the Team Interviewing part of the SDTimes article is the little bit about what you do when you don't have a unanimous decision. Bottom line here: you have to have everyone on board. Every team member has full veto power. That's why they're in the process. Note: this isn't the same as saying that any objection raised by any team member will shoot down a candidate - that's why you get everyone together after the interview and talk through their feedback. You can, and should, have people bringing objections into this meeting. If they don't, you need to work on their interview skills. Once you've talked through pros and cons, however, everyone gets a chance to say "no hire". If anyone -- anyone -- says "no", the candidate is history. You've hired all these guys (and hired well, I hope) and you have to trust that they have the best interests of the team at heart.
The last aspect of hiring to consider is skill set and character traits. It's common in our technical environment to get wrapped up in technical skill sets. While it is immensely helpful to know something about the programming languages and environments your team uses, don't lose sight of the fact that our technical environment changes quickly and inexorably day after day, year after year. It may be cliche, but it's true that the only thing that stays the same is change.
Given that change happens, you need to evaluate a candidate's ability to roll with that change and to pick up new tools and technologies. Attitude is an important predictor here. Some people can see technical change as an assault on their self-worth and identity. Trust me, you can't help these people. Some people are quite certain that their way of doing things is the best there can possibly be, bar none. You're not worthy of these people.
Instead, look for the people who are able to focus on an objective and drive toward it using whatever tools are at their disposal, including some they may never have used before. A few years ago, I used to quiz people on resources they used to stay up to date with technical change and to solve tough problems when they encountered them. Today, there's no excuse for instant satisfaction. There are very few problem that don't have answers in Google, for instance. I hired a guy that I completely believe would be capable of working his way through open-heart surgery armed with Google (and maybe a spare patient or two).
In addition to Google-guy, you can look for the silent-but-deadly developer. This is they guy who doesn't make a lot of fuss, but cranks out volumes of code that all works. Note that when I say "silent", I'm not talking about intensely introverted, I'm talking about the guy who knows what the job is and how to get it done, and would just as soon you leave him alone to get it done. This person, in order to be successful, will be able to understand a problem at high and low-levels simultaneously, so he won't be easy to spot, but he's a great asset if you can find him.
Watch out for crisis-boy. This is the guy who creates or magnifies catastrophes so he can swoop in to fix them. This person is characterized by a lot of self-congratulation, technical elitism, and last-minute heroics. His ego is fueled by the adolation he gets when he rescues a release at the last minute. In order to really understand why this is bad, consider how you'd feel about an airline that had pilots that were so good that they could recover from near-disaster after near-disaster. Hats off to the pilots, right, but how about figuring out how they keep getting into near-disaster situations?
When all is said and done, you hopefully will have a group of people who are predisposed to doing the right thing and skilled enough to go do it. The fun part is helping them do their work.
Good luck!