How To Hire A Sysadmin, Part I   5 comments

There’s lots of lists out there for “interview questions” to ask IT people when you are interviewing them for a new position.  Many of those lists are pretty worthless in practice, as they actually ask the sorts of questions to which you can find the answers with 60 seconds and a web browser, but they don’t ask the sort of questions that actually tell you anything about the candidate’s capability to understand complex system design.

I really don’t need to know if you’ve memorized the IPv4 header (this is the networking equivalent of memorizing Pi to 40 digits).  I don’t really need to know if you know the difference between the HKEY_CURRENT_CONFIG and HKEY_LOCAL_MACHINE registry hives on a Windows machine, or what the difference is between GRUB and LILO, or what your opinion is of the advantage of the FreeBSD ports collection vs. Linux’s RPMs.  I *really* don’t need to see your Perl coding skills, because if you’re a really good Perl coder you should be writing code, not administering systems.  Not to mention the fact that if you’re administering a lot of systems with home-grown Perl code I probably don’t want to hire you because after 6 months the only person who will have a freaking clue about how the cluster works is the guy who wrote all the tools from scratch in Perl.

What I need to know is if you understand, at a meta-level, what a sysadmin is supposed to do.  You can learn syntax over time (or ask the magic Internet machine).  Learning how to juggle interdependencies is something else.  In fact, quite often those people who are really skilled at syntax (read: recent certification acquisitions) can sound like they really know what they’re doing, without knowing anything about what they *ought* to be doing.

So, I have only two questions for a sysadmin candidate.  Here’s the first one:

“You have a cluster of 300 machines, running 40 different services, on three discrete networks, with two OS-level dependencies. Assuming you’ve built this cluster yourself from scratch with no legacy dependencies, describe this cluster. Feel free to ask as many questions as you like for clarification. Go.”

This is meta-level information mining.  A good sysadmin will spend more time asking questions about what the cluster is supposed to be doing, what sort of services are running, what’s the uptime requirements, who the users are, and what the business continuity requirements look like than they will talking about their design ideas.  A good sysadmin will have a thousand questions.  Note, you have to be able to provide at least theoretical answers to these questions in order to interview a candidate this way.  Second note, if you can’t interview someone this way, you probably should not be involved in the decision making process for new IT hires.

A *really* good sysadmin will ask questions about the physical facility, budgeting, and office politics, not just technology.  They’re going to want to know if they’re going to be able to fix things based upon technological merit, or if there’s a labrynthine approval process that goes through someone who has no technical expertise but absolute veto power over technology decisions… but if you get someone like this in an interview, be forewarned that you’re either hiring someone who will replace your IT manager within 6 months, or someone who will need some other sort of upward mobility within 18 months or they’re going to get bored and go elsewhere.  The price of hiring really great people is that you need to give them really high level work.

We’ll talk about question #2 in the next post.

Advertisements

Posted October 19, 2009 by padraic2112 in management, tech

5 responses to “How To Hire A Sysadmin, Part I

Subscribe to comments with RSS.

  1. Pat-

    I have the luxury of mostly hiring entry-level folks these days, but I have successfully applied a lot of the logic you use. A couple of points upon which to expound:

    1) You might consider basing your first question on the actuality of your current situation, rather than a theoretical test case. i.e. “We have the set of: current business requirements, budget, infrastructure, management philosophy, personality issues, constraints, etc.- How would you manage them?” This has a couple of advantages. One, the prospective employee gets a much better sense of the projects that he’d be dealing with (and if he isn’t a good fit you can find out sooner), two, you don’t have to worry about keeping track of all the details of your theoretical test case, and three, you just might pick up a useful suggestion in the process. Sure, you don’t want to expose anything inappropriate (ex.: “How would you address the problem of being so far out of HIPAA compliance that your IT management is worried about jail time?”), but there are quite a lot of problems that are reasonably safe to discuss.

    2) When I hire someone, I’m thinking about their promotion potential on their first day. I don’t want the kind of person who will have zero ambition and will work the same job for 10 years. I’d rather have a fire-eater who is a pain to manage and whom I’ll have to replace within a year or two, because those people are going to give me the best results. Yes, as a result I go through interviews several times a year, but so far this strategy has paid high dividends. In fact, I just finished getting one of my team promoted to the development side. 🙂

  2. I’ve thought about your #1 point, and the only flip side to it is that you’re going to be prejudiced as to the answers. This isn’t necessarily a problem if you can control for it. It also pre-channels the conversation into one direction, whereas an entirely theoretical cluster gives you the ability to think outside your own box. In and of itself, though, I think that’s an entirely suitable alternative approach.

    On the second point, there are reasons not to pick fire-eaters (although given a choice, I agree I’d probably pick ’em over the alternative). Zero ambition people are scary, because they usually have zero risk tolerance and that’s not an okay proposition for a sysadmin. On the other hand, some people have very little ambition in the here and now for perfectly justifiable reasons. If your wife is expecting twins in three months, I’d be a little worried about your long term stability if you were the type who *was* uber-gung ho. Someone who wants to work 40 reasonable hours and have flex time capabilities because they’re expecting to have a rough first year with newborns isn’t necessarily a bad hire 🙂

  3. Hi!

    I wrote a column on my recent experiences hiring a sysadmin that you might find interesting:
    http://www.simple-talk.com/sysadmin/general/hiring-system-administrators/

    My view was less technical than yours, but I think they work well in concert.

  4. Do you need just a normal “Admin” I make a good cup of coffee and I don’t mind buying flowers for your wife on your behalf. I type 90 words a minute and can turn techspeak into plain English. If you weren’t in the US, I’d be seriously lobbying for a PA job at yours!

  5. You earned my respect over at Science and Ethics, and this post has earned my unequivocal love. I say this as an IT manager with no flunkies (so a sysadmin with a bigger title).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: