I wanted to write a little bit on effective IT hiring techniques. But today's a busy day, so instead of a massive essay called "Strategies for Effective Hiring" you just get a Cliffs notes Jank Handy thought list. Which is probably ok since you don't have time to read a giant hiring guide. If you want a big guide, read Joel Spolsky's Guerrilla Guide to Interviewing. It has a lot of good suggestions. Ok, moving on.

Finding Candidates

There's a lot of advice on finding good candidates, and I don't have a magic, easy answer. I will say that good candidates sometimes have to be lured and convinced to join your company. Eons ago, a startup I worked for was able to eventually convince a really good DBA to come work for the company. The IT manager had worked with this guy before & knew he'd be a great asset to the company. Initially our attempts to convince the database superhero failed, as he had a nice contracting gig that he didn't want to give up. But, we didn't give up. After several months of subtle and non-annoying wooing, he finally came on board. Granted, the defining moment was when the future coworker was told by his consulting company that he'd have to start travelling or commuting more. He then contacted us and said, "Hey, tell me again about your new startup, I think I might be interested."

So does that mean you should bribe consulting companies to send their top programmers on crappy travel assignments? No. But it means a few things:

• Good candidates aren't just lurking on Monster.com, CraigsList, and other resume databases. You should ask around, tap your network, and try to come up with a list of good people that you can contact and see what their situation is.
  
• If a person isn't available, don't give up. But don't annoy them, either. :) Listen to them, and just follow up in a friendly way from time to time, letting them know how the company is doing, telling them that if their situation changes, feel free to look you up, etc. This is a basic tenet of standard networking anyhow -- keeping in touch with worthwhile people. If you used to be a programmer, you may not be into (people) networking. But you should try to change that, if you can.
  
• Be in a position to consider great candidates, and try to be a place where people might be interested in working. You never know when a good candidate will appear, so ask yourself, "If I were working somewhere else and wanting to make a move, would I want to work here?" If the answer is "no", you have a problem.

Interview Effectively

I could write a lot this, but I'll try to keep it short for now. Joel's aforementioned article has a lot of good interview tips, but I'll add my own.

Multi-level interview process

Have a multi-level interview process so that you don't spend a ton of time on candidates that aren't a good fit. The levels act as a filtering mechanism, so candidates who don't pass a level get rejected and don't continue to the other levels. 

For me, the first level was often handled by recruiters -- an in-person discussion and some technical screening questions. That filtered out 80-90% of the candidates, so that probably saved me 10-20 hours a week. Well worth the recruiter fee. If you aren't using recruiters, that's ok -- you'll probably just start with a phone screen.

Next would be a phone screen where I would ask a series of questions, talk a bit about the company, and learn more about the candidate. Phone screens were mostly technical questions, and if a candidate was doing terribly halfway through, I would usually not ask the rest of the questions and wrap up the phone screen. If you know someone's a "no," don't spend another 30 minutes. And if you hear a long pause and some clicking after you ask a tough question, you know they're looking up the answer. :) Phone screens probably filtered out another 75% of candidates.

After a successful phone screen, I'd invite candidates to come into the office. I would tell them to plan on being there 2-3 hours. The candidate would come in and meet with me for a bit, and then take a 1-2 hour written aptitude exam. I'd have them wait in the meeting room while I looked through the exam to see if they did well enough. 

If they passed the exam, I'd have them meet with several members of the existing team for 30-60 minutes.

BTW, some people prefer to do the initial screen in person, but I don't, and here's why: 

I went back & forth about meeting people in person vs phone calls for the initial technical screen. An in person meeting will give you more information about whether the person is a good fit, and eliminate the chance of them cheating during a phone screen. However, many of my phone screens ended after 15-20 minutes when it was apparent that they didn't have the knowledge we were looking for. I didn't want to invite people into the office and then send them away after 20 minutes (it seemed rude to me for some reason), and I certainly didn't want to conduct hour-long in person interviews with people that I could evaluate in 20 minutes over the phone.

Technical Screens

For technical screens (both in-person and over the phone), try to ask some open ended questions. Technical questions are good, but avoid obscure ones that even great programmers might not know but that can be easily looked up online or in a book. Ask questions that demonstrate someone has a strong grasp of concepts & fundamentals and that illustrate that they have experience with the language/platform in question. Have a few questions to see if the person is a good thinker, creative, and a problem solver -- I always liked SQL or pseudocode questions for that (e.g. write pseudocode to read a parent-child database and display a hierarchy). The questions partly depend on the level and type of position you're interviewing for.

Bad question: "What are the parameters of <obscure function> and which ones are optional?"

Good questions: "What are some methods to improve the performance of a data-driven web site?" "What is database normalization and what are some pros and cons about it?" "How can you implement caching in ASP.NET?" "In HTTP, what is GET and POST?" "Tell me about your experience with AJAX."

Then listen to their answers -- you'll know how deep their knowledge is based on how detailed and thorough their answers are. You can ask follow up questions if you want. For example, you might ask someone "What is ViewState in ASP.NET?" If they have a good response, you could then follow up with "What are some pros and cons about ViewState?" or "How can you develop an application without using ViewState, and what are some pros & cons to that?"

Have a written set of questions that you can print out when you interview candidates. The document should have fields at the top for job title, candidate name, time and date, and a yes/no decision. Then below can be a list of questions with space below to write down the candidates answers. During the screen, you can ask the questions and jot down their responses (or indicate their lack of response). At the end of the screen, go through the questions and "grade" each one. How you grade is up to you: it could just be Yes or No, or a point system, or grade school like A, B, C, D, E, F. Then go through, and make your decision on a candidate. Try to make the decision right there, and stick with it. The printed sheet is also good because it gives you a written record of the interview results in case your company gets sued later, or in case you're asked why you didn't hire Mr So-and-So, or if you encounter the candidate again in 6 months and wanted to remind yourself why you passed on them before.

Over time, you'll be adjusting your screening questions as you come up with better questions, or realize some questions suck, or that you never end up asking them. Another suggestion is to ask some of your existing staff the questions, and get their opinions on whether the questions are good. If none of your staff can answer a particular question, then that means either your questions aren't very good, or ...

In general, try to involve your staff -- they're a good resource and sounding board for you, they'll (often) appreciate being involved in the process (since they'll have to work with whomever you hire), and it's good training for them if they'll eventually become managers. Some staff won't be interested, and that's ok.

Have your team meet candidates

Your team should interview candidates, too. After the interviewing is done, meet with the candidate a bit more & send them home, then meet with your staff right away and get their feedback. Getting feedback immediately is important because the sooner you get it, the better quality it'll be. And you need to get their feedback anyhow, because if you don't, then you're wasting your staff's time.

Sell Your Company

During the interview process, you should try to talk a bit about what it's like to work at your company and why it's a good place to work. Give them a little walking tour. Think of ways to make your company worth working at, because it'll make your current staff happier, it'll make it easier to attract good candidates, and even candidates that don't get hired (for whatever reason) might come back to you later or tell others about your company.

No company is perfect though, but don't lie to candidates. There's no reason to go on & on about the company's downsides, but I think being honest is important. You establish yourself as someone trustworthy. You also filter out people who would be a bad fit. E.g. if you lie & tell people that the team never works weekends, even though they do, then if someone comes to work for you that really can't accommodate weekend work, they'll probably be grumpy, quit later, waste everyone's time, and tell all their friends what a lying jerk you are. Or you'll be forced to live up to your lie & not make them work weekends, whereupon your current staff will say "hey how come New Guy doesn't work weekends but we do?"

Ah, lies and the web they weave.

Make a Decision

I don't agree with Joel's "if you have any doubts, don't hire the person." I wish I could, but I don't think it's practical for every company, when sometimes you're struggling to even find decent candidates, let alone great ones. I think it's a goal to aspire to, but perfect candidates are often hard to find, and sometimes you need to take a few days to decide on a candidate (or decide between a few good candidates). That having been said, if you know someone's no good, don't hire them. Don't ever be tempted to hire someone you don't like "just to get someone in the door."

And even though HR people will tell me it's a bad idea, I like to get back to candidates and let them know if they haven't been selected. I know the convention is sometimes to just blow people off, but that's rude IMO. I try not to go into specific details, because that can be a legal issue, although if someone's experience is clearly and severely lacking, I say so. Anyhow, candidates appreciate at least being told, "thanks for interviewing, it's not the right fit right now, but we'll keep you on file for openings down the road." It's about respect and honesty, which will help you in the future. People remember that you were one of the few hiring managers that was up front with them, and that your company was the place that employed people like you. And it's good karma.

If the candidate was good but just lacking in experience, I might say something like "you don't really have the experience we need, but keep us in mind and get back to us in a year or two, or if you get a chance to take some training."

Move Quickly!

Wow, did I say this post was going to be short? Anyhow, this is a very important point. If you find a candidate that you want, start them as soon as you possibly can! See, I even bolded that. Ask them when they can start. If they can start right away, get them in the next day, especially if they're good and interviewing with other companies. Have them come in and shadow another team member for a bit, or install a wiki and enter documentation into it, or do research, or something -- just get them in. And get them an offer in writing ASAP. If they're still working, see if they can swing in after work or for an afternoon even, just something to get their feet in the door. Something to physically establish that they are your future employee.

Why get them in right away? Because otherwise they might take another offer between the time they accept your offer and their official "start" time.

I lost several great candidates by not following this rule. I made offers, they accepted, and we set a start date of 2-3 weeks out. But since they were still interviewing, they ended up going with other jobs, or being talked out of the job. A common excuse was "my wife/husband doesn't like <insert random point about your company or the job> so I can't accept the job, sorry." Yes, I know they "accepted" the offer, and it's kinda lame of them to back out. But it happens, and you need to make sure it doesn't happen to you. If they're still working, it's less likely to happen, but it still might.

BTW, it's my belief that the "my spouse doesn't approve" excuse isn't always true (maybe 50/50), but people feel they need to give some sort of explanation on why they changed their mind, and saying someone else vetoed their decision means that hey, they would have kept their acceptance of your offer, but since their better half said no...

Final Thoughts

Ok, I need to wrap this post up. I meant for this to be a quick post, but I guess I just had a lot to say.

So...hiring people is a lot of work, but it's arguably your most vital function as a manager. The more effort you put into finding good people, the happier you'll be.