FizzBuzz is a simple test of programing ability, often used by employers to weed out people who can't actually program. Is there an equivalent test for system administrators and general IT guys?

Clarification I'm looking for things that can be tested in an interview setting with some accuracy. Obviously, this isn't going to clearly determine the right person, just as FizzBuzz doesn't for programmers. I'm just looking to weed out people who think they can work as a system administrator/IT Person because they can surf the web.

  • If you can get your email, your probably safe. Mar 18, 2010 at 17:34
  • 1
    @user37899:don't you mean, if he or she can get your email, you're probably safe? Mar 18, 2010 at 17:40
  • So... We should just hire someone off the street and if we can still get our email, we clearly hired the right guy?
    – baudtack
    Mar 18, 2010 at 18:05
  • Well for someone who is doing a good amount of scripting, FizzBuzz ain't bad for admins either. Mar 18, 2010 at 18:41
  • 2
    Shouldn't this be Community Wiki? Is there an answer to this question? Mar 18, 2010 at 21:29

9 Answers 9


I don't think you are going to come up with a single test like this for administrators because the definition of an administrator (for purposes of this site) is much too broad. The FizzBuzz test can be implemented in any programming language, so it doesn't matter if you are hiring a PHP developer or someone doing embedded C.

On the administrative side, you could be hiring a network admin, storage admin, server admin (further broken into Windows, Linux, *nix, mainframe), desktop admins/support, service desk or even specific application administrators (Exchange, Lotus, SAP, etc).

Sure, one area you could touch on is TCP/IP and CIDR as network communication is a fundamental skill of most positions but even that may not be necessary for entry level potions (unlike FizzBuzz for developers).

Personally, I prefer to use open-ended scenarios to see an applicant's troubleshooting process and how well they can analyze a new situation. An even better extension of that is to have the applicant work directly with an internal customer on a real issue. Not only do you get to see the above in action but also see their customer service attitude.

  • +1 Good points. The interview and the methodology must be taken in the context of the position applied for. Mar 18, 2010 at 22:58
  • 2
    +1 From me as well. Sysadmin is an extraordinarily broad job description. If you need a unix admin, make them build a package or install some patches. If you need a Windows admin, make 'em add a computer to the domain, or set up DNS or DHCP. If you're looking for a desktop guy, ask them stupid questions until a normal person would snap. Mar 19, 2010 at 0:22
  • From the description, the fizzbuzz for admins would be a test of troubleshooting process, no? That's something all those sub-categories have in common, I would think. Mar 19, 2010 at 12:16
  • @Satanicpuppy...the question is, do normal people apply for a desktop support job? Mar 19, 2010 at 12:17
  • 1
    @Bart Silverstrim All things are for the best in this best of all possible worlds. Mar 19, 2010 at 15:06

I think you'll find FizzBuzz is very rarely used at all and then only by very poor interviewers with minimal knowledge of programming principles. Any common testing method like that is completely defeated because the solutions are widely publicised and memorised by anyone who even considers themselves qualified for an interview. Any such test for a sysadmin would be equally useless.

Standardised test questions are and always have been worthless. No less so in a job interview than having the same questions every year on a school exam. They work just once.

