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>
> 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
Not that I planned on applying or anything, but curiosity compels me to ask – was the right answer to whois complete.org and email 1ef4ddc18bd53b245bebe092e4693ea5-127819@contact.gandi.net?
Well, that’s one answer, or at least is for a few hours… Easier ones abound ;-)
Your offer looks really interesting … Would you hire somebody from Europe :) ?
I’d consider anyone, though I’ll say that we haven’t yet hired anybody on a 100% telecommuting basis, but wouldn’t exclude that at the outset.
gwern, overcomplicated. Fail :)
Usually I find it would be better to describe in the job posting the job that the new person will be expected to do – what is the structure of the environment, complexity of the tasks, how specific are the day to day tasks and how much the person would be asked to manage themselves. If you can describe it as closely as you can to the technical nitty gritty, the more likely you are to attract technical people.
Then on the interview I find it useful to ask about previous technical jobs (and hobby projects) – what the person did, what was the environment, what technologies were used (by him/her) and how. Typically that easily shows you the level of the knowledge of the person and their overall technical mindset.
If you are not the sort of person who can figure that out I hear it is pretty useful to give people puzzle type tasks to solve either in the programming language you are targeting or in a meta language.
I learned from a job posting back in 2005 that getting into the nitty gritty on the technical stuff has a way of becoming obsolete quickly. Part of my problem as a hiring manager is that I really don’t know what the person will be asked to do in a year. I can generally offer what I think we’ve been doing, but we’re surprisingly agile for a company as big as we are and predicting what will come is hard. I have decent visibility into the next 12 months now. So I can give an idea of the sorts of things we do, but lots of detail is probably going to be inaccurate over the long term.
If you’re really okay with somone having programming experience in general, and not necessarily with your in-house preference, then you can say that in the job listing, like:
“5 years experience in a high-level programming language such as Python (preferred) or perl, ruby, etc”.
Also, a lot of people use the “required skills” section of a job posting to list not only required skills, but also to convey what the job responsibilities are. I think that’s why you often see a laundry list of “required skills” that you know do not all exist in one person. That’s why I think the “required skills” section really should just be “required skills” like “strong Linux familiarity”. But then in a separate section, “job responsibilities”, you talk about what they’d actually have to be in charge of.
As far as screening people in person, I like to invent scenarios and talk them through it. I’m far, far more interested in their thought process and how they’d go about handling a situation than I am with them getting the exact “right” answer, if there even is one.
Then when you get some resumes and
Solid suggestions, and I agree.
> but then again I’m also the only person I know that formats his own resume in hand-crafted LaTeX
Actually, I do so too; and though I’ve not actually seen it, I’d be extremely surprised if my business partner’s resume was done in anything but LaTeX. I think you’ll find that there are many Linux geeks who format their resumes in LaTeX :-)
As to “how do you employ people”, well, that depends. For instance, having gone partway through it once, I can’t say I’m very fond of the Google approach to hiring people. Personally, I’ve only ever worked for people who would look at my resume, and understand that I have the skill to learn by just doing stuff. If people wouldn’t believe that, or wouldn’t work for me, I didn’t want to work for them. But maybe that’s just me.
I think what you are looking for isn’t a particular skill; it’s an attitude. For some kind of jobs, several years of experience really is a requirement; for instance, you wouldn’t want to give the job of “someone to decide how we’re going to write this million-dollar application in Java” to someone who’s never done any Java. In that case, requiring several years of experience in Java might make sense, even if putting a certain number of years to that doesn’t. But if you’re just looking for someone with the interest and ability to learn, then that’s what your job posting should say — and perhaps it might add that having these or those skills is an advantage.
You make a reasonably strong case for one situation in which having experience in a given language is valuable, and there’s another one below (a specific project in mind that’s already late). I still maintain that these aren’t great long-term strategies.
To play devil’s advocate on your scenario: what if, when I wantted a lead for a multimillion dollar Java project, I want a computer scientist or software engineer with a strong background in OOP, wide language experience, and hands-on work rather than someone that’s just been around the block with Java for a few years? If they knew Smalltalk and had worked with Lisp and C++ I’d consider that a plus, even if they won’t use those languages with the project. If you’re doing architecture work, there are a lot of principles that carry over from one language to the next. Not everything, of course; but for some of those things (JBoss? Tomcat? etc) you may need to look to the team. Somebody who recognizes the patterns that lead to spaghetti code, unintended consequences, and API paralysis may be more valuable at that level than someone who can pick from middleware toolkits.
As a person who conducts several phone and face to face interviews for unix sysadmin and DBA positions per week, I really agree with Dan. The most important part of an interview is scenarios. “You’re on call and get an angry user with this error, take it from here”, “what would you expect you need to do to install X amount of servers”, “based on what you know about what we do, design us (part of our infrastructure|database|network)”. The thinking process is what really matters. Your skillset will never be a 100% match with what we want, but a good candidate will show talent to learn the missing bits.
These questions really sort the wheat from the chaff. Combined with proper CV screening and interciews by people from different backgrounds (and thus asking questions from different angles), we’ve managed to gather a diverse but very talented group of people. (Oh and yes, still hiring :))
(And spelling your own name correctly is apparently not a requirement :))
The resumes-in-latex bit is interesting. I come across them occasionally and not surprisingly, those candidates are almost always far above average quality.
CAPTCHA: Employment tofish (Is recaptcha intelligent?)
Haha, wow. I’ve never known it to be but that is a fun coincidence.
Hm, based on the resume format remarks in the post and in Dennis’s reply, I wonder what the effect would be if the job ad included the requirement that resumes be submitted in a format that neither Microsoft Office nor Adobe Acrobat can generate.
The set of applicants who would not get discouraged by this and who would manage to submit a resume in an acceptable format would probably have an above-average match with your criteria, similar to what Dennis has noticed.
This discriminates (slightly) against those of us that don’t use MS Office or Acrobat at all, and don’t know what formats they can produce.
Hiring for IT jobs is an interesting problem. Joel Spolsky thinks he’s solved it with Stack Overflow Careers: http://www.joelonsoftware.com/items/2009/11/05.html Basically, the idea for a job-seeker is to let your Stack Overflow reputation and answers do (a lot of) the talking for you.
Oh, and I used to manage my resume in LaTeX but have since switched to reStructuredText with Git branches for different types of work. Thinking of switching to Org-mode :-)
Having sat on a few open interview sessions, I’ve seen some of the brain damage that discounts learning:
1. Bob left for greener pastures, and his project was already late! The new developer will also be interrupting people asking questions and generally counterproductive for months. From this angle, hiring a ‘learner’ candidate for a late project due in two months is a deal breaker. We all know what adding people does, even if Bob isn’t the only developer. There’s a lot of ‘history’ behind why the code is different than what your new hire is expecting, and while Bob knew all that and could fix five bugs a day, the new hire can’t and won’t. We all know this project is late period, but managers seem to be promoted to their highest level of optimism.
2. We’re obligated to seek multiple candidates, but between you and me this job is yours, Smith. Get your resume ready by tomorrow. More common among certain H1-B visa employers, but some adjunct faculty at my last job felt most tenure track positions were similarly corrupt. But unless you write the position to match the candidate, there’s no way you can effectively promote these groups.
Personally, I think the first argument is more true for developers than sysadmins, and the second might be a dysfunction particular to government work.
My most painful experience in LaTeX was writing my resume, and I’ve got nearly 20 years experience with it. In retrospect, it would have been almost trivial to do in plain TeX, because, unlike LaTeX, you have complete control over everything. But, then, I’m a bit of a perfectionist when it comes to typesetting :)
Hehehe, I’m in the exact same situation now. I lead a team of three now, but I’m needing another to cover for me in a long-drawn project (while I get back closer to home and review the infrastructure for improvements.) I agree, walking potentials through scenarios to find their thought process sounds like a great idea for screening.
An interesting job ad I once saw from a Swiss ISP basically asked for an SSH key in lieu of a resumé. Presumably, people who solved the online test would get invited to an interview.
My present employer does the traditional CV-sorting first, but once candidates arrive they get placed in front of a computer and told to do stuff… e.g. write a script to do a task. In the language of their choice, of course…
– Another guy with a LaTeX resume
I’m terrified to run rm at all, let alone root. I alias rm to rm -i, though sometimes the rm -rf comes out a little too easily. :-/
Often I have considered how I would hire programmers for making iPhone Apps. Most companies get flooded with responses in the first few hours on craigslist. Thus they filter all those responses.
break in periods are desirable for those people your unsure of. Use a Contracting firm, Temp to Hire. Break in period can be as short as two months, or as long as 6 months. This depends on the complexities of the environment.
As you said, earlier on, your employees will have to wear multiple hats.. I think for most System Administrators, this is expected.
There is always general knowledge testing, companies may require as well. This has nothing to do with testing laziness of a potential employee. Brainbench may be a good source for testing as its inexpensive, and seems to have a good foundation for testing. I took and passed the Linux Systems Admin in 2006. The questions were straight forward, for the seasoned, and varied for multiple linux flavors.
So for hiring, a few tests may give you a good benchmark on capabilities, so perhaps only new concepts and learning would be the break in period, plus how they integrate with the team, how effective with their time, go getter etc. If a new employee can commit 70% of their time to work, that is a good employee. Anything more is gravy.