Slashdot Mirror
How Do You Interview A Sysadmin Candidate?
benedict writes: "The article No Shortage of Programmers? sparked a really interesting thread about how to interview programmers. Being a systems administrator, I am curious about the Slashdot community's collective wisdom on how to interview sysadmins. I have come up with a few questions of my own to prime the pump. 'What is tcpdump? What is it good for?' 'How about truss/ktrace/strace? What are they good for?' 'What's the largest number of machines you've maintained? What have you done to make it easier on yourself (e.g. what types of automation, file distribution, etc.)' 'Do you use source code control? What for?' I would also present a couple of 'hypothetical' situations from my own experience and ask how people would approach them. How about you: what kinds of questions would you ask, what situations would you describe, what kinds of answers would you look for?"
Here is a list of some other 'inappropriate' interview questions: http://www.sunfeatures.com/inapprop.htm
I do not deploy Linux. Ever.
Don't ask them little trivia questions like "What does this utility do?". A sysadmin is more than just a person who does routine tasks every day, they have to solve new problems as they arise. You should interview a person by asking them problems and how they would solve them. Ask them about big problems they encountered in the past and their solution to them, or problems they weren't able to solve.
What you want to find is someone who is interested in what they do and can learn new things as new problems arise. You don't want someone who just memorized a book and some man pages, because what will they do if something happens that wasn't in the book they read?...
Outdoor digital photography, mostly in New Engl
People skills! Programmers can hide in their
caves and snarl when thrown their ration of caffeine and carbohydrates. Sysadmins gotta be able to smile while being asked: 1) to do the impossible, 2) Yet Another FAQ, 3) add another user, 4) restore from backup, 5) say no to some bigwig who wants the security policy violated for his/her personal whim, *) you get the idea.
Be good to your sysadmin, even if it isn't his/her day.
technical information can be learned reasonably easily but some things cannot be. when i was interviewing people i looked for people who had a genuine interest in IT too and how easily they could pick stuff up, and how well they could manage a number of concurrent tasks.
1) Tell me about the things that you have done at your last job or two. Tell me about how you got 10 different types of boxes to work together or implemented a system to do something or whatever. I don't really care if you know all the options to tcpdump by heart, you can look them up when you need them. I would much rather know why you have done the things you have done and how.
And 2) Do you have any questions about working here?
Erlang Developer and podcaster
Excellent! That's a good idea; I always hit them with an un-plugged box, just to see if they know Rule Number One: "CHECK THE PLUGS!" but a bad cable is even better.
I'm a big believer in practical exams like that. Sit the candidate down at a box, ask them to perform some simple tasks or give you some information that should be relatively easy to find. I'd rather have someone that can sit down and work with their hands on a problem than spit up textbook answers all day long. You can read up on esoteric commands and techniques all you like, but if you can't translate it into results on a screen, you're worthless. This is also a good way to see how they perform under pressure, and whether or not their afraid to look for help elsewhere. I'll take the guy who fires up the web browser and finds the answer in thirty seconds off Google a long time before the schmoe who spends ten minutes slogging through machine settings and racking his brain for it.
No relation to Happy Monkey
A few jobs back I ended up doing a lot of the sysadmin work for a good part of the company. As a joke, my boss dropped a "sysadmin" magazine on my desk one day. It turned out there was a timely article in it... The article talked about how well programming tests work in a dev organization. Some folks did a study where they applied a how _bunch_ of tests to candidates, but did not _do_ anything with the results; they just kept the data around. Two years later they looked at peer feed back, performance reviews, etc, etc, to look for "key" people and tried to find a correlation. The result was interesting: nothing for the programming test part, etc. BUT, there was a strong connection between "interesting" hobbies and key people. I.E., if you did something like gourmet cooking or sky-diving, chances were good the person would end up being cool. So, now when I interview, I always ask what peoples hobbies are. It seems to work pretty well! --stuart
We start in the cubicle and have them talk about their current and past job. The kind of things they did. The kinds of machines they worked with. The kind of environment it is.
Then, we go into the technical questions. Things they should be able to explain. Like when you use 'uptime' (or 'w'), what do the three numbers after 'load average' represent? Here. Run a command on this box and tell me how many processors it has, what speed, and how much memory. I run 'top' on a busy production box and have them describe what they see. That kind of thing.
Also, I give them a tour of the datacenter and, while we're in there, have them identify some simple things like cards. Or I'll poing to a Sun E4000 and ask them to tell me, in general terms, about the E4000 server and what it is capable of. I might ask what the difference between the E4000 and E4500 is.
Yes, I also see how they respond to questions they don't know the answer to. But a lot of what I look for is personality. How well they're going to get along with the group and others.