Reading job listings for any sort of IT job is depressing. It’s been quite some time since I’ve had to do that, but how many times have you seen something like this:

• “5 years of Java experience required.”
• “3 years of Java experience with modules X, Y, Z required.”
• “6 years of experience administering Linux machines running RHEL 4 on a Windows 2000 domain with 1500 clients in an educational setting preferred.”

I could go on and on. As a job seeker, that sort of thing is fundamentally devaluing to someone who has strengths in being adaptable and quickly learning new tools, languages, or even entire environments. As an employer, it sends a message that you’re not interested in more than a surface look at someone’s strengths, and probably don’t care to hire the best and the brightest. After all, would you turn away a rockstar programmer simply because he or she had been writing filesystem code in C the last 3 years instead of the latest whizbang Java web widget that will probably be obsolete in a year and unsupported in two? I am quite certain that there are plenty of managers that do. Even if you are a company large enough to have an entire team of people that do nothing but work on that whizbang app, don’t you still want the best you can find, realizing that some of the best people to work on that app may not have even heard of it yet? (And that when the app goes obsolete in 5 years, you’d rather not have to lay off a large team of single-skill people)

Some of you may know that I work in IT at a manufacturing company. We have a small IT team here, about seven people, and are a heavy Debian shop. And we have a vacancy open up in our development/Linux admin group. I’m the manager of that group, which is why I’m thinking about this right now.

We’re too small for single-subject specialists to make sense, yet we’re big enough to appreciate skill, experience, flexibility, and rigor. Consequently, when the occasion arises for me to look for new employees, I don’t prepare a laundry list of things we use in-house and would like experience with.

The list of almost-required things generally begins with “Linux” and ends with “experienced”, and has nothing else in between. In other words, I’d like it if I don’t have to explain to you what a symlink or a hardlink is, but I’d be willing to do so if I think you’d internalize it quickly. On the “experienced” side, it would be nice if you already have a well-developed sense of fear at running rm when you’re root, or have designed a storage infrastructure for a network before, or are paranoid about security. But again, if people can pick up those traits on the job, we are usually still interested. If learning how to package up software for Debian, fix bugs in software you’ve never seen in a language you’ve never heard of, raise good questions about things you may not have lots of experience with, and write documentation for it all on a wiki sounds like fun, then that’s probably the kind of person I want, even if you’ve never used our particular tools before.

If I were to judge based on the stuff I normally see in job postings, I guess you might conclude I’m nuts. I don’t think I am, but then again I’m also the only person I know that formats his own resume in hand-crafted LaTeX. What do you all think?

The next question is: how should one evaluate candidates given this sort of philosophy? I’m not a fan of canned tests, or even “whiteboard tests” that tend to be some sort of canned topic that may test the applicant’s specific knowledge base more than overall skill and flexibility. Similarly, as an applicant in years past, I’ve struggled with how to present the “I’ve never used $LANGUAGE, but I know I could pick it up quickly and do it very well” vibe. To certain people, that might sound like BS. To the more geeky managers, perhaps it sounds like what they want.

We’ve built a fairly diverse team on the back of this approach, and it’s worked out well for us so far. I’m interested to hear your thoughts.

Oh, and if you’d like to work for us, you should probably be sending me an email. No, I’m not going to list the address here on this blog post. If you can’t figure it out, I don’t want to hear from you <grin>