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?"
Have you ever played Core Wars?
Which weapon on Counter Strike do you prefer?
What is your home machine?
Know what BOFH stands for :)
I always ask a potential applicant to spell "piece" for me.
"Technically, a cat locked in a box may be alive or dead." -Kurt Cobain
on this file I send you?
DataSquid.net, a little about me.
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.
No, no! You know the drill! If there's any chance that he'll end up as a marketeer we have to drive a stake through his heart, decapitate him and bury the remains at a crossroads at midnight.
There may be something involving salt as well, but maybe I'm just I'm just thinking about tequila.
I would be a paid subscriber if Taco and Hemos weren't such cunts
Not so fast, marketing is hiring too!
Say no to software patents.
Handwriting test: if their handwriting is anything but completely illegible, don't hire them.
/dev/null? If the answer is not 'for redirecting Web proxy logs' forget it.
Eye test: if they aren't near-sighted, just say no.
Wrist test: if they don't have carpal tunnel, nix 'em.
Clothing test: if they show up to the job interview wearing a suit, they have no clue.
Jargon file test: Do you know what RTFM means? Can you recite the entire "Story of Mel"?
Caffeine test: If they don't ask for coffee, tea, Coke, or some other form of caffeine several times throughout the interview, forget it.
Slashdot test: What is your slashdot karma? (Don't hire if Karma 25)
Microsoft test: show them a picture of Bill Gates naked. If they don't turn away and run in disgust, don't hire 'em. (NOTE: a good hire will be very difficult to catch)
/dev/null test: What is the true use for
My journal has hot
- 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.
Gonzo Granzeau
"Nothing the god of biomechanics wouldn't let you into heaven for.." -Roy Batty
There is loads of highly concentrated wisdom in here
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.
Robust
Synergy
Think-outside-the-box
Current- state
Pro-active
Throw them out of your office.
CIO: "So what do you do?"
ME: "I play a lot of games."
CIO: "Ever make a UT Server behind a firewall?"
ME: "Yeah."
CIO: "Windows or Linux?"
ME: "Both."
CIO: "Go to HR and get a badge."
True story.
This
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.
Who is CowboyNeal?
People skills! Programmers can hide in their
caves and snarl when thrown their ration of caffeine and carbohydrates. Sysadmins gotta be able to smile while being asked: 1) to do the impossible, 2) Yet Another FAQ, 3) add another user, 4) restore from backup, 5) say no to some bigwig who wants the security policy violated for his/her personal whim, *) you get the idea.
Be good to your sysadmin, even if it isn't his/her day.
Do you like children?
If the candidate answers with anything other than some smartass reply like "Yes, with lemon butter and capers" then reject.
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
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.
If your company is running NT or 2000 servers you might ask "How quickly can you reboot a Windows NT Server?"
S.t.e.v.e.
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!
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.
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.
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 like to ask some basic questions to get a feel for their understanding before going into any depth. Here's my favorite question and answer from an actual interview: q. What's the difference between TCP and UDP? a. "TCP is from Microsoft. I don't know what UDP is."
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_
/
Big Bubbles (no troubles) - what sucks, who sucks and you suck
them: so if (this organization) was a circus, what role would do you play?
me (thinking): what the fuck kind of stupid question is that??
me (speaking): *laff* I clean up the elephant shit.
I think they wanted me to say ringmaster or something.