What you need is the interviewer to be skilled and have an ability to "read" people. There's more to be learned about how a candidate answers questions than there is about the answers themselves. There are no shortcuts. At least none of any value.

  • 3
    FizzBuzz obviously isn't going to weed out every person who can't program. It's not supposed to. It's supposed to weed out those who think programming sounds like a fun job but have never written a line of code. It's going to be fairly obvious if someone is just regurgitating something they read online with no understanding. I was mostly using FizzBuzz as an example, not suggesting that anyone who passes it could program.
    – baudtack
    Mar 18, 2010 at 20:56
  • 2
    I can'tsay enough how so right this answer is.
    – Jim B
    Mar 18, 2010 at 21:14
  • 2
    I must disagree. I've given FizzBuzz as a interview programming question to many candidates, and am frequently shocked by how many candidates struggle through it or fail outright. Anyone who cannot pass FizzBuzz is rejected quickly. Those who pass FizzBuzz are put through more rigorous evaluation. FizzBuzz an excellent tool for weeding out some incompetent programmers.
    – abelenky
    Mar 19, 2010 at 8:21
  • 2
    FizzBuzz isn't about programming. It's not about being a competent programmer. It's about thinking process. Sysadmins need that quality as well, figuring out how to solve a problem. Fizzbuzz is basically about coming up with an algorithm/solution to some relatively simple math, and translating it into a requested format (since the blogs I read about it said even putting it into pseudocode was too difficult for many candidates). It could be argued that FizzBuzz is applicable to any job that requires methodical, logical thinking. Just not the only qualifier, which it wasn't anyway :-) Mar 19, 2010 at 12:21
  • 1
    @John Gardeniers: I agree. I am disappointed that these candidates make it to the interview stage. But the fact is that people lie on resumes, recruiters misrepresent their candidates, and HR staff with no technical knowledge often set up interviews. It falls to programmers such as myself to try to maintain a minimum standard for candidates and employees.
    – abelenky
    Mar 19, 2010 at 19:52

I still find that the old "how do I safely and portably delete a file named 'dash-eff-arr' (-fr)?" to be a reasonably good predictor of how well someone will fare for more advanced questions. I routinely recommend it as a screening question.

People who flounder around with suggestions about globbing, quoting and escaping are, in my opinion, potentially dangerous at a root shell on a production system. Those who blithely suggest rm -- -fr are only marginally better. Those who demonstrate a real understanding of how the shell parses a command line ... about the difference between what the shell parsed and what a command (such as rm) received on its argument vector usually have a pretty good understanding of other systems administration material as well.

A much more interesting and involved question:

Given a tape backup, a boot/root or rescue disc of your choice, and
a system with a freshly replace, blank, hard drive ... how would you get
that system back into production?  What other information do you need
before you can proceed?

