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?"
If the computers are all down, you don't need a netmask. If you need a netmask in an emergency, there will be a calculator available somewhere. Then, it's not too hard to subtract 29 from 32, divide the IP by 2^3, drop the remainder, and remultiply either... :)
How about not without incident, but just be able to complete the task.
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.
Depending on their answer, slashdot, activewin, theregister, betanews, macworld, or the msnbc technology section!
While it's easier to administor homogenous networks, IT usually doesn't dictate to the rest of the business just who they are going to buy or merge with. Heterogenous environments are often a product of history, not choice. But this sort of reality is what separates the enterprise-level players from small-shop or departmental-level.
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.
Top Most Bizarre/Disturbing Error Messages
Have you ever played Core Wars?
Which weapon on Counter Strike do you prefer?
What is your home machine?
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.
now we need to go OSS in diesel cars
Here is a list of some other 'inappropriate' interview questions: http://www.sunfeatures.com/inapprop.htm
I do not deploy Linux. Ever.
When I interviewed for my current job, the people who are now my colleagues (I'm one of several sysadmins) did something very considerate. Rather than either trying to quiz me with acronyms or version numbers, or coming up with completely contrived examples, they showed me a couple REAL problems that they were currently trying to solve. One was a routing problem. I solved that problem, and basically came to the same conclusion that another sysadmin had come to. I got the job, because I proved that I could handle a real problem, not a silly contrived one.
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.
-- "Those who cast the votes decide nothing. Those who count the votes decide everything." -Joseph Stalin
Know what BOFH stands for :)
A few thoughts on interviewing in general:
- 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.
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
...to the No Shortage of Programmers article.
on this file I send you?
DataSquid.net, a little about me.
I am really worried that any of you guys might end up interviewing me someday. Really. Interviews are a great way of succinctly assessing ability and knowledge, but only if you're ready to get to the meat of what you want.
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.
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
Everything except the proper spelling of "Distilled". Or has Adobe decided that the word "Distill" dilutes their trademark?
Someone who doesn't know rudimentary information requires training though. This is usually about the same as being flat out unqualified.
Linux: The world's best text-adventure game.
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.
Check out this link. It's a good scoop on what a day of a good sysadmin looks like. The second chapter actually has an interview scenario too. Hope this helps.
Your pizza just the way you ought to have it.
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
A sysadmin who routinely logs in as root would lose points with me during an interview. Such behavior indicates to me that they have little experience working in a shared-admin environment or with large installations.
/bin/csh or /bin/sh as a deterrent to frequent use, the better off you'll be.
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
I always as that one. It's not a make or break... but I have found several would be sysadmins that don't have computers at home - that are just not into it, and do lousy work.
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...
BlackNova Traders
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...
Say no to software patents.
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
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
Systems should be self-organizing and self-protecting. Specifically:
The Macintosh was closer to this in 1990 than what we have today.
'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.
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
That's what us geeks were doing while you were out having a so-called, "social life". Moron.
"Technically, a cat locked in a box may be alive or dead." -Kurt Cobain
A better Answer..
What's the difference between root and God ?
God doesn't think that he is root.
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
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).
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.
now we need to go OSS in diesel cars
Be sure that you know Unix as well as your sysadmin canidate.
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.
Gentoo Sucks
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 ask them little trivia questions like "What does this utility do?". A sysadmin is more than just a person who does routine tasks every day, they have to solve new problems as they arise. You should interview a person by asking them problems and how they would solve them. Ask them about big problems they encountered in the past and their solution to them, or problems they weren't able to solve.
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?...
Outdoor digital photography, mostly in New Engl
There *is* something worse than that.
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).
I can throw myself at the ground, and miss.
If you are giving hypotetical situations, be sure to word them well. I once had an interview in which the interviewer tried giving me a hypothetical situation to get myself out of, but he had trouble simplifying it to a way that I could come up with an answer that was more general than the specific one he used to solve the real problem. Luckily the interviewer and I already knew each other, so it didn't ruin either of our days, but being able to ask a question in a way that it can provoke thought is important. If you base your hypothetical situation on a real one, it can be really easy to make it too specific and then expect the exact same solution you used...
Posted from the wireless couch.
At my office, we've gotten real tired of headhunters and placement firms sending us people who call themselves "Unix Admins" and have taken Solaris 101, or AIX 101, or whatever and think they know what they're doing. Here are questions that we ask every candidate. If they answer a couple wrong, no biggie, but some of them are gotchas. BTW, this is UNIX specific (frankly, WinX admins aren't system administrators. They're WinX admins. A system administrator supporting a WinX box is a very unhappy person.)
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)
I tend to ask a lot of open ended questions to get the candidates talking. One of my favorites (lately) is "A new peice of software is placed on your desk. How would you go about implementing it into production?" These types of questions show you thought process, willingness to read manuals, consult help, and generally pay attention to details.
/29) and an IP address and then ask them to tell me the network and broadcast addresses.
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
-- I need more coffee. It's Monday. There is no such thing as enough coffee on a Monday.
There's a good article on The Reg about certifications. The rumors seem to be true, people are being trained to pass the tests, not to know the subject matter. I'd take any certifications with a large grain of salt. It's looking more and more like the people who can do the job are actually doing it; the ones with the certification are the ones that want to do it.
www.lucernesys.comHorizon: Calendar-based personal finance
This applies to any technical field, not just sysadmining.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
I just went through this: being interviewed for a sysadmin job. It's a pretty prestigous place and they were getting 60 resumes/day. My boss for a while there was phone interviewing 20 people/day.
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.
Do you know why the road less traveled by is littered with the bones of the unwary?
- 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
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot 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.
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.
Robust
Synergy
Think-outside-the-box
Current- state
Pro-active
Throw them out of your office.
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.
I do not deploy Linux. Ever.
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
...and yet I am an excellent sysadmin. (On that you'll have to take my word for it.) I'm not an excellent network guru - that I'll grant you. OTOH I've been able to handle all the problems that came up with networking at all the places I've worked. The details of various protocols has never come up. I understand the basics of network layers, seen the OSI model, etc. but never had to delve into the differences in various packets. So where does that leave me with your question? My answer would be "I don't know". Not hired?
Part of our technical interviewing involves sitting down with the candidate and a laptop that has BSD loaded on it. There are little problems that we throw at them to see not only if they diagnose them correctly, but can find a workaround. Then we can see problem solving skills in action.
:)
.login. This was causing new shells to be invoked until the user had no further processes. Follow up question was: Why would a user do that? (Trying to change his shell in a not so smart way. :-)
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.
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.
Well, "sounds impressive" is sort of a subjective judgement. Presumably the person asking would know that that's the sort of thing sysdamins do - I don't think anyone would expect you to wow them with an account of how you cured cancer or whatever. The key to the question is in the description of the problem-solving process, more so than in the actual problem or solution.
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
ABSURDITY, n.: A statement or belief manifestly inconsistent with one's own opinion.
How about: (largely based on Pitr from User Friendly.
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
Mr. Hu is not a ninja.
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.
I do not deploy Linux. Ever.
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.
Who is CowboyNeal?
I (as a software engineer, not a sysadmin) was in a similar situation in my last round of interviewing. Guy asked some programming problem "How would you fix XYZ" I replied with "By doing ABC then DEF" "Well, think a bit different, what about Y again?" "Er, I suppose I could run LMN on Y and see what it showed" "Right, but if Z got in the way..." This went on for about 5 minutes, until I figured out he was looking for a SPECIFIC answer, not just a correct answer.
there are many more possible questions on this path... the path to Windows NT servers that never crash.
--Mike--
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.
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.
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.
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
Well, strike out "programming" in the above, but otherwise it works ;)
ABSURDITY, n.: A statement or belief manifestly inconsistent with one's own opinion.
Claric
There's no problem that cannot be solved with a suitable amount of high explosives
1) Tell me about the things that you have done at your last job or two. Tell me about how you got 10 different types of boxes to work together or implemented a system to do something or whatever. I don't really care if you know all the options to tcpdump by heart, you can look them up when you need them. I would much rather know why you have done the things you have done and how.
And 2) Do you have any questions about working here?
Erlang Developer and podcaster
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.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
And don't forget: What is the air speed velocity of an unladen swallow?
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`.
Best question I ever heard in an interview...
What three things would you need if you were stranded on a desert island?
Never hire anyone who says "my computer"
The question forces potential new hire to think creativly under pressure, and THAT is a an atribute every company needs.
what was the best answer I heard?
One guy said sun tan lotion, toothbrush, and a towel, preferably with the words don't panic written on the towel.
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.
I've done more sysad interviews than I can count, so I've come up with a bit of a "method".
:-)
The first question I always ask is "Can you describe a project you've worked on that you are really proud of, what you did, and why?" This gives them a chance to brag a little, and puts them at ease. I really try to draw them out on this question, to get them to go into detail.
The second question I ask is "Now tell me about a project you worked on that you would do differently if you could do it again, and why?" Anyone who has been a sysad for more than five minutes has made mistakes. You want someone who has learned from them, and can explain what they have learned.
Then I move into the "clue check" portion of the interview. Generally questions one and two have given me an idea of how technical this person is so I can ask appropriately difficult questions. As others have mentioned, I find it's better to ask "how to" questions that are answerable in the context of any flavor unix. Asking about flags to certain commands is just useless.
One question I nearly always ask is "What is the difference between a symbolic link and a hard link?" or the corollary "Why can't you hard link across filesystems?" It's *amazing* how many people who claim to be sysads can't answer that.
I then move into troubleshooting, which is really the meat of the interview. I paint scenarios and ask the interviewee what steps they'd take to diagnose and resolve the problem. "The performance on the mail server is unacceptably slow. What do you do?" "The load on the ftp server is going up to 3000 and then the machine hangs. What could be wrong?" I try to get the person to tell me what commands they'd run, what output they'd expect if it turned out to be X problem versus Y problem. I explain that I'm not looking for a specific answer, I just want to see what their mental process is.
I end with "fit" questions. What hours they like to work, if they prefer to work alone or in groups, etc. This lets the person relax again and allows you to end on a good note. The last thing I do is ask if the person has any questions for me.
This system has worked very reliably for me. I've yet to recommend someone that turned out to be a dud.
If you're going to ask all 'opt out' questions, don't call them in front of a panel of 12 people, and have them drive 20miles there through rush hour for the meeting. Yes, sometimes, you do need to ask those questions, but they can be done easily and diplomaticly, so that you don't piss off the person. [As well, they may not have the talents for the job they're interviewing for, but there may be some other position that you know about that they'd be ideal for...if you piss them off, there's no way they're going to come to your company]
What I've found that has worked in the past for hiring.
Then give them a quick quiz to make sure that they're legit with what they said on their resume. If they say they know PL/SQL, ask them a few set questions, etc. You want this to be relatively simple questions, that someone can answer quickly, without much thought. Ideally, they'll give the right answer. Sometimes, you'll get response like 'I'm not sure off the top of my head but it's in [some book]'. Hell, even admitting that they don't know [so long as they don't fail every question] is better than giving a wrong answer...
You need to make sure that the person feels comfortable before going in and being grilled by the half dozen people, so it's good to get them to meet with one or two people to give them the quick tour, (so they see all of the people whom haven't slept in 4 days, as you're behind schedule...erm..okay, maybe skip introducing them to the other programmers) before you start asking them deep questions.
This last part is the hardest part, as it's the real 'get to know you' type thing. The questions that you ask, and how much you tell them are going to directly impact the future. I prefer letting people know about quirks to the job before they take it [well, we're not so busy right now, but our crunch months tend to be (x,y,z), when we all tend to pull some overtime.]
If you don't let people know about the potential problems to the job, you risk a good chance of employee rollover, and then you've got to go through the hiring process all over again, and you've just lost whatever time you're spent in training. Hiring isn't just about getting the person to come to work for you, but it's about making sure that they stay working for you, too. [Unless you're filling a contractor slot, of course]
Build it, and they will come^Hplain.
I tend to start with lower level questions and work up until I find out where the candidate's knowledge reaches (or that it surpasses my own :) I start with things like "name the fields in the password file" and "how do you tell how much disk space is being used?", then progress to networking: "how do you determine the number of network interfaces and their IP addresses" and "what is a default route, how do you determine it and how do you set it".
:)
If they're still going strong, I'll get into volume management, system tuning, bare-metal restore, and troubleshooting scenarios. So far, I've only had to interview for admin positions for one OS (Solaris, AIX, HPUX) but if a candidate is strong in one OS, I'll usually give them some leeway towards being able to apply that knowledge to the new commands and syntax without much difficulty.
If there's time left over, I'll ask about scripting (emphasizing perl and ksh) and/or other programming skills (can't be a sysadmin if you don't script!
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.
That is all.
Excellent! That's a good idea; I always hit them with an un-plugged box, just to see if they know Rule Number One: "CHECK THE PLUGS!" but a bad cable is even better.
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.
No relation to Happy Monkey
True enough, although if they come back at you with "Well, I just never could wrap my head around this whole int versus float thing..." then you know what you're dealing with right off the bat. ;)
I definitely agree with you that the handling of whatever it was, is the key.
ABSURDITY, n.: A statement or belief manifestly inconsistent with one's own opinion.
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!
"What would you use to list the contents of a directory?" got me my first job heh. They'd been advertising for 3 weeks and I got sick of seeing the ad and called them. I'd never seen Xenix before but it was sufficiently UNIX-Like. I went out there and they showed me the box and said "We got this in and don't know what to do with it." I logged in with their root password and did an "ls -al". They said "That's more than we've been able to do. When can you start?"
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I do something similar to this in interviews. I have a laptop on the desk, with a big chunky PCMCIA NIC, with huge lights. It's plugged into the wall, but the cord is bad. Ergo, no hooge 'LINK' light on the NIC. I say 'this laptop can't see the network. Start trying to fix it.' So far, nobody has so much as glanced at the lights on the NIC. :-)
Vintage computer games and RPG books available. Email me if you're interested.
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
man
Extra points for answering man -k
Calculating netmasks has been relegated to the very back of my brain and was recently pushed out for good by a Palm Pilot application. Why the fuck should anyone be expected to know something as seldom-used as that? What's next? "Explain in 50 words or less the benefits of 'tar' over 'pax'"? Are you gonna argue with candidates over whether /opt is better than /usr/local for third-party applications? The flags for "ltrace"?
If trivial little things like this are what you base your hiring decisions on, I doubt many will want to work for you.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
This isn't a substitute for the other good questions, but this has helped me to make good character judgements.
-- Solaris Central - http://w
Forget asking them about ls and rm and tcpdump, etc., but instead show them the equipment room, talk about what you are doing, etc..
A true tech "geek" will almost immediately forget he's on an interview and start asking questions like "You're whole building is wired with fiber?", Or "What OS are you running on these?", etc., etc., etc.. Sharing war stories also seems to bring out the best in geeks.
You will find out very quickly whether the person knows anything or not, and their relative clue level, although you do have to give some leeway for the occasional stupid question/comment. You can also insert a few leading questions in the discussion. "Oh yeah, we just got done installing those switches last week. Have you played with that brand yet?"
You also will probably be able to tell how much a person really wants to be involved in your company by how they respond during the "show and tell".
The last person we hired was basically interviewed this way. She obviously knew the questions to ask, could deal with our kind of always-hectic environment (darn users anyways), and her eyes lit up when she saw our equipment room. We hired her and we haven't regretted it for a microsecond since.
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.
What mailing lists do you subscribe to, or did you subscribe to at your last place of work?
Vintage computer games and RPG books available. Email me if you're interested.
What did you learn from it ?
healyourchurchwebsite.com - WWJB?
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.
A few jobs back I ended up doing a lot of the sysadmin work for a good part of the company. As a joke, my boss dropped a "sysadmin" magazine on my desk one day. It turned out there was a timely article in it... The article talked about how well programming tests work in a dev organization. Some folks did a study where they applied a how _bunch_ of tests to candidates, but did not _do_ anything with the results; they just kept the data around. Two years later they looked at peer feed back, performance reviews, etc, etc, to look for "key" people and tried to find a correlation. The result was interesting: nothing for the programming test part, etc. BUT, there was a strong connection between "interesting" hobbies and key people. I.E., if you did something like gourmet cooking or sky-diving, chances were good the person would end up being cool. So, now when I interview, I always ask what peoples hobbies are. It seems to work pretty well! --stuart
It became clear VERY quickly, that many of the "standard" questions I was given when I started didn't cut it. Unless you are looking a sysadmin god, most of the specific questions about "How did do such-and-such with this command" don't tell you much.
Here are the types of questions that told me if the person could work through a problem. Have them tell you EXACTLY what they would say and check with someone who tells them the following
"My computer's not working"
"My screen is black"
"The printer's not working"
If they can't lead you through these basics, you shouldn't even waste your time with the rest.
---"What did I say that sounded like 'Tell me about your day?'"---
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."
What really shocked me is that this worked a little too well and it was hard to find the number of required staff. It also showed the CCNP certifaction for what it is; abosolutly worthless.
The people I ended up employing are real gems, they work well together as they all have a good level of technical knowledge, I think one thing that distracts teams moe than anything is the fact that a lot of uncompitent people get employed this distraction doesn't exist here.
As they say the proof of the pudding is in the eating, so let your candidates make some pudding for you.
A journey of a thousand miles starts with a brutal anal raping at airport security
Bah. I play Xscorch..
Which weapon on Counter Strike do you prefer?
Tribes2, man. I've dueled Shrikes with a bomber.
What is your home machine?
Which one? I'll go open the rack and let you know...
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
For some background, I'd been working at a company with a small US office, and a large Australian office. All the SysAdmins were in Oz, and so some of us engineers ended up doing all the "emergency maintenance" when anything broke or didn't work during the US work hours.
The two questions I really remember asking at the last SysAdmin interview I took part in were:
How do you feel about 'sudo'? (This company just tended to let everyone in the US have root and use su blindly - despite my objections.)
What are some common problems with 'samba' in a mixed unix/NT/Win98 network and how can you avoid them? (We had recurring problems with Win98 refusing to play nicely with unix shares.)
Since these were real-world problems that we'd experienced, I knew this kind of thing would come up again. Also, they indicated how broad the candidate's experience was, whether he had worked with mixed networks, knew what sudo was, etc. He had great answers, but then our hiring budget dried up...
I suggest everyone read Joel on Software. He has a lot of good information for programmers and site management. One of his articles is how to interview. He lists several things, most of which are really good for any interviewer (be they in software development or not). For example, his main point, "Smart and gets things done."
Anyway, I'm rambling. Check the site out. Lots of good information.
-Frijoles-
I believe there is a museum located in Ruedesheim, Rhine, Germany that displays some tests I might consider for a sysadmin candidate. The theory being that if they can handle these tests, then dealing with lame users and moody system will be a snap.
healyourchurchwebsite.com - WWJB?
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!
Don't post on slashdot. Get back to work.
I just got done with a couple weeks of interviewing for a new admin here. Here's a bunch of stuff from my notes:
Describe your previous experience with:
Unix: (Linux, IRIX, Solaris, Others)
What I was looking for here was a good history of their experience.. I didn't want to know "I know linux".. I was looking for something more descriptive.. Interviewing is like telling a story about yourself. "I've been using linux since 'XX. I started out doing slackware, but have moved to debian to make system maintence on a large scale easier"
Since this was for a unix admin position, I was looking for some stuff in the Other category.. I want to see some variety in their experience.. Do they understand basic unix fundamentals, SYSV, BSD?
Windows:
I had to ask, just because we still have a few of these around.. but it's good to see a cringe on their face when you ask the question. Working is not all technical skills.. I had to drop a guy's resume because I just couldn't stand the guy's attitude.
Networking:
Have you worked with a managed network.. describe some of the networks you have setup/designed/worked on. I want to find out if the person has a grasp of network topology, switching, vlans, routing, trunking, etc.
Describe your support experience:
I wanted to see what kind of variety of users you've had to work with.. because when it all comes down to it.. they're the most important part of the job. I want to hear storys about user groups.. have you had to support developers? windows desktop users? students? home users?
Audio/Video:
Somtimes the admin has to wear the presentation hat.. make the VCR work. it's just one of those things.
Are you familiar with Linux Package Development.
We have to maintain our own distribution, and customizations.. it's good to have a fundamental understanding of atleast RPM, or dpkg.
What scripting languages are you familiar with:
I want to see a good base of atleast some bash, tcsh, or other shell stuff. Quantify your experiene.. "I created a easy set of scripts to do user maintence of a NIS server"
The next part I had to do for comparative uses. buzzord bingo.
Name the acronym, and it's use.
NFS
NIS
DNS
DDP
TCP/IP
TeX
PHP
SQL
stuff like that.. I'm trying to get out key phrases to quantify the persons experince, and from their reaction, I can easily guage their knowlage.
example.. lots of people have worked with NFS, but the people that only just mount filesystems, and pretend it's all seamless are missing out on some fundamental understanding.. the guy's that mention NFSv2 NFSv3, and having to beat a solaris server over the head so it can talk to linux are the guys that are really going to know what their doing. it's all about the details.
Describe and list the daemons used for:
SMTP:
HTTP:
FTP:
I'm trying to find out what kind of variety a person has.. and this section will also pull out religious tendancies.. like sendmail bigots, qmail bigots, etc etc.. When working in either a closed source unix, or an open source unix.. it's good to know where you're code came from.. and if the guy doesn't know the difference between wu-ftpd and proftpd.. you might run into trouble.
the last section.. (of the technical side of the interview) is to present a situaion, and guage their knowlage of business processes. here's what I asked.
The department needs to purchase 12 identical linux workstations, for general use on the network.. what factors do you consier in how to spend the money.
A lot of the people I interviewed went strait into technical considerations.. some went into "who's it for".. and only one that I remember asked "what are the existing vendor relations like" there is a lot to consider when you're expanding a network infrastructure.. and diving into buying parts for you're favorite platform is the _worst_ idea.
the other half of interviewing is just trying to pull the guy's work habbits out of him.. being able to pull the bullshiting from the real attitude can be tough.. but the right set of standard interview questions will get you there. just be honest.. if you hate getting up in the morning, but will make the extra effort to be at work on time.. say it. let your overall qualifications stand for themselvs.
"How much does the Washington Monument weigh?"
You shouldn't care if they get the right answer - what counts is their reaction to the questions, and their thought process coming to an answer.
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
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? --
As a programmer, my goal is to hire someone at at least as competent as myself. As an expert, its easy for me to spot such a person. However, most organizations I have worked in have had only one or two sysadmins. You may not have an expert sysadmin around to evaluate if a candidate's response to a tcpdump question is valid.
So, my quesion: How can a non-sysadmin interview a potential sysadmin? How does a startup find a good sysadmin, or a good lead programmer if no one there is an expert in the field.
One possible solution is to have the last person to hold that position involved in the interview process. But if you are getting rid of a poor sysadmin, you are likely to get another poor sysadmin.
We usually interview in teams. Each member of the team comes up with 10 questions or so ranging in difficulty from very easy to impossible (or at least improbable). We try to avoid "memorization/certification style" questions (eg options to ls) and go for problem oriented questions (although there are some OS specific questions as part of the process).
...
At some point after the "get acquainted" part of the interview we start the technical part. The team members will start asking questions that escalate up the difficulty chain until they simply can't answer the questions anymore.
Purpose number one is to find an approximate level of technical skill. The second major purpose is to find out how they handle stress. Sysadmins need to be able to operate efficiently under very high stress loads. If during the interview they remain clam and composed even when they don't know the answer, they at least have a chance at handling the normal work. If they fold during the interview they probably won't handle a raving user very gracefully.
For these purposes, the particular questions are don't matter much; anything that will stump them will do. The other thing we really ask about is their home system and what sort of work they've done on it in the past. People who are sysadmin material will usually expound at great length about all the tweaks they've made to their systems. Sysadmins are compulsive tinkerers; even those with little experience or those who have left the field can't resist the urge to make the system behave as it's *supposed to*. If the candidate turns it on and forgets about it
Finally we throw some real life "difficult user" problems at them to see how they deal with the situations. This tells us how quickly they think on their feet when there's no technical answers to the questions, and how far they'll go before looking for help. This is one of the realities of the job, so it's a good idea to check for it during the interview.
This process has generally worked pretty well. It's still possible for people to sneak through, but you at least eliminate the candidates who are obviously not right for the job.
We start in the cubicle and have them talk about their current and past job. The kind of things they did. The kinds of machines they worked with. The kind of environment it is.
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.
Depends on where you've been and what you've been doing. Personally, I don't sit around memorizing crap I don't use on a daily basis. If I've had to do something recently, I can probably give you an answer on that subject in detail, but if it's something I did a lot of last year but haven't had to deal with in the interim, that doesn't mean I'm not competent to do it--just need to refresh my memory.
Granted, there are people out there who have all this at their fingertips, and by all means if you can find one, hire them. But I don't think that "I have to look it up" is necessarily a bad answer. Maybe in your particular situation you had to have someone who could do something specific the next day, but frankly, I'd rather hire a generalist who can do other useful things in the future even if it takes him a couple of days to get up to speed on the current project. I look for the ability to pick things up, because the one constant in this business is change, and just because someone has the flavor of the day down, it doesn't mean they're going to be able to adapt to what happens next week.
No relation to Happy Monkey
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.
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?"
....
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
The only thing worse is a company that asks you to come in to work for a few days, without pay, to 'see if you are a good fit'.
I've been a corporate employee, I have been a consultant, and asking me to solve your operational problems or spend a few days working for you isn't part of a job interview, it's a very short consulting gig- and should pay accordingly.
Trying to get job candidates to give you for free what would cost you thousands of dollars from a consulting firm is a slimy and unethical interview practice, and should never be tolerated.
Unfortunately, I don't know of any way to refuse these requests without ensuring you won't get the job- no big loss, who would want to work for a company that behaves in such a manner?
I do not deploy Linux. Ever.
I walk on interviews like that. Those people aren't asking you for answers, they are asking you to read their mind. Unless you're psychic, you're never going to make them happy. The job's not worth it.
No relation to Happy Monkey
when my brother went in for his interview they set up a couple macs with some problems (they are an all mac shop) they expected to take a couple minutes (plus some time to figugre out the setup). My brother got it in 5, and the way he described it I would have found it too, even though I've not touched a mac since 7.5 was the latest macOS version. Of the other canidates, one seemed good on paper, but his problem solving skills proved he had no clue as he spent half an hour doing nothing over an over again. the other canidate tried some stuff, and ended up messng up the system so baddly they couldn't figgure out what she did despite spending an hour on the machine after she was gone.
what that proved was problem solving skills. The first guy obvious was out, he had no problem solving skills. the last canidate was better, and at least tried some stuff - if they could have figgured out what she did wrong they might have hired her - at least she tried even if she was wrong. Getting a canidate who got the right answer though tilting things slight in his favor, and since up to this point all were close to equal he got it.
What someone knows on paper is different from what they know. Give me free access to the net, root on a few machines (different OS even), and I'll set up NIS+ one them, or at least have made enough progress that you will be convinced I can do it, even though i've never done NIS before. I'm not unique, nor a particularly good admin. I just have some problem solving skills that work well with comptuers.
Set the candidate down in a chair right next to an excellent set of documentation material, like a UNIX command reference. Put the book on the desk if you have to. Turn it so it is facing them. Then ask them about one of the most obscure options on some command. Be careful not to phrase it like you are asking if they know the answer. Phrase it more like "How would you find out what the option to .... is?". Tempt them to pick up the book and look.
Not even the book authors memorize everything. Sysadmins may well learn a lot on the job, but there will always be something that happens to be what they don't use all that often, if ever at all. The good sysadmins will know how to look it up and won't be afraid to do so. You probably don't want to hire a Prima Donna anyway.
The above should also apply to programmers, although the questions will differ.
now we need to go OSS in diesel cars
2. Delete the objects in the following order: (1) Queue, (2) Queue Server, (3) Extended Schema
3. Create the objects in the following order: (1) Extended Schema, (2) Queue Server, (3) Queue
4. If Multiple ARCserve/IT host servers reside in the same NDS container, they will share a common Queue Server object.
Of course, by the time I got to step #4 I had already performed step #2. Doh! Ended up reinstalling Arcserve on 4 servers (and learned to read all the instructions before starting next time :)
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.
Are all your base belong to us?
You've got mail. Pattern baldness. - Crow