How Do You Interview A Sysadmin Candidate?

benedict writes: "The article No Shortage of Programmers? sparked a really interesting thread about how to interview programmers. Being a systems administrator, I am curious about the Slashdot community's collective wisdom on how to interview sysadmins. I have come up with a few questions of my own to prime the pump. 'What is tcpdump? What is it good for?' 'How about truss/ktrace/strace? What are they good for?' 'What's the largest number of machines you've maintained? What have you done to make it easier on yourself (e.g. what types of automation, file distribution, etc.)' 'Do you use source code control? What for?' I would also present a couple of 'hypothetical' situations from my own experience and ask how people would approach them. How about you: what kinds of questions would you ask, what situations would you describe, what kinds of answers would you look for?"

Comments

Here's a working link...

[krugdm]

...to the No Shortage of Programmers article.

Interviewing sysadmin candiates [unix only]

[GoNINzo]

I've interviewed quite a few, and there are 'sets' of questions you can ask. You don't want to follow a work book, but there are a bunch of formulaic questions you might ask:

• Describe the process in which your favorite version of comes boots up from a cold state. Please use as much detail as possible. The advantage of this question is that there are TONS of sideroads to check. Also, you find out how interested in the underlying part they are. Also, you can see what run control scripts they hit, and you can hit those applications later... Or better yet, they can tell you things like what run level 4 on Solaris is, etc. (ie, trick questions)
• OSI layers? BSD vs. SysV? This tests if they are well rounded. You see if they've touched networking, you can see if they even know the book learning on the different OS's, and get general 'you need to read a book to know this' type stuff. Also, asking the differences between things in the simplest possible terms is another good test to see if the candiate has the ability to talk to managers. `8r)
• Favorite OS and why. Any good unix candiate belives in 'the right tool for the job'. Anyone who says that 'Linux is the answer to everything' is fooling themselves. All the different Unix OS's have their advantages, and the key to having them explain theirs. They don't have to agree with you! that's the key. But they should at least make sense. But don't hold it against them if the answer is 'Because I know that OS the best'. It's a common one. But do NOT let them just say 'Oh, AIX sucks' etc. If they can't back that statement up with facts, they obviously havn't looked at it close enough.
• How would you rate yourself on DNS? Ah, an expert, eh? What are the different types of records? What are some limitations of MX ones? Get deep into at least one major unix process. Sendmail, NFS, NIS, and file systems are all very good parts to go into detail on. By asking how they rate themselves, they show either a) they know what they're talking about and rated themselves appropriately and b) They are rating themselves guru-level when they have trouble remembering even the names of the parts of the program.
• So I had this really hard problem... I was seeing this kind of behavior... What sort of things would you check to solve the problem? No, I tried using This calls into all their troubleshooting skills. You see how deep they go, what they go to next, and why. There are a couple sendmail and NFS problems that can run the gamut.

One more thing... Don't expect excrutiating detail on a process that you don't know either. IE, don't ask a person questions that you don't know the answer to either! And if you do feel inclined to ask about something you don't know, make it clear that you're coming at it from a newbie's point of view.

If people have further questions, i'd be happy to answer them.

Random thoughts

[andy@petdance.com]

Random thoughts from my past, in sysadmin and elsewhere:

• Last programmer I hired was because I saw her reading Webmaster In A Nutshell on a commuter train. "You wouldn't happen to be looking for a job, would you?" Bing-bang-boom.
• I always ask "How do you keep up?" Good answers: "I read Slashdot", "I have a $2K/year book budget", "I'm trying to get a complete collection of O'Reilly books". More importantly is how they reply. If they have to think about it, then they don't see it as a priority.
• Culture in general is key. Any mention of Slashdot or similar fora is almost a requirement.
• Immersion questions are as important as specifics. Someone who crammed through Teach Yourself Perl In 72 Seconds may well know the three basic data types, but only an experienced programmer will know who Larry, Randal and Tom are.
• Ask him to DO something. I've given printouts of suboptimal web pages to the candidate and said "OK, how would you fix this?" (Tell him it's an old version of the page, so he doesn't have to worry about offending anyone with his comments) Read Nick Corcodilos' excellent Ask The Headhunter for more about this sort of interviewing.
• It's critical that the person actually care and/or be interested in the business that you're in. My company is in the education business, and in my eyes, it's important that they see the industry itself as valuable.
• Ask about what kind of machine they have at home.
• DON'T ask the standard bullshit questions, like "Where are you going to be in five years?", "What are your greatest strengths?", etc etc unless you actually CARE about those things. Chances are, you don't, and you can't even answer those yourself.

Have you ever

[Sir_Real]

Have you ever worked with a mixed platform network? Done a network backup on such a network? (I only mention this because I'm a big fan of backups. Well, I am now that I've found that the hassle has a payoff. A large, large payoff.)

Andrew

Not "what it does", ask "how to do"

[Syberghost]

Don't ask "what is tcpdump?".

Instead, ask "what would you use to view the contents of TCP packets on the network?"

We start with the basics "what would you use to list the contents of a directory?" and work up from there, to gauge the level of knowledge.

Also, technical folks conduct that part of the interview over the phone, and the person doesn't get a face-to-face with a manager about non-technical issues until AFTER we've made our recommendations.

Thank you!

[20000hitpoints]

THANK YOU.

The same, incidentally, goes for hiring programmers. Requiring interviewees to answer questions like "what are the arguments of the 'exportObject' method in the java.rmi.UnicastRemoteObject class?" will result in you hiring programmers who have maybe done a lot of programming, or maybe a lot of memorizing, but who have not (necessarily) done a whole lot of thinking, learning, or architecting systems. Additional minor details that questions like this don't test for are understanding computers, computer science, or algorithms. Remember, we're supposed to be ENGINEERS -- not typists!

SAGE have an excellent booklet on this

[ader]

Don't sort through 300 random Slashdot trolls. Join the System Administrators Guild and get their booklet on Hiring System Administrators. That should answer all your questions in one hit.

Ade_
/