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.

  • 6
    Should maybe be Community Wiki?
    – Sam Cogan
    May 2, 2009 at 21:01
  • I don't think this should be community. This should not be a long list of questions or tips. And it's not a poll. There are already some good answers which deserve the upvotes.
    – splattne
    Jun 16, 2009 at 14:52
  • 2
    There isn't any "right" answer to this, which is almost the definition of a community wiki page.
    – Bill Weiss
    Jun 22, 2009 at 16:58
  • Why shouldn't there be any right answer? There are already some answer which are perfectly right.
    – splattne
    Jun 22, 2009 at 17:13
  • 1
    I know this is old, but as it has resurfaced... There can't be a "right" answer for the simple reason that there is no one System Administrator job. Different situations call for completely different questions, answers and even attitude. The right answer for a small company is not going to be the right answer for an ISP or large corporation. Jan 6, 2011 at 23:51

17 Answers 17


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).

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

  • This is a good one, adding it to my list.
    – jj33
    May 3, 2009 at 1:20
  • 2
    What about debouncing the keypress first? May 6, 2009 at 16:51
  • I've asked the google question but with a browser rather than wget. No real right answer, but it's great for pinning down where people's skill are. It can also help show who actually has an interest in computing, science and how things work rather than just being able to read a book and pass a vendor exam. You can get some quite long discussions and as an interviewer you can also learn something new.
    – goo
    Jun 13, 2009 at 13:22
  • 24
    "Nothing, you have to press <enter> to make it do anything." :) Jun 16, 2009 at 15:18
  • I know it's a little late for a comment, but Murali, it wasn't me interviewing you, was it? That's my standard question in technical grillings.
    – MadHatter
    Feb 1, 2011 at 16:37

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.

  • 1
    This happened to me as well.
    – ninegrid
    May 6, 2009 at 14:10
  • 4
    I work part-time as a sysadmin, and my boss values integrity over everything else. It's not just knowing your limits, but admitting to them instead of BSing your way through.
    – Magus
    May 7, 2009 at 14:49
  • 3
    @Magus - Great point that I failed to point out very well. People who blather and lie their way through mistakes are just toxic. May 8, 2009 at 12:01
  • 1
    I like to ask questions when I interview, where "I don't know is an appropriate answer". I like it even better when they say, but this is where I would start looking/do next.
    – geoffc
    Jun 22, 2009 at 16:11
  • 4
    Generally my "I don't know's" are followed by "This is how I'd find out". Dec 6, 2009 at 20:51

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.

  • 5
    +1 for questions for people with little experiences
    – blank3
    Dec 1, 2009 at 15:57

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:


  • Describe to me, as if I knew nothing, how a TCP/IP network works.
  • Describe to me, as if I knew nothing how a computer works (a basic Von-Neumann device)
  • Draw me a simple network diagram: You have 20 systems, 1 router, 5 switches, 2 servers, and a small IP block. Go.
  • Based on the job posting, what do you expect to be doing here?
  • Describe to me what you hope to accomplish here.
  • What is the best method to keep documentation up-to-date?
  • What's the worst disaster recovery incident you have ever been involved in? Tell me what you did.
  • Why do you like being a SA?
  • How would you rate yourself as a SA?


  • Do you believe that IT drives business or that business drives IT?
  • What do you think about our current business model?
  • What could you do to make us more profitable?
  • How does IT interface with our company?


  • What's your favorite joke?
  • What book should I read tomorrow? Why? (then go to the library and skim it)
  • Who is Thomas Limoncelli? (heh heh, GOTCHA!)

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.

  • Why the gotcha after asking who Thomas Limoncelli is? Don't people know he wrote the book on time management (for SAs)? Jan 1, 2011 at 0:46
  • An attempt at humor, given the quote I lead the answer off with, and the final attempt at a trivia question during the interview. May 12, 2012 at 0:42

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.

  • Well, this does put the hiring process in check. If a person not able to cope with such a workload was hired.
    – Tim Post
    May 2, 2009 at 21:24
  • @JamesBarnett: Why are you asking me rather than the person whose answer actually mentioned Thomas Limoncelli?
    – Jon Skeet
    Dec 31, 2010 at 9:24
  • Because I put the comment on the wrong answer. Jan 1, 2011 at 0:46

