When it comes to IT hires, you get what you pay for

Does this sound familiar? You apply for a job, only to learn you’re overqualified for the position. In the current economic climate, it’s not so unusual to hear this refrain. On the other end of the scale, you sometimes scratch your head wondering how some people get hired at all, considering their lack of skills and experience. Welcome to my world.

At the time of this story, I was working in a 24/7 environment where we took shifts. All the techs working these shifts were senior level, though our job description didn’t have the word “senior” in it. For the most part, we all had the same skill set and experience. This was key because the work had to be carried on seamlessly, regardless of who was on duty.

[ For more IT stories, read InfoWorld’s “Stupid user tricks 7: True tales of extreme brain fail.” | Get your weekly dose of workplace shenanigans by following Off the Record on Twitter and subscribing to the Off the Record newsletter. ]

All of our shifts overlapped slightly so that the tech going off-duty could pass along whatever the tech in the next shift needed to know. Normally, most of us would try to fix issues that arose on our shift rather than let it fall on the next person. Complicated issues might take more time to fix, but those couldn’t be helped.

When a new person got hired, we braced ourselves for a learning curve and for more work to get passed on from one shift to the next. Usually after a month, a new hire was up to speed and the work settled back into a routine. Overall, we knew what to expect from each other and from the job — a plus in my book.

Trouble in paradise

Then a new manager threw a monkey wrench into our setup. A senior-level tech left for another job, and the manager hired a replacement. “Jim” had only entry-level skills, though the job description and advertisement specifically asked for a more advanced work history.

In the beginning none of us knew that Jim didn’t have much experience. He would pass on more than the usual amount of unfinished work, but we gave him the benefit of the doubt and figured he was settling in to the job.

However, after three months on the job, Jim was handing over not only a high amount of unfinished work at the end of his shift, but also surprising issues. The extra work was having a domino effect — it slowed down everyone else as we pulled Jim out of another hole. It wasn’t noticeable outside of our department, but it definitely caused frustration among our group.

In over his head

I had the shift after Jim’s, and he would sometimes turn over simple problems to me. There was the time Jim set up a new employee’s computer and left a note saying it was done except for a couple of items with email. When I looked into it, I discovered that Jim had almost established the email account for the person, which I finished as he’d requested. But he hadn’t created a user profile on the computer assigned to the new employee or a new VoIP phone and virtual machine box, all of which was standard procedure and he should have known to do.

There was another time when scan-to-email wasn’t working for a user. Jim said he’d tested it, and it came through for his email, but not the user’s. He narrowed down the problem in Outlook: The user was getting the scan-to-emails, but they ended up in her Deleted Items folder. Jim said he didn’t see any applicable rules and couldn’t figure out the problem.

I quickly exported and deleted all the user’s rules, and the user was able to get the scan-to-email items in her Inbox. Contrary to Jim’s conjecture, there was a rule moving the items into the wrong folder. It worked fine, and Jim was surprised to learn of my solution.

There were other simple details Jim didn’t know. On one occasion, he had to work with a vendor who asked him to log in using the local admin account of the machine he was diagnosing. That way, Jim could troubleshoot the issue and see if it was related to the domain admin account.

Toward the end of his shift, Jim told me he wasn’t able to log into the computer with the local admin account, a task that proved no problem for me. It turned out Jim didn’t even know he had to specify the localname/administrator to log in as the local admin.

Out of curiosity — and a lot of frustration — I decided to chat with Jim about his work history the next time our shifts overlapped. It turned out he used to be a mechanical engineer and had a few years in IT under his belt, but his experience wasn’t what we called progressive. Rather, he had mainly held various entry-level IT positions.

What was the manager thinking?

At that point I couldn’t get too upset with him — it wasn’t all his fault. But that made me wonder what the hiring manager had been thinking. Did he merely hire the candidate with the lowest-asking salary and a few years of IT experience? But Jim was a nice guy and very willing to stay after his shift to learn, so I spent the next couple of months helping him catch up.

It’s amazing how better a department can function by getting the right person with the right qualifications for a job — and how painful it can be when such is not the case. I left shortly afterward to get a position with more “normal” hours. Hopefully, by now Jim is up to speed. But I also wonder who they hired to replace me.

Correction: This blog as originally posted incorrectly identified what kind of admin account was being logged in to. The blog has been amended.

This story, “When it comes to IT hires, you get what you pay for,” was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.