Slashdot Mirror
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?"
My favorite means of testing this out? Troll them. Ask them which editor they use. Ask them which O'Reilly books they own. Ask them which distro of Linux they prefer. If they're zealots about things like that, its going to make it a lot harder for me to get along with them.
Of course, it's very important that you don't make them feel like they're being grilled/trolled, because they're also interviewing you, and deciding whether or not they want to be a part of your team.
--Cycon
Your Brain + EEG + LEGO Robots = Brainstorms
I found a really good way to do an interview was to point the vict^H^H^H^H candidate at a dry erase board, hand them a marker, and tell them to draw up the network they most enjoyed working on.
It allows them to take control and talk about what they know, giving them a comfort zone. I can ask whatever questions I think might be useful. I can add or remove a component and find out how they would work around it. I can also make sure that they are comfortable thinking in the same mindset that I have. I can make sure they are talking the same language that I am talking.
How to do this in a programming arena? Instead of a network diagram, maybe a flowchart for the logic, maybe a screen drawing for layouts, maybe pseudocode or code, although I would expect that last one would get hairy on a dry erase board.
Anyone who can build on this, please do so. I got a CS degree doing programming, but that was way too many years (and beers) ago. I do not remember enough to really be useful on this.
We always ask for what computer games the guy plays. Real time strategy and 3D shooters are our top picks.
We actually use that question to put the applicant at ease. I also ask them if they play softball (recruiting for the team never stops, hehe) and what would they pick between IE and Netscape. The browser question has no right answer, we just want to know the reasoning behind it.
I don't like to play 20 questions, I prefer instead to test them for problem solving skills. I also want to make sure the guy doesn't turn into a total asshole or a heap of nerves every time a red light blinks.
Pedro
----
The Insomniac Coder
So prepare yourself - ask questions about the current structure of the organisation, ask who you will be working with, ask about test systems, ask about backups, ask about software/hardware used, ask about the future and the past. And if they drop something in that it looks like they shouldn't have, ask about that too.
And finally ask about pay, working hours, pension schemes, holidays etc
As much as you are being interviewed, you have to interview them. Make sure they are on the recieving end of thinking on thier feet - would you want to work for a Boss or company who couldn't?
try to make ends meet, you're a slave to money, then you die
Look for people with a broad knowledge of many technologies, even if they aren't experts. You're looking for people who might not know everything, but have a large enough framework knowledge and the willingness to learn anything new.
The easist way to weed out the "Quick Study Course" MCSEs is to ask them about thier experiences/knowledge on Unix/Linux (even if they don't activily use Linux any competent sysadmin has read about it).
If the position is going to be inside a team, and the interviewee seems pretty comfortable, declare the interview over with. Then take the interviewee to the breakroom/lunch and arraige for the other team members to drift over. (Don't go to someone's office to say hello.. this puts the interviewee on unfamilar turf) Maybe have one of the team members toss out a problem they're working on or give a status report. See if you can get the interviewee to interject ideas or solutions. They'll be pretty nervous, so don't hold it against them for being quiet but the really good ones will love talking shop and may even give some free advice. Plus this makes the team members feel more involved in the process.
The biggest thing I can say.. is look for experiences outside the workplace. If someone did something for fun, odds are good that they learned more about it than they ever could of on the job or in a classroom.
The interviewer brought up an xterm on the terminal on his desk, typed `ls
For added difficulty, they were using a version of UN*X I didn't have experience with (BSDi). The question tested:
Lucky for me, I'm pretty curious by nature and got the job.
As a Sysadmin manager, I've found that personality and ability to work in a team can be as important as strong technical skills. As mentioned in other posts, knowing where to find the info you need quickly can make the difference, so finding someone with a strong, broad tech base and a good attitude can be better than taking the first real guru to walk through the door.
Here's some of the discussion questions I hit prospective candidates with to guage both their general tech knowledge (and involvement), as well as their personality and interest in their work:
- Do you consider the open source movement to be a threat to the commercial software industry?
- What was your first computer? What kind of things did you use it for?
- Explain ways in which you believe improper or ignorant use of technology can lead to lost productivity in the workplace.
- Tell me a joke (remarkably, this one stumps about 90% of the interviewees, but it lets me know how fast they can change gears).
I also make sure all the serious candidates meet individually with a few members of the team to get an honest take on how they'll get along, as well as to let the candidate see what kind of environment they'll be working in.
So far, results have been great. Because we only take people who enjoy the technology and a good challenge, we've got an enjoyable, productive environment with lots of discussion and innovation.
There are two questions I ask everybody:
So, what do I learn from these? First off, sysadmin work is frequently nothing more than creative problem solving. I want to know how people resolve problems and what kinds of problem solving they're proud of.
Second, everybody has made a huge mistake at some point in his/her life as a sysadmin. What sets the great sysadmins apart from the clowns I don't want to hire is how they dealt with the situation and what they learned from the experience.
One of the big things I would check for is troubleshooting skills. And in a non-obvious way, so they don't zero in on what you're asking for and give the "right" answers. Asking to give an example of a problem in the past and what they did, give some hypothetical situations (though some people think better in front of a keyboard then in when speaking.)
On big one with me is automation and tools. I don't care if you know a specific tool - that can always be learned. But once you get to real sizes, you need to use automation and tools, you can't do everything by hand. If you told me that you speced out or even wrote tools to fit the specific circumstances of the last job, that's a big plus. Along the same lines, any sysadmin that can't take the time to be fluent in a shell probably isn't worth my time. I ask them for their prefered shell and why. It doesn't really matter what they answer, as long as they have an answer. Along those lines, tellign me that "they used to love [insert shell], but now they don't care as much because they always use perl (or other appropriate language)" is also fine.
Sysadmining is sometimes periods of boredom followed by periods of extreme need. If you can keep your cool in that extrene need, that's very good, but hard to judge on an interview. It's very important, though. If you're a self-starter, and those periods of boredom will be used on projects to make your job easier, either from a manager or self-starting, is also good, and something that might be easier to detect in an interview.
Many sysadmins have a large (and fairly well-deserved) ego. This is almost a "necessary evil". However, a prima-donna or someone who will not work with other team members is a problem, and that can be determined to a point during an interview. Also watch out for loose cannons. They can be great, but they're hard to control. A small company might benefit more then a large one by a loose cannon, but no matter how good they are they can get you in trouble. You just need to balance if it's worth it.
=Blue(23)
LITTLE GIRL: But which cookie will you eat FIRST? C. MONSTER: Me think you have misconception of cookie-eating process.
Sysadmin candidates need to be asked, How prepared are you for artificial intelligence and for http://www.ugcs.caltech.edu/~phoenix/vinge/vinge-s ing.html -- the Technological Singularity as described by Vernor Vinge?
It's important when formulating the questions for a sysadmin to avoid trying to ask "catch out" questions, and better to have a good stock of "standard" questions that will ensure you know the candidate has a solid understanding of the principles. Knowing all of the flags to "ls" or "tcpdump" for example, doesn't tell you much, but knowing that they understand the differences between RAID 1 and RAID 5 is. Crank up the difficulty as appropriate for the position.
Asking questions that only catch out the candidate, leaves them feeling bad throughout the interview, and you with little more knowledge than what they don't know, and maybe a pointless feeling that you caught them out. If that floats-your-boat, go for it, but not me. been there, done that, thinkgeek ain't got the t-shirt.
Also, once you've identified that the candidate has a good foundation of knowledge, start asking about approaches they've taken to problems. One of my favourite questions is "What's your biggest f#&* up". Everybody makes mistakes. If a candidate can't think of a big fubar situation that they've been involved in, chances are they're either very good or inexperienced. It's also a good talking point to base additional questions around. Bring in your own situations as a way of lightening the questioning. You can reverse the question for the age-old fav "Tell me about your biggest achievement", but I prefer problem solving skills in an SA.
I'm also a big believer in "fit". If the candidate "feels" right, but has made a few boo-boo's in the answers given to questions, better to take them than somebody who doesn't "feel" right, and got all the questions right.
At the end of the day, it's a judgement call, and there are plenty of other factors to take into consideration that i've not mentioned here (and I'm sure others will). In a nutshell, find a questioning style/interview technique that ensures the candidate is at ease, feels they can be honest, and covers all of the main points.
Oh, and personally I hate giving and doing technical tests where they're left to fend for themselves for an hour in an empty office. Wasted time all round. Get somebody to interview them in that time who can get more out of them.
Needless to say, get different people to interview as well. Technical skills are but one part of a good employee. HR departments sometimes come out with very good points all the techies in the world couldn't find out.
Hope that helps.
ooooooh! What does this button do? - DeeDee, Dexters Lab.
...Is for references on the employees he/she has helped.
Lets face it, there are two types of sysadmins:
1.) The type that sits in a locked server room never to be bothered (see BOFH).
2.) The type that wants to help you in a kind manner.
Sure, it is more important to have a knowledgable sysadmin that can knows a ton, and knows some clever little techniques to make everyone's life easier, but its also important to have one that is good with employees and treats everyone well.
One of my former employers had a sysadmin that everyone was afraid to go to because of the tone he'd use. He always shouted and was just generally mean to everyone. He was fired, and the man that replaced him knew just as much, but was always helping people with a smile and would stick with you until the problem was solved. It was a huge difference. People loved the new guy.
I'm digressing, but the point is, a sysadmin job usually requires that you help fellow employees, and that is something to check for in an interview.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
This book has just such a set of questions for a UNIX SysAdmin candidate.
For WIN based systems, "How do you reboot?" usually is enough.
DanH
Cav Pilot's Reference Page
UNIX - Not just for Vestal Virgins anymore
You ask a Sr. level admin what are the file types on unix and he will LAUGH AT YOU.
You ask a Sr. level admin how he runs his systems, how he works under pressure, if he/she is available during odd hours and get a personality feel for them. Find out if they're resourcefull, independant and a good co-worker. Don't play 20 questions and post the answers on slashdot :)
1 Good admin can run 4-5 nt servers, all your unix servers and maintain your business applications, databases and still have time to read his (her) email.
One of the best I've seen and heard of is asking "What's the most difficult programming problem or task you've encountered? How did you solve it?"
It's a good question, because it lets you gauge what the applicant is good at, what they might be weak at, and allows you to see evidence of their ability to learn new things.
In other words, was what they consider "difficult" something you'd also consider difficult? Were they able to come up with an elegant and clever solution? A good duct-tape-and-baling-wire workaround? Were they just plain stumped, but understood a good solution when they saw it? Or were they lost completely?
ABSURDITY, n.: A statement or belief manifestly inconsistent with one's own opinion.
Ask him something he obviously doesn't know the answer to, something he hasn't put on his resume. If he gives you a bullshit answer, kick him out the door. If he says, "I don't know", ask him how he'd find out and listen to what he says. Not every sysadmin knows everything, but the truelly good ones will know how to find the information they need. A sysadmin who says, "I dont know we need to hire a consultant" is not someone you eant working for you.
just ask for their Slashdot ID, and then you can evaluate their competence based on their comments and their karma ;-)
I've interviewed a few candidates over the last year or so. We tend to do team interviews. We ask some funny questions sometimes, almost as a joke, but often the answer speaks of how they will mesh the team. We have even asked "what's your favorite shell" and "what's your favorite editor" and "what's your favorite os" :)
Seriously though, I would ask about experience with multiple unixes (assuming a unix admin position), backup systems, perl scripting, shell scripting, shared file system experience (we use AFS where I work), "special project" experience (like beowulf clusters, firewalling, etc). Often a sysadmin is already a particular personality...my experience has been that they seem to have a great uniformity of character. Trust your instincts...not very many people will be able to give adequate answers to 3 of the questions above without being sysadmin material. Oh, and another good question..."Describe an experience that yoiu had with a difficult user". this will show if they have a "screw the user" attitude or have a realization that the user is the job.
-- Who is the bigger fool? The fool or the fool who follows him? --
There are two unix machines named A and B that are on the same subnet. Describe to me, in as much detail as possible, what happens when I type "telnet B" from a terminal on machine A.
The "in as much detail as possible" is the key phrase here. The interviewer got to see an understanding of (or lack of) PATH, inetd, DNS, subnetting, TCP/IP, ethernet, etc.
That question, and the discussion we had afterward impressed me so much about the technical caliber of the manger, I took the job.