(I will usually provide a specific tar command and a date as the label on the tape's case; and print out with the fdisk -l and df -k output; and I generally will permit them to change the tar to any similar cpio, afio, or even pax command; the details of the archiving utility are not the focus of my question).

This question is not suitable for screening ... the interviewer has to have a solid understanding of the answer and should be able to check off about ten steps in the process. I'm very forgiving of minor sequence issues, especially if the respondent catches them --- for example realizing they he or she would have had to run fdisk before that series of mkfs and mount commands.

I'd say this is, in spirit, the closest to a fizzbuzz scenario.

Another favorite:

You have just been given responsibility for a departmental server running Linux.
The former admin has been "hit by a bus" and no one knows the root password for
this system.  How do you proceed?

This one is intended to be a dialog. At the core I want them to demonstrate an understanding of how to boot a system into single user mode and force a password change and how to boot from a rescue disc and accomplish the same task. (So I reveal, by turns, that the system is configured with sulogin and that there's a bootloader (GRUB or LILO) password to prevent an easy init=/bin/sh). That's the purely technical part of the desired answer.

However, I usually also care about the broader considerations that they should raise. Do they ask whether anyone has sudo access sufficient to the task? How do they anticipate arranging for the service disruption? Do they ask about the possibility that the former administrator was hostile or that the system may have been compromised? Do they volunteer some opinions or make suggestions about how passwords should be escrowed by management?

  • 3
    Password recovery is worthless as an admin test. You really have to pose a problem that can't be easily solved by any school kid with Internet access. Apart from which, a demonstration of hacking techniques in no way indicates the candidate has any worthwhile admin skills. Mar 18, 2010 at 20:26
  • @John Gardeniers: Password recovery is not really a "demonstration of hacking." But let's turn this criticism around and ask: would you consider someone who did NOT know how to force a system password change to be a truly qualified UNIX/Linux sysadmin? Keep in mind that the process of forcing a root password change is almost identical to that which one would use for troubleshooting a variety boot configuration problems (particularly when using a rescue disc or network boot).
    – Jim Dennis
    Mar 19, 2010 at 4:25
  • 3
    I'm really a Windows admin, so can't comment too much on the principles you refer to, only ever having needed to recover passwords on Windows and a Mac, but I would definitely hire someone who doesn't know how to recover passwords - provided I'm satisfied they know how to learn to do so if/when required. THAT is the single skill I want more than anything else, the ability to find the answers. Mar 19, 2010 at 6:26
  • 1
    Considering how much sysadmin work I've run into comes from having to research online and "network" with other admins...I question anything that judges potential admins with on-the-spot trivia, especially since techniques change over time (fsck a drive with a "touch" of a particular filename at boot works for Ubuntu...but for all Linux systems? What about just booting from a disc and check it there? Or differences in handling filesystem mounting across Linux versions? A huge amount of troubleshooting consists of finding answers rather than knowing them, it seems.) Mar 19, 2010 at 12:26
  • @John and Bart: the basic principles of how to "rescue" a Linux system have been consistent for its history. Some details have changed for good reasons. Many of them also apply to other forms of UNIX (on very old systems you loaded a "mini-root" environment off the systems installation or IPL tape; similar to running from a RAM disk today). If I were interviewing for an entry level or internship position then I would be happy to provide a laptop/browser and have him or her look up the answers right there. (Normally I'm only asked to give technical interviews for very senior candidates).
    – Jim Dennis
    Mar 20, 2010 at 2:20

Nothing formally usable I can think of, but here's a few more general tips.

Ask them about backups. If they don't say something along the lines of "the purpose of backup is to restore" you don't want them.

You need to get a feeling for how they react when Mr Sh-t meets Mr Fan and decides to have a beautiful relationship. Fake an emergency situation during the interview and see if they go about at least dealing with it in a sensible manner, or do they run around in circles as if they were on fire.

You need to weed out technology evangelists. These people are never good to have on board as they will always want to use their favourite technology, irrespective of whether or not it's suitable. A few leading questions should get you there.

You also need to weed out the "ivory tower" types. A sysadmin should always be prepared to roll up their sleeves and get their hands dirty where required. That fake emergency situation might help here.


Ask them to explain what means. The answer doesn't need to be quite as detailed as this one, but any SysAdmin should be able to explain addresses, networks, masks.

  • IMO anyone who uses a computer should, but that's not going to happen anytime soon
    – PostMan
    Mar 18, 2010 at 18:12
  • 2
    @PostMan: Understanding CIDR is so far beyond necessary for the average computer user.
    – brent
    Mar 18, 2010 at 20:25
  • @PostMan - that's like saying anyone who flies in an airplane should understand the air traffic control algorithms for directing landings. Sysadmins exist because tools that aren't usable by the ignorant eventually end up in the trash heap.
    – sh-beta
    Mar 18, 2010 at 22:10

Ask them to come up with a troubleshooting tree for SSL. Most new IT systems today depend on web servers, and SSL depends on a number of technologies. Start with 'A user complains that the website says the security certificate is invalid,' and have them start listing things to look for.

What you want to look for are three things:

  • information gathering, culminating in reproduction of the problem
  • experimental procedure; change one thing and one thing only and compare outcomes
  • understanding of SSL security mechanisms and the technologies beneath it; DNS, web server config, and even browser configuration

Bonus points if you can actually pull an initial vague description of the problem from your existing issue tracker. Finding the root cause of a problem can be difficult; as Torvalds says:

Somebody finds the problem, and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.

  • I didn't give the downvote (I hate it when people downvote but don't leave a reason so answers can be improved)...but we just had a user report they couldn't get to the home page. Tech goes onsite. The computer wouldn't turn on. "Home page" meant login screen, apparently. Mar 19, 2010 at 12:32
  • Good point. I'll clarify the last sentence a bit.
    – jldugger
    Mar 19, 2010 at 18:07

Having interviewed a few people for roles at our place over the last few years I'd say that a tech quiz involving some MCP like questions works pretty well for a paper exam. The rest (such as approach and problem solving) are best found out through a one-on-one interview and technical discussion.

I've set some quizzes for people that have seemed on the ball and have all the right bits of paper only to have the receptionist that they were in tears taking the test! So whilst certs are a good indicator, you can't put all your faith in them.


A system administrator should be able to give you detailed step-by-step instructions for configuring networking on at least one common operating system, and he should be able to do this without seeing or touching a computer.

@Ben, Giving them a computer defeats the point of the test. I think configuring the network is a very basic skill that every sysadmin should pretty much have committed to memory.

Over the years I have probably received a dozen or so calls where someone else had helped one of my laptop users set a static address or proxy so it worked on a some foreign network. When they moved ato nother network they called me asking what they needed to do fix their computer. These calls always seem to happen when I am not in front of a computer, and the caller usually has enough political clout that immediately helping is required. I am not saying you have to know every detail like the exact name of the menu items, but I think you should be able to walk someone through troubleshooting and fixing the network settings on computers without being in front of that computer.

  • On a similar note. If you ask them to configure something common (like networking), they should not be reading each screen. The screens should be familiar enough that they just simply know where to click next skimming over the screens.
    – Chris S
    Mar 18, 2010 at 18:37
  • 2
    I will have to disagree with this one. In my opinion, asking anybody how to do anything from memory is just cruel. I sure as hell don't memorise every aspect of Windows (and it's even worse since Vista/7 totally changed a lot of major things) and I wouldn't expect candidates to know this off by heart either. xkcd.com/627 don't you know! Personally, I would give them a laptop and ask them to do it and try and gauge from that. Mar 18, 2010 at 18:53
  • @Ben, updated to address your point. I have several occasions where I have had to provide this level of help to my users. I believe a sysadmin should know basic network configuration better then the back of their hand.
    – Zoredache
    Mar 18, 2010 at 22:03
  • @Zoredache: it's not entirely that simple, in my opinion, since it does radically change at times. They should be able to learn and navigate it, but at the same time it wouldn't necessarily work on all our systems (example: dell's wireless utility likes to steal network management from Windows on our XP notebooks). A new tech would be lost if they weren't familiar with that, but it doesn't make them incompetent. I'd rather have someone that likes learning and adapting to these issues instead of a memorize the bullet points person. Mar 19, 2010 at 12:30
  • @Ben & Bart: You're missing the point. They don't have to be 100% accurate. But they should know it like it's their job. The questions should be based on a simple task for that particular job. If you have to make excuses for the person before you even hire them, time to find someone else.
    – Chris S
    Mar 19, 2010 at 18:26

It's a simple question, when doing your sysadmin duties do you use the command line or the mouse.

If they said mouse, I'd show them the door.

  • Both. The mouse is mostly used to switch from one window to another and to operate my browser (even though I've been slowly getting use to Vimperator for Firefox). On my work system I've standardized on 132x52 Terminal.app (Mac OS X laptop ... usually using dual monitor mode at the office). I usually have 4 or 5 such term windows ... all ssh'd into my desktop and sharing one persistent multi-user GNU screen session which an average of 20 shells maintain state in various connections to other systems, IRC, etc.
    – Jim Dennis
    Jun 20, 2010 at 10:01
  • 6
    I'm not fond of this answer. There are a lot of situations and solutions perfectly addressible via the mouse - and many which can't be handled without one. I like the CLI too, but there is no need to be a snob about it.
    – quux
    Aug 4, 2010 at 9:26
  • I think this is a bit too blunt and narrow, but it is true that a shocking number of IT professionals -- even folks in their thirties -- profess an avowed dislike for using the command line, with the consequence that they are completely incapable of automating anything without some kind of a pre-packaged solution. These people really do deserve to be shown the door, unless they are being hired for a dead-end job.
    – Skyhawk
    May 22, 2012 at 23:29

Not the answer you're looking for? Browse other questions tagged .