How to interview a sysadmin candidate? [closed]

Solution 1:

I ask questions in 3 categories:

• Technical Knowledge - I want to make sure the candidate knows what he/she is supposed to know. For instance, tell me the difference between RAID 0, RAID 1, RAID 5, RAID 1+0, and RAID 0+1. If an AD Directory Services administrator, tell me the forest and domain level FSMO roles and what do they each do. In addition, this is where I ask what technology they are interested in. Do they build robots on the side? Good! Do they program said robots? Really? So I've got someone who can do a bit of coding and knows the pains of troubleshooting. Outstanding! Things like that.
• Personality - I ask questions about how they would handle different scenarios. Situations like, "The PM realizes there has been an error made in the schedule. You know the error is the PM's fault. That error is going to cause you to work two weekends back to back. How do you handle it?" Basically questions that reveal how the candidate thinks and whether or not they know what to do to be part of a team. This won't weed out the folks who know the right answers and don't do them, but it will weed out the folks who have no idea how to play nicely with others. I also ask questions about community involvement.
• Previous Experience - I usually ask for the candidate to give me a situation or project in the past that went well where they were a major part. I want to know what challenges they faced and how they handled them. I also ask to give me a situation where things didn't go well. What were the lessons that candidate learned? What could the candidate have done, thinking in hindsight, to possibly turn around the situation (and if the candidate couldn't, does the candidate recognize that).

Solution 2:

This answer covers the three major areas that need to be investigated. However, one thing that needs to be allowed for, particularly in smaller shops where infrastructure people are expected to be multi-disciplined, is to ask technical questions that are very broad in scope, and that can be answered at different layers of abstraction depending on the candidate's expertise. This allows you to get a feel for what each is capable of, and lets them demonstrate their specific expertise, while still allowing you to directly compare different candidates' answers.

A great question that I once got asked is:

Imagine I've logged you on to a machine here and brought up a terminal. You type wget http://www.google.com/. What happens?

I, with my networking bias, answered starting with the DNS resolution, moving on to proxy configuration, and then on to the routing decision and establishment of a TCP connection; another candidate answered in terms of the HTTP conversation. When I asked the interviewer what the best answer he'd heard was, his response was:

"Well, it started with the keyboard interrupt..."

Solution 3:

Technical questions are important, and the method of answering is almost as important as having the correct answer. (the last thing the IT dept needs is someone sabotaging its goodwill throughout the organization with hostility and condescension).

But here's my most important question -

My first interview with a "real" IT firm ended when I he got to a technical question that I answered with, "I don't know."

The response was: "Great, when can you start?"

I was fresh out of college, and my interviewer wanted to know that I was capable of recognizing the limits of my knowledge/experience. It's something I've kept with me, and I think it's the single most important attribute for a sysadmin. Specific knowledge is great, and will give you a leg up, but if you can't admit to not knowing, you're going to progress very slowly, if at all.