What kinds of questions would you ask and what scenarios would you describe, what kinds of answers would you look for?
I don't ask for specific questions. I would like to know which interview strategy is good for selecting candidates who are qualified for the job.
I ask questions in 3 categories:
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..."
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.
I often interview people for entry level positions, meaning I can't discuss meaningful work history. I usually discuss personal projects, but two questions I always ask are "Can you describe your home network to me?" and "How do you backup your home machine(s)?" A really interested person could stand at a whiteboard for 30 minutes discussing this, getting into IP addressing, wireless security, etc. A poor candidate will shrug and tell you his brother set it up.
Don't ask "trivia" questions - questions with a single, highly specific, answer. People can forget that kind of thing when under stress. If their job requires them to know which pin on a V.35 interface is used to transmit data, they can look it up when they have the job. General questions help you understand more about candidates than trivia ... We also dislike brain teasers.
The Practice of System and Network Administration
Ask different types of questions that will help you learn about the candidate. And how they will fit in with your workgroup. In the ancient days. Most SA were physicists, astronomers, mathematicians, and engineers. Why? Probably because the had excellent trouble shooting skills and took very good notes.
A few questions to ask:
Technical
Business
Personal
Most anyone can look good on paper. Some people can BS their way through technical discussions. And many people are poor public speakers. You must ask open ended questions. No "Yes or No", observe their thought processes, and their troubleshooting abilities. Most telling, are the metaphors they use to describe complex processes.
Hiring a SA is a very difficult task. It is unlikely that a technical interview will describe who you will be hiring. It's not so much what they know now. It's what they are willing to learn, and how quickly they will learn and apply it.
If I were part of an interview panel for a sysadmin at a software company where they'd be expected to keep the company's software running on their servers, I'd be interested to know what the candidate expects from developers. How do they interact with developers - "us vs them" or "all pulling together with different expertise"? Do they have any experience of a situation where development and IT (or whichever the department is called) ended up in conflict, and how was it resolved? Are they interested in getting some awareness of the technology and terminology used by the developers, and are they willing to help educate the developers in their own areas of expertise, so everyone can communicate better?
Admittedly this would partly be to satisfy my own interest in the relationship between sysadmins and developers as well as to judge the candidate.
Make sure he is not just book smart. I feel it's good to give some kind of hands on test.
I'm hiring Linux admins for a startup, so my questions are ones that should tease out experience from inexperience. Phone screen:
For the phone interview, I try to get them to talk about their previous projects, home network, how many computers they have and what they do with them, etc.
In-person, I like to give them a real problem I'm facing, and ask them to solve it for me. I'll compare their answer with whatever solution I'm already mulling over. If their answer is better, my project moves along. If their answer is worse, the interviewing process has moved along. Either way, I can keep engaged with my own projects and refine or discard candidates or ideas.
Otherwise it's talking more in-depth about what they expect out of a work environment, trying to find out if they're a 9-5er or if they actually care about what they're doing---absent other factors, Linux types tend to care (though they may suck) and network engineers tend to be 9-5ers (who also may suck)... Just my experience.
Assuming they pass all that, I also like to set them up with a new Linux box on an isolated network whose network config is wrong, with weird equipment attached and a loose cable for the final "screw you", and have them get it back online. I leave them alone and periodically come back to check on them, although I could just as easily hover if I wanted to be a hardass about it.
It typically takes about 30 minutes for someone who has made it past the rest of the interview to walk into this totally unfamiliar environment and get it working again. It's an awesome real-world test of exactly how long it takes them to troubleshoot a totally new, totally broken environment.
The "blank whiteboard" questions are the ones that really separate the sheep from the goats. "This is the network boundary; this is a web app that runs on IIS, this is your SQL backend; this is a UNIX box with another black-box service on it. How do you make this fault-tolerant, secure, etc?"
The only response I got to this from one candidate was a poleaxed "you're joking, right?"
After careful sorting the resume, I still had 20 candidates. 20 person from ~150 have passed the first selection that has allowed me to spend three-four hours for interviewing each of them. The main criteria of selection for me were:
To know about their skill to gather and solve a problem in a non-standard situation, I was asked them, for example: "How to spoil a Windows-system, if you have physical access to the computer, but don't have any account passwords?" and, after that, I asked them about "How to patch spoiled system?". I gave some virus-action examples and asked, what they would do to prevent damage and return funcionality and the lost data with as little instrumets, as possible, and more questions on non-standard instruments usage. Once, I've asked a candidate: "Which question would you ask, if you were interviewing me, to know, how good I'm with non-standard situations?" :-)
To know, how good they are in finding optimal approach, I gave them a little practice in configuring web, or mail server, or network gateway for particular parameters ("I need it to be very fast web-server for small number of clients connected to it, and yes, I want some server-side scripting language on it, to show me some statistics, what should I choose and why do you thing that is better? Could you show me on our test-server, if you've got 20 minutes left?")
The ability to training on a place - not really easy to check, but I asked some of candidates to make sample configuration file, or a script, and then, gave them a little hint to see if they could do it better after that.
The knowlege base - one of my favorite parts: What is OSI? Why TCP/IP called "protocol stack"? What computer science heroes do you know? What is Windows-registery? And what about Unix-like systems?
And very important thing - they MUST love their job! "Did you read some of the classic authors, such as K&R?", "How long you take a great interest in computer technics?", "With what you began to study computers?", "do you have test computers/little network at home?" (if it's true, that's a very good sign!).
K. Brian Kelley's list great, but I would like to emphasis that asking troubleshooting questions is important. Pick a couple difficult issues you have faced and have the candidate tell you how they would try and solve the problem. Knowing lots of technical tidbits is important, but being able to solve problems with a methodical approach is very important in my opinion.
When interviewing, I'm not really looking to see if a candidate is able to answer specific technical questions. I think it is more important that a candidate know where to go to find an answer.
A candidate shouldn't just say, "I don't know". I'm looking for an answer more along the lines of "I would Google that" or something similar to "I am a member of [ACM|SAGE|LOPSA|Server Fault] and I would check the [mailing list archives|web site] to find help answering this question".
Finding out where a candidate will turn when they do not know the answer to a question is a good way get a picture of their capabilities.
A little off topic - but an interesting story from he Official Google Blog:
Our engineers, though, tend to come by more varied, and occasionally odder, routes. Some get recruited out of grad school, or by friends or former colleagues. Others just send their resumes to jobs@google.com. For a few engineers, though, the path has been more interesting.
Please read the rest of the blog post about that unconventional, but - in my opinion - valid method to hire the right people.
I like to ask questions that are the opposite of the normal form of that same question. For example, in web development a common question is "when do you POST a form instead of GET?" But I ask the opposite: "When do you use GET instead of POST?" This forces people to think about drawbacks instead of advantages, or to consider what trade-offs they are making when they make a decision.
A representative question for IT might involve two similar technology choices; maybe a question like "When would you choose a Windows Workgroup instead of Domain?"
I always keep a pen-and-paper note of all the odd, quirky things that I come across in normal day to day work, not the sort of thing that's in the 'how to...' books. I can then call on one or two of these situations in an interview, often more to start a conversation than as a test, I'm more interested in HOW they'd deal with the situation than if they know the answer. I always ask a question regarding 'bleeding edge' tech to see if they're interested in new tech (or TOO interested in fact).
I've interviewed people both as an employee of a large company and as the owner of a small company. The number one quality that I look for is a balanced personality between 'visionary' and 'tinkerer'.
If you have too much visionary, you get a system built like Twitter. (If you haven't read any of it, half of their early descriptions of their engineering instruction will lead most admin types to do a facepalm and head for the bar.) If you have too much tinkerer, you have 200 awesome systems in various states of disrepair all over the place, and all your web sites are running on one ten year old box running BSD 4.2 under the sysadmin's desk.
Flat-out, the best person that I ever hired was a guy with a dual Bachelor's degree in Religion and Philosophy from a small private college in Connecticut. He was creative, dedicated, intelligent, and persevered in the face of adversity. He was checking in code via tethered cell phone up until an hour before his first daughter was born. He's gone on to do amazing things and is now the community leader of a major PHP framework. Great guy.
The worst person I've ever worked with was a guy who was very steeped in the organization we both worked for. His dad worked there and he'd worked there since high school. There were at least a dozen times where I almost told him that if he didn't like his job, he should just quit and save the rest of us the headache. He was a tinkerer. And co-incidentally, a huge BSD and Gentoo fan.
Other than that, any sysadmin in a *nix role should be able to describe why this is funny.
I always ask the candidate to rate themselves from 1-10 on certain aspects of the position. Then, based upon that answer, I ask questions which match the level that they placed themselves.
If the position requires use of scripting I will always ask for examples and then in a second interview give them a scenario and ask them to automate their response. I just need to be sure that their approach isn't cookie cutter.