Make sure he is not just book smart. I feel it's good to give some kind of hands on test.

  • 1
    Yes, I've know alot of people who have studied, passed reams of exams, look great on paper, but put them in a real life situation, with users to deal with and they crumble
    – Sam Cogan
    May 2, 2009 at 21:00
  • 3
    Works the other way around too.
    – Bart S.
    May 4, 2009 at 14:53
  • True. I wouldn't want to work for a company that hired people just based on a resume.
    – Kredns
    May 4, 2009 at 20:22

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

  • That's a great question, assuming you keep the candidate from going down too many rabbit holes.
    – Bill Weiss
    Jun 22, 2009 at 16:56
  • I would start by pointing out that I've see a 700 page instruction manual for "securing" MS NT servers which is freely available from some branch of the U.S. federal government (NIST?, Dept. of the Navy? ... don't remember off the top of my head). Then I would point out that we've all read at least one headline in the mainstream media telling us how effective that set of instructions have been for them. From there I'd discuss setting reasonable expectations and isolating exposure (air gap between SQL "backend" and public facing IIS, for example).
    – Jim Dennis
    Jun 30, 2011 at 2:30
  • 1
    @JimDennis I think that was the NSA; they have a large number of such manuals. Oct 6, 2012 at 3:04

I'm hiring Linux admins for a startup, so my questions are ones that should tease out experience from inexperience. Phone screen:

  1. Name as many top-level directories in a modern linux system (FHS) as you can (there are about 20, nobody gets more than 75%, even those who deal with it every day)?
  2. What is the PATH environment variable used for?
  3. Name a person famous for their involvement with open-source/free software (other than Linus Torvalds) (most frequent response: Richard Stallman)

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.

  • 2
    Pain in the ass grammar point: for "on an isolated network who's network config is wrong," substitute "whose."
    – Telemachus
    Jun 13, 2009 at 13:34
  • 2
    My linux box has ~14 directories in / . What has 20?
    – Bill Weiss
    Jun 22, 2009 at 16:23
  • There are 16 in the FHS; lost+found on ext3, proc, sys, selinux, and tftpboot/
    – James Cape
    Jun 25, 2009 at 2:12
  • Personally I think it's pointless to ask about the directories one should expect to find under root of a filesystem. It happens to be the sort of question that I'm pretty good at but I think it has essentially no predictive value on how well someone would perform as a sysadmin. Better would be questions like: "Where would you look for files installed by something like Oracle or some other commercial package? (somewhere under /opt) ... some free utility installed from source code by one of the other SAs? (/usr/local). Those at least reveal familiarity with common conventions.
    – Jim Dennis
    Jun 30, 2011 at 2:13
  • @Jim Dennis, It's a trivia question, designed to be asked by a secretary or HR person before they waste my time scheduling an interview. Those who know Linux from experience will answer correctly, those who do not will fail and their resume goes in the trash.
    – James Cape
    Jun 30, 2011 at 4:27

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:

  • ability to training on a place
  • skill to choose the optimum approach
  • skill to gather and solve a problem in a non-standard situation
  • a good knowledge base: that means, the candidate should know the history of computer technics, possess the theory at a high level, knowing not only "what to do", but also to know "why".

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!).

  • "How to spoil a Windows-system, if you have physical access to the computer, but don't have any account passwords?". Easy. DBAN.
    – phuzion
    Jul 6, 2009 at 15:43
  • phuzion: and if you don't have BIOS password and need to make it unnoticed, that you've ever touched the system? When you can't ever boot from cd/floppy/etc? Jul 19, 2009 at 6:16
  • My initial answer: open the case, drag my keys across the motherboard. Sep 14, 2009 at 20:43

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.


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).


A little off topic - but an interesting story from he Official Google Blog:

How I got to Google (Ch. 1)

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.


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.

  • I agree with this! Being new in the world of Sys Admin-ery I don't know a lot of answers, but when someone gives me a task I will either utilize someone I know, Google, etc to find the answer so I can get it done.
    – Ethabelle
    Apr 12, 2012 at 14:40

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.