How Do You Interview A Sysadmin Candidate? 476
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?"
Where do you go for your techie news? (Score:2, Interesting)
Three top questions: (Score:4, Funny)
Which weapon on Counter Strike do you prefer?
What is your home machine?
Solve real problems! (Score:2)
If you're interviewing somebody, don't throw acronyms at them and ask them "do you know this?" because they'll either say yes or sidestep it. Headhunters tell interviewees never to say they don't know something. Instead, give the interviewee real problems to solve and see how they tackle them. Pay attention to how methodically they solve the problem, and ask them to explain their thought process to you.
System Administration is not about what you know; that stuff can (and should be) looked up in a manual, to avoid mistakes. It's about thought process, ingenuity, methodology, intuition, meticulousness, and overall problem solving skills. These are what you want to test. Obviously somebody needs to have worked with the basic software/hardware/equipment that you need them to work with. Obviously they need familiarity with your environment. But those are just minimal requirements; a good candidate should have a good understanding of how a network functions, how a unix system functions, and what goes wrong.
At my site, we have a lot of Solaris systems and also some chip testing equipment from companies like Teradyne. I didn't have any familiarity with the chip-testing equipment, other than the fact that they rely on an external Sun to provide services to an internal netbooted system. However, if my company had a requirement that any new hire needed to be familiar with the Teradyne stuff, they'd never find anyone to hire. I, and other employees, picked up that stuff fast enough; sometimes you need to acknowledge that with specialized hardware or software, some on-the-job training may be required.
Ask them if they.. (Score:4, Funny)
Thoughts on Interviewing (Score:2, Interesting)
- Try to ask the same questions to all candidates, but feel free to customize your follow-ups when warranted. The single biggest mistake I've seen is a scenario where candidates are asked very different questions, and no real comparison can be made.
- Ask questions that relate to the job at hand. Don't get theoretical unless the job involves heavy theory. A good interviewer will have enough understanding of the job at hand to be able to ask and understand answers to the question at hand.
- Don't ask leading, "I know the correct answer and you have to figure out what I'm thinking," questions. I've seen this happen as well; an interviewer asks a leading question, the candidate gives a reasonable (but perhaps incorrect) answer, or at least exposes some interesting and appropriate thoughts on the matter, and the interviewer says, "Wrong!"
- Don't assume that there is a piece of knowledge that is an absolute marker of proficiency or understanding of a topic. Sure, any experienced network admin would probably know about tcpdump, but there are certainly sysadmins who don't have extensive networking experience.
- Prepare for the interview process by assessing what knowledge you require of a candidate, and what you can teach. For example, you shouldn't expect candidates to have knowledge of the specific oddball hw/sw that you are using (e.g. eGate, Citrix, f5). Sure you might some who do, but don't assume that because they have experience with this one area that they are the ideal candidates.
- Others have mentioned it, but it bears repeating; ask _open-ended_ questions to get a sense of the candidate's thought process and problem-solving skills. It is impossible to know "everything there is to know" about any tech/IT job, so you must have someone who can think and solve problems.
Re:Thoughts on Interviewing (Score:2)
Here's a working link... (Score:3, Informative)
May I have your advice... (Score:5, Funny)
what about the meat? (Score:2, Interesting)
Here's the thing -- I'm an instructional technologist, so I'm always thinking about how people learn about technology, and how best to move information around regarding technology. So maybe it's easier for me to get to the heart of interview questions by breaking down possible questions into categories . . .
First: Identify what it is the candidate will really be doing for the organization. Is this someone who should be able to turn everything around for the better? Is this person just supposed to fill the shoes of someone who's leaving? Is it a new position? Is this someone you're setting up to take the blame when that domain controller you've been nursing along for months finally tanks? Ask questions with the context in mind.
Second: Consider the level of knowledge that is required for the job, and ask the highest level questions first. Here's how learning works --
** The lowest level would be facts (list the components of OSI model)
** Next would be concepts (what are the characteristics of ethernet versus FDDI)
** Then there are relational rules (how do you know when to back up your account database) and procedural rules (list the steps you follow for a Win2K deployment)
** And finally there is problem solving (apply what you know about disaster recovery and backup plans in telling us how you would react to a long-term power outage.)
So when you're interviewing a potential sysadmin, start with some of the how-well-will-you-fit-in questions, and then follow up with questions appropriate to the level of knowledge you expect them to use on the job . . . and, oh by the way, you might be prepared to answer all of those questions yourself. Makes it easier to turn an interview into a conversation, and I really think conversations will tell you more about a technologist than your standard grilling of the suspect.
Troll Them (Score:5, Insightful)
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
Network Engineer - Hopefully Helpful (Score:4, Insightful)
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.
Some good advice (Score:2)
What kind of computer do you have at home? (Score:2)
I also ask how they got into computers in the first place... This is another 'into it' question... you get a lot of people who got into the biz for the $ and don't really enjoy the work...
Why are there still sysadmins? (Score:2)
Systems should be self-organizing and self-protecting. Specifically:
The Macintosh was closer to this in 1990 than what we have today.
One of my favourites... (Score:2)
'How much disk space should you allocate for the /proc filesystem?'
He said he was shocked at the number of candidates that couldn't get that one right.
My suggestions (Score:2)
Technical stuff is all very well, but you might try coming up with some logic questions too to see how they perform in unknown situations (once you know how to solve a problem it's much quicker to fix than if you have to figure it out).
Can they login? (Score:2)
Set them down in front of a computer/terminal/whatever. Say "the password is ..." and tell them the password. See if they instinctively type "root" for the userid.
Re:Can they login? (Score:2)
It doesn't take much before you outgrow root logins and graduate to the land of su and sudo. The sooner you realize that root's shell should be
Be sure that... (Score:2)
I don't sysadmin, but I also know that most sysadmins type chmod 666 blah.file , whereas I type chmod a+rw blah.file. I saw a sysadmin canidate get bombed on that one, once.
You also can learn a lot about any canidate by asking them about:
1) Their personal projects
2) Their past work experience
If they are to be a sysadmin and they run a little network at home or have run one well in the past at an employer, they probably know what they are doing.
Also, ask them about a technology that they are likely to hate. If you are the boss and they are the sysadmin, you want them to be able to consider other options and not just dismiss them because it's Microsoft, VMS, AS/400, etc. You want to make sure that there is rational thinking behind their recomendations, so that they don't replace all of your Sun boxes with HP boxes simply because they like HP more.
An administrator's test (Score:2, Funny)
Take the person to a room and boot up a Windows system - a Windows system without a mouse.
Ask the person to copy all files from C:\Program Files to C:\TEMP
Those who have their "SH" with their "IT" won't break a sweat. The others will ask for a mouse...
Don't give them a pop quiz. (Score:3, Interesting)
What you want to find is someone who is interested in what they do and can learn new things as new problems arise. You don't want someone who just memorized a book and some man pages, because what will they do if something happens that wasn't in the book they read?...
Word things well! (Score:2)
Our standard 20 Questions (Score:2, Informative)
1. What are the fields in the passwd file? What do they mean, what do they do?
2. How does enabling shadow passwd's change the functionality of user authentication?
3. Pick your favorite Unix flavor. Pick your favorite HW in that flavor. Walk me through a system load, the whiteboard is over there.
4. What are Unix runlevels and how do they work? Flavor-specific answers are acceptable.
5. What's a socket? What's a port? How do you reserve them? how are they related? How do you find out what's going on with them on a system? (again, pick your flavor)
6. Do you know Perl?
7. If the answer to 6 is No, then why the hell not?
8. How would you grab the middle 300 lines of a 1000 line file, grab the second field of every line in that range, and sort the result alphabetically using only piped commands from the toolbox?
9. Do you know vi?
10. Pick your favorite Unix. Great, now tell me how you would a) mirror the rootdisk, b) grow an existing filesystem, or c) modify the partition table for a disk on that OS.
11. What are the various levels of RAID and what differentiates them?
12. What do you know about NIS? (or NIS+, or LDAP).
13. What do you know about DNS?
14. What do you know about NFS? Automounting?
15. What do you know about Firewalls?
16. Describe the various metrics and procedures you would use to evaluate the performance and system utilization of a Unix machine.
17. What's your biggest fuck up, and how did you fix it?
18. If you didn't know how to do something, how would you go about figuring out how to do it?
19. Do you smoke? Drink Coffee? Drink?
And finally:
20. Ok, pretend for a moment that the entire network crashes and the CEO is in your office wanting to know why. What do you say?
:-)
Pogie
(The only good NT server is a down NT server)
What do you know... (Score:2, Interesting)
There were a few that made it to the in interviews done in person...and that had to have been teh roughest gauntlet I've done. 9 hours and 14 people. Even lunch was an interview. They asked anything from C coding minutae to very simple sysadmin to favourite accomplishments to my favourite hack.
They also encouraged me to ask questions. THAT would be an excellent way of telling about your candidate. What does he/she ask about? Watch that and you can get some peaks. Sysadmins shouldn't be timid! Nor should they be overbearing.
The other thing that they seem to be noticing is whether or not they are are salary hoppers or not. They've been quite purposefully screening out those that change jobs every 6 months...partially due to the fact that they are going to invest a lot of money in training and such. Loyalty is important too.
Finally, ask things they don't know...as someone else pointed out. How they respond matters quite a bit.
*chuckles* I got the job and I'm quite pleased with it. It was also the roughest interview I've ever had.
Interviewing sysadmin candiates [unix only] (Score:4, Informative)
- 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.
Destiled wisdom (Score:5, Funny)
Re:Destiled wisdom (Score:2)
Broad Knowledge/Fast Learner (Score:4, Insightful)
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.
Best Questions (Score:2, Interesting)
The Best Questions are Obviously...
Define Red Shift and Wake Turbulance
Than make them recite the Distance Formula for any 2 points on a graph.
If they know the answers do not hire them. Everyone else qualifies.
Signal-Words (Score:5, Funny)
Robust
Synergy
Think-outside-the-box
Current- state
Pro-active
Throw them out of your office.
The questions they asked me... (Score:5, Funny)
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.
Re:The questions they asked me... (Score:3, Insightful)
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.
The Laptop Test (Score:2, Interesting)
Example, we have them cd to a directory where one of the files is named '-' and have them remove it. rm -. Ooops. Now, how to get around the fact that rm is parsing that as the first part of a flag instead of a filename? The goal isn't to completely stump them, but to give them small cases to display some problem solving skills.
Another question asked during "the laptop interview." "What OS is the machine running?" Not everyone knows the 'uname' command. For those that don't, there are other options! Like the header of the man pages. Or the log in screen. I personally didn't know the uname command during that interview (yes, I took it) but remembered machines advertise the operating system at the login prompt, so I logged out. Not conventional, but they weren't looking for conventional. They were looking for problem solving under pressure. (Being on the spot in an interview like that is pressure. Especially if you don't know the obvious answer and you know you don't know the obvious answer.
Another one they threw at me was having me log into an account. When the prompt appeared the first thing I saw was "no processes" followed by the prompt. If I tried to run any commands I got 'no processes'. What was going on? I tracked the problem down the the user having 'tcsh' in their
I liked that particular problem as it involved diagnosing the problem, and then why the problem occurred, which involved getting into the "virtual" head of a confused user.
Most of the problems in the laptop interview are pulled from real-world examples of problems submitted to sys admins by users in our own environment or others.
My Best (UN*X) SysAdmin Question (Score:5, Insightful)
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.
Digging deeper (Score:2, Insightful)
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.
1st question: (Score:4, Funny)
Who is CowboyNeal?
Re:1st question: (Score:5, Funny)
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
Re:1st question: (Score:3, Funny)
Q: Do you have or can you fake a Slavic Accent?
A: Da.
Q: What is the difference between being root and being God?
A: Root, God, no difference at all.
Q: What is your most used manual?
A: Evil Geniuses for Dummies. Or O'Reilly books. It varies. Dependink on current evil plan.
Q: Have you ever been a sysadmin for an NT system.
A: No, but havink crushed them with mallet.
Kierthos
Re:1st question: (Score:2)
What's the difference between root and God ?
God doesn't think that he is root.
A key human resources criterion: (Score:4, Funny)
If the candidate answers with anything other than some smartass reply like "Yes, with lemon butter and capers" then reject.
not just technical too (Score:3, Interesting)
technical information can be learned reasonably easily but some things cannot be. when i was interviewing people i looked for people who had a genuine interest in IT too and how easily they could pick stuff up, and how well they could manage a number of concurrent tasks.
Random thoughts (Score:3, Informative)
Have you ever (Score:3, Informative)
Andrew
Re:Have you ever (Score:2)
This is probably the most important thing you can ask a sysadmin. We've had a real problem finding anyone that has experience of multiple platforms (and I'm not talking Win/Unix/VMS here -- I'm just talking about Unix). Virtually everyone we've seen has had plenty of experience, but only on Solaris, or only on HP/UX or only Linux. Those people would be completely lost on our network, which currently consists of Solaris, Linux, AIX, Tru64 and OpenBSD. But even if we were a completely homogeneous shop, I'd prefer someone with cross platform experience. It implies they *know* the subject, rather than just being able to quote the Sun training manual, for example. If you've been exposed to the differences between Unices, then you're going to have a more in depth understanding of how and why things work than those who have only encountered one version of Unix.
Heterogenous environments (Score:2)
It's always important... (Score:2, Funny)
Claric
I always include 2 questions (Score:3, Interesting)
And 2) Do you have any questions about working here?
Thoughts... (Score:2)
However, some questions that might be good are:
(Network Questions)
(That last question is important. If you want a good network admin, you've got to look past their prejudices and preferences, and see what it is they really -DO- know.)
(Server-related Questions)
(That uptime question is not a trick. It's not easy, though, and will really sort the wannabes from the gurus. There are many possible answers, but they all work around the same basic idea: Don't put all your eggs in one basket. If you depend on any one thing to work perfectly, it won't. The moment you assume XYZ will be there is the moment it'll decide not to be. Once you work your way through a system, on this basis, you'll have a system that's so near to guaranteed 100% uptime, it's not funny. To go that extra step, calculate the probability of failure for an array A of component X, and simply expand A or vary X, until the probability of total failure is below whatever threshold you've set as acceptable.)
Picking a sysadmin (Score:5, Insightful)
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)
Possible Question (Score:4, Funny)
Questions for a Windows administrator (Score:2)
there are many more possible questions on this path... the path to Windows NT servers that never crash.
--Mike--
Types of question (Score:5, Insightful)
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.
Re:Types of question (Score:2)
You better write that question down. I don't think there's an easy way to pronounce "f#&*". And if they don't know what "f#&*" means, you don't want to hire them.
Re:Types of question (Score:4, Interesting)
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.
One question I wish I could ask... (Score:5, Insightful)
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.
Not "what it does", ask "how to do" (Score:5, Informative)
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.
Re:Not "what it does", ask "how to do" (Score:2, Funny)
Let's do in a different manner.
<interviewer> It's a program to view contents of TCP packets on the network?
<candidate> "What is tcpdump?"
It would be much more funny... (maybe the candidate can then go to the big final, and win 1 million)
Don't worry, I'm too addicted [to|every]day
Re:Not "what it does", ask "how to do" (Score:2)
This applies to any technical field, not just sysadmining.
Re:Don't Laugh! (Score:2)
We wrote a little data retrieveal system on it using a foxbase Dbase III clone. It worked pretty well for the time, especially considering the company wasn't going to shell out for a C compiler or anything. It wasn't in production for long -- it was more a proof of concept for the customer than anything else. By the time we dropped the project I had already proven my usefulness and they kept me around.
Re:Not "what it does", ask "how to do" (Score:3, Interesting)
I'm a big believer in practical exams like that. Sit the candidate down at a box, ask them to perform some simple tasks or give you some information that should be relatively easy to find. I'd rather have someone that can sit down and work with their hands on a problem than spit up textbook answers all day long. You can read up on esoteric commands and techniques all you like, but if you can't translate it into results on a screen, you're worthless. This is also a good way to see how they perform under pressure, and whether or not their afraid to look for help elsewhere. I'll take the guy who fires up the web browser and finds the answer in thirty seconds off Google a long time before the schmoe who spends ten minutes slogging through machine settings and racking his brain for it.
Re:Not "what it does", ask "how to do" (Score:2)
Yes and no. I want to see the candidate able to function without a 'net connection, if necessary. If s/he can't do anything without looking up the answer they aren't thinking and thinking==`troubleshooting step #1`.
Re:Not "what it does", ask "how to do" (Score:3, Funny)
And if you do enough of this, you never have to hire a damn sysadmin!
To candidate 1: Install this firewall software. I'll be back in a couple hours to see how you've done.
To candidate 2: Configure this firewall to...
Etc.
"What's the most difficult thing you've seen?" (Score:4, Insightful)
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?
Re:"What's the most difficult thing you've seen?" (Score:2)
Re:"What's the most difficult thing you've seen?" (Score:2)
Trust me, if I ask you that question, and you describe a real head-scratcher of a problem that you had never encountered before, evidence of a good problem-solving process will go a long, long way in my book, even if the actual solution is to change one character in some config file
How to Interview a Sysadmin? (Score:5, Insightful)
Re:How to Interview a Sysadmin? (Score:2)
Another thing is ask if they've ever been in a situation were they had to innovate to get service back up. For example, we had an IBM file server go down hard on Friday - IBM didn't want to come in till MOnday (it was our last IBM and we'd let the contract expire) so we built a temporary server out of spare parts we had around, and had the file server back up the next morning - it ran that way for a few weeks until we could order a new proper fileserver. Stuff like that.
Re:How to Interview a Sysadmin? (Score:5, Funny)
Not so fast, marketing is hiring too!
Re:How to Interview a Sysadmin? (Score:5, Funny)
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.
Re:How to Interview a Sysadmin? (Score:2)
Ask open ended questions (Score:2)
I have made some critical misjudements on people by not putting enough weight on tough technical questions. For networking candidates I have found the best watermark is to give them a non-standard netmask (like
Longer interviews are better. I won't go to work for a company unless I have been through 4-8 hours of interviews and had lots of opportunities to question the company as much as they are questioning me. I have generally found that my job satisfaction has been directly related to the amount of time spent interviewing, but that's just MHO.
Chris
Re:Ask open ended questions (Score:4, Funny)
I always ask a potential applicant to spell "piece" for me.
Re:Ask open ended questions (Score:2, Insightful)
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?
Re:Ask open ended questions (Score:2)
Thank you! (Score:3, Informative)
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!
Re:How to Interview a Sysadmin? (Score:2)
Someone who doesn't know rudimentary information requires training though. This is usually about the same as being flat out unqualified.
Read the hobbies. No, really! (Score:3, Interesting)
Well Duh... (Score:5, Insightful)
Re:Well Duh... (Score:3, Insightful)
Haha! Do anything BUT that. I'm a decent admin. Excellent with Linux, competent on Solaris, experienced in a wide variety of commercial Mach/BSD flavours. But if someone judged me on my slashdot posts, I doubt they'd have a high opinion. On the other hand my karma's good.
However, in all seriousness, when I've had to interview sysadmin candidates, I DO go looking to see they've posted to any well known technical mailling lists. Slashdot brings out the worst in people; technical mailling lists help highlight people's technical skills.
Re:Questions to ask... (Score:2)
Basic interview questions (Score:4, Funny)
I don't know the answer to that question... (Score:2)
Re:I don't know the answer to that question... (Score:2, Interesting)
"I don't know the answer to that question... and yet I am an excellent sysadmin."
Of course you do, it's: "I don't know the answer to that question, but I know where to find it, and how." That is a much better answer than going forward and pretending you do. In fact, it's the difference between possibly getting the job, and being immediately ruled out if your interviewing with me! Of course, if you can't tell me how to go about finding the info, the interview is definately over!
my experience (Score:3, Insightful)
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.
My test of sysadmins... (Score:3, Interesting)
Then, we go into the technical questions. Things they should be able to explain. Like when you use 'uptime' (or 'w'), what do the three numbers after 'load average' represent? Here. Run a command on this box and tell me how many processors it has, what speed, and how much memory. I run 'top' on a busy production box and have them describe what they see. That kind of thing.
Also, I give them a tour of the datacenter and, while we're in there, have them identify some simple things like cards. Or I'll poing to a Sun E4000 and ask them to tell me, in general terms, about the E4000 server and what it is capable of. I might ask what the difference between the E4000 and E4500 is.
Yes, I also see how they respond to questions they don't know the answer to. But a lot of what I look for is personality. How well they're going to get along with the group and others.
The best question I ever got... (Score:3, Insightful)
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.
trick question (Score:3, Funny)
Throw in atleast ONE trick question:
"Do you have an expeirence with the Thruman Process on Unix or NT?"
"Ummm *cough* yea they used it breifly at the last company I was at"
"On a scale of 1 to 10, 10 being the best, how would you rate your knowledge and expeirence with the Thruman Process on Unix or NT?"
"Very much so, I would have to give myself a 6-7"
"Do you have expeirence with the Uma Modules to the Thurman Process?"
....
SAGE have an excellent booklet on this (Score:5, Informative)
Ade_
/
actual interview question (Score:4, Funny)
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.
Re:Ask them how to... (Score:2)
I don't use Redhat, but I know from hanging out on l-k that there were some problems with the initial release of 7.1 that prevented it from being able to straightly "make bzImage".
I think I could do it now without incident. But I think it would be more important to be able to solve the problems that arrise.
Illegal Interview Questions. (Score:3, Interesting)
Here is a list of some other 'inappropriate' interview questions: http://www.sunfeatures.com/inapprop.htm [sunfeatures.com]
Re:Certifications anyone? (Score:2)
Hey, when I was interviewed for my current position, I didn't know the OSI layers. Boy did I feel ashamed about it! But yes, I still got the position...
Re:What I Would do (Score:2)
Re:Interview a SysAdmin (Score:2)
A MCSE thinking that they can administer a *nix system because they can setup a NT machine with IIS. These insist on running telnet, X and a shitload of other stuff that shouldn't exist on a production machine exposed to the Internet.
Oh, and they won't use the copmmand line, not know shell scripting and will not work as any user other than root (and demand the root password).
At least the programmer can be expected yto learn to admin (and every good programmer becomes a sysadmin, maybe not a very good one, but still good enough to let him/her admin his/her own machine).
Answer: Don't (Re:How do you become a SysAdmin?) (Score:2)
Instead, consider taking a position at a smaller company where you would wear many hats- Network Engineer, Programmer, Analyst, and also, System Administrator. If the company grows, hire yourself a PFY (aka 'Junior Admin') to do the grunt work.
The best way to get real world experience is to find a small but growing company that cannot afford to hire somebody who is already experienced in system administration.
Re:How to choose a female system admin ? (Score:2)
Choose the best qualified person for the position, male or female. You might ask, "What if I have two equally qualified applicants, one male, one female?".
IMHO, that's bullshit, a cop out- in the IT world, there is no such thing as two equally qualified applicants. I assume your company exists for the purpose of making a profit for the owners or shareholders, not to make the world a better place for women...
If you choose to hire a female candidate out of some misguided notion of righting past wrongs, you are derelict in your duty. Your primary overriding purpose is "Maximize shareholder value". You do this by hiring based on what the employee can offer the company, with no regard for the color of their skin or the number of X chromosomes in their DNA.
Re:One I was asked and half stumbled on... (Score:2, Interesting)
Re:I've intervieved a few and... (Score:5, Insightful)
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.
Re:I've intervieved a few and... (Score:3, Insightful)
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.
Re:Ask her about backups (Score:2)