12

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.

HopelessN00b
  • 54,273
baudtack
  • 490

9 Answers9

11

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.

Doug Luxem
  • 9,652
7

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.

4

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

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.

2

Ask them to explain what 10.13.216.41/18 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.

Ward
  • 13,010
2

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.

jldugger
  • 14,602
1

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.

Zoredache
  • 133,737
1

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.

-1

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.

The Unix Janitor
  • 2,558
  • 15
  • 13