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?"

Comments

Lots of experience

[xrayspx]

I've had quite a few interviews lately, and as a Senior Admin, I'm used to giving the interviews as well. The least useful yet most common question is "What's the difference between a router, switch, and hub?". I've been asked that at almost every interview. Questions and techniques that I think might be useful are:

• Be Specific, don't say "what is DNS, what is SMTP. Ask specifically how they work, it makes you sound like a better interviewer. Ask for examples of associated software packages.
• When asking "hypothetical" questions that are based on a real problem, don't go looking for the solution that you came up with. I've been grilled on this to no end, and almost always they sit there waiting for me to tell them how THEY fixed it. I had one guy ask "If you have an NT server that reboots every 30 minutes or hour, how would you tackle it?". I told him, but it didn't look like it was the same way they did it, and he looked confused/pissed.
• In the same vein, don't expect prospects to be able to solve your real problem for you with a hypothetical situation question.
• Logic questions are bad, but might give you insight. Same problem as above though. If you go into it looking for a specific answer, you're going to be frustrated. I was just asked a logic question and spent 20 minutes giving perfectly acceptible answers before I came up with "The Answer". I got the job, so I guess it was ok, but I personally don't do well being on the spot.
• Put your candidates at ease. I SUCK at interviews, a lot of really really good geeks SUCK at interviews. Know that the person you're talking to at interview is likely not the person you will be working with. My last job I got because I was totally stone deaf, and just smiled and nodded my way through the interview. I looked more comfortable I guess.
• Ask about the relative merits of various OS', ask where and why you'd use NT, Linux, Solaris, OBSD and 2000. Ask for examples (NT is 'cheap' in that most web programmers know ASP + MSSQL, and in a load balanced farm, if you have to reboot weekly, fine. Linux is far more stable and easily configured for a billion different uses. Solaris == Available, OBSD == Security fetish, etc.)

Hope this helps some, I am so sick of interviewing, and I'd like to go back to being the interviewer. I am also however tired of being asked the same, bad, questions again and again. I guess your prospects need to remember that they're socially retarded geeks being interviewed by a socially retarded geek, and that nothing good can come of that :-)