In our IT Manager Republic Net Note, I recently asked whether any IT managers had experienced any hiring nightmares when staffing their IT organizations.

As a former manager myself, I knew the question would strike a nerve. Even after you extricate yourself from the mess caused by a poor hire, the memories never leave. And we’ve all been there, from the programmer who blows you away in the interview with her knowledge and charm but who, once on the job, doesn’t even know how to do the most basic of tasks, to the help desk tech who seems so astute in the interview but whose on-the-job social skills lead you to believe he was raised in a cave somewhere.

In response to my question, member Adrienne DeMaster submitted the following hiring horror story. Adrienne is a former IS manager for a small company in Small Town, USA. Other names have been changed to protect the incompetent. Here’s Adrienne’s story:

The background
The cast of our tale includes one overloaded manager doing programming, managing IT, managing a subcontractor or two, and just for kicks, co-managing an ISO 9000 implementation (me). There’s also one very busy systems admin who is working a punishing 60- to 70-hour week.

The good news…
Upper management decides we need some help and says I can hire a programmer (aka database developer) who can take a project and run with it from start to finish. We’re looking for someone who doesn’t need a lot of supervision, can deal successfully with end users, and can make sure management knows what resources are needed to complete projects on time. Oh, and by the way, this person also needs programming skills.

The IT group (all two of us) comes up with a job description and a set of questions for the interviews. The questions are designed to tell us what programming skills and experience the interviewees have, if they are a cultural fit for our company, and whether they have the independence and initiative to manage their own projects with minimal oversight. They are similar to questions we’ve used in the past—open-ended and worded so the interviewee needs to use examples of past work to give us some real answers, not just fluff.

Things aren’t looking good; qualified candidates are scarce. The few interviews we grant are lackluster and clearly don’t fit the bill. Finally Mr. Wright applies; Horatio Wright, that is. Horatio easily moves through our questions, with plenty of examples of previous work, some of it based on “we” did this, and some on “I” did that, so we’re thinking this guy is a team player who can work on his own, as well.

He has the right skill set, so we schedule a second interview that involves having him sit down at a computer to actually demonstrate what he can do. After looking at some information, he tells me how he would construct a report from it, and he is at ease using the tools of the trade. He also seems to have satisfactory answers as to why he’s moved through several jobs in the last few years, including a job with our direct competitor, which means he must know something about the way our business works. I tell my boss to pay him whatever it takes to get him in here; I think he is the one.

The bad news…
Things start out fine. Horatio shows up for work on time, is charming and impatient to get to work. And knowing the tools, he knocks off a few quick reports and other urgent programming fixes. We lay out the groundwork for the first big project: constructing and integrating a module into the current database.

Part of the assignment means that he needs to interact with a team of end users and managers so he can determine the specs for his work. We haven’t laid out a specification for this project yet, and nobody else has time to do this for him. After several weeks of meetings and one-to-one work with the group, we still don’t have a specification, but Horatio is building a prototype. He spends a lot of time working on how we could get data to the interface, even though that was something that had already been determined. Then he became preoccupied with what the interface should look like.

Color scheme seems to take a priority in the discussions that keep cropping up, even though it was not even a consideration in the unofficial specs we finally agreed on, because nobody else cares about color scheme. It seems Horatio doesn’t like the visual style that has been adopted for the project. The next issue is working on an existing data structure; no one particularly likes dealing with legacy data, but Horatio seems to think that he’s being punished with bad data.

At the six-month review point, I am desperately looking for a way to get things back on track. The big project is going nowhere, and by this time, I am realizing how little of the big picture is sinking in for Horatio (next to none). Turns out Mr. Wright has some great programming skills but is largely limited to working from a spec sheet with defined data sources. His lunch hours are getting a little long, and there seems to be plenty of time to talk to other employees but not for sitting at a workstation.

We pull back, carefully define a different short-term project (design and build a small, single-use database to collect sampling information) that should take no more than a couple of weeks at the longest. I am thinking that we can relieve some of the stress of the major project, get a “win” under Horatio’s belt, and then refocus when the small project is done (and when my major commitment in another area is relaxed, as well).

Six weeks later, looking at the small project, I realize it will never get off the ground without a total rewrite. The data structure Horatio designed was just plain odd. And efforts to reorganize and get the major project back on track were flagging. So when Horatio comes in with his resignation (he’s found a new job that pays more), my boss and I are both biting our tongues to keep from cheering.

Lessons learned
Looking back, I certainly would have done some things differently over the course of Horatio’s employment. The experience caused me to change the hiring process I used so I would never have a repeat experience. My take-home lessons are:

Skills are important, but they’re not the first consideration in the hiring process. Ever. The concept of “cultural fit” isn’t particularly popular right now, but it’s still the biggest consideration on my list. Most interviewees are going to try to tell you what you want to hear, so make sure that you’ve considered what qualities an employee needs to fit the job, then interview for those qualities without first indicating what you want to hear the interviewee saying. Get a true sense of whether the person will fit in with the way your company works, and then look at whether the interviewee’s skill set is close enough to make a good fit.

Design your questions so you can ask for as many specific examples as you can. Dig deep enough to find out who did what work in a project or situation. To some interviewees, having seen it done seems to qualify for having done it. Even a smooth talker like Horatio will hesitate about saying he can do it all.

After you’ve finished asking questions, be brutally honest with the candidate about what the job entails. This could be the biggest favor you could do for yourself. You might scare some candidates off, but it’ll save you some heartache in the long run.