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... :)
Depending on the level of administrator (jr. vs. sr.) there are aspects of an interviewee that are important, aside from the abc's of their technical knowledge.
.bashrc or .tcshrc) If you have an unlimited budget, how would you do x.
As the most sr. of engineering staff w/in our IT department, I actually try to get the other sr. admins to cover the "do you know how to..." and "what would you do..." questions. I usually interview last, and focus on the more ephemeral aspects of what we do.
I try to dig down into the person's problem solving skills, to see HOW they work. What web sites do you refer to when you don't know something (if they don't use many web sites because "they don't need to" the person doesn't have a grasp of what the DON'T know. What tools do they use on a daily basis?
Fun questions play a big part of the process to...Name a few files that are in your home directory on every machine you work on (besides your
The single most important question I ask myself about any candidate is "do they get IT." Do they have the basic understanding of how stuff is supposed to work, and can they figure out when things are working wrong.
It's easy to tell if someone knows how to use ls, or install a linux machines. The ABCs are easily definable. It's the less quantifiable capabilities that are far more important to me in an a potential administrator.
In relation to this question of how to interview someone for a SysAdmin position.. how do you *become* a sysadmin?? I've had a number of programming positions, I am very farmiliar with windows and *nix systems. I use Linux all the time. BUT, I don't have any experience in maintaining a network other than a home network. At the end of the day I think system administration is the sort of thing I would prefer to be doing (interaction with people, new challenges on a frequent basis, etc) rather than coding java all day every day but I don't know how to enter that sort of field. How do I market myself as a SysAdmin? Where can I get (real world) experience? Any suggestions? "I don't want the world, I just want your half"
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.
Depends on the systems to be administered I guess. For Windows NT I suggest the following: Q:What are the only 3 keys that a keyboard requires? A:CTRL-ALT-DEL Q:What keystroke combination (Hint: 3 Keys) will magically fix and Windows NT server? A:See above...
Depending on their answer, slashdot, activewin, theregister, betanews, macworld, or the msnbc technology section!
And what's to stop them from lying?
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.
Yeah, I had pretty much the same thing happen once for a programming position:
Company Owner: (first question after the small talk) "So what languages do you know?"
Me: "Well, in approximate order of how much I like them, there is perl , and"
CO: (big smile) "Cool, we really need a perl guy. How much do you want?"
That startup ended up dying out from under me several months later, but it was a fun ride on the whole.
News for Geeks in Austin, TX
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?
Great moments in interviewing, part 7: Q: Do you like children? A: Oh, yes, they're so wonderfully soft, and they smell so clean, and they're so innocent, as they look up at you with those bright, inquisitive eyes as you slowly guide your... I'm sorry, could we talk about the network topology some more? For the humor impared, this is a joke. Similar to the "Why do you want to be a babysitter?" "Because my master, the Demon Lord of the 7th Pit of Hell has so instructed me. I do not presume to know his reasons." one.
Vintage computer games and RPG books available. Email me if you're interested.
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
Yea, and when you find someone with a lot of characters behind their name, kick them out the door -- unless those characters are CNE or Cisco. :) AFAICT those two are the only certs worth having (can you still get a CNE?). All the others (A+, MCS?, Linux, etc.) are just used to get money from unsuspecting geeks.
KangarooBox - We make IT simple!
..although not necessarily work-experience..
.....
Asking someone what was their first computer usually gives a pretty decent picture about how serious they are about computers.
Valid answers: TRS-80, VIC-20, C64....
Invalid: Pentium 100
"This year"?? I think you missed the point!
This jew will wait.
Here is a list of some other 'inappropriate' interview questions: http://www.sunfeatures.com/inapprop.htm
I do not deploy Linux. Ever.
... just tell him/her to pretend you're a end user ... and that you just asked for help with your password ... if the candidate spits in your face, you hire them.
LOL!
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 :)
(You aren't in the Detroit area by any chance? ;) You see, I'm an uncertified sysadmin looking for a better job. I've served as the entire IT department for this shop for the last nine years. At one point, we had close to 100 windows/DOS boxes and three dozen UNIX stations (of varying flavors- IRIX, HP-UX, Solaris), and also half a dozen servers of UNIX and Netware types, but no NT (thankfully!). Nowadays, however, there are two people who do work on the computers here. There's sixty workstations in the next room that haven't been turned on in 12 months. Server utilization for the past year is probably around .00001 percent.
Anyways, it's been my experience that problem-solving skills are the most important trait that a sysadmin can have. There is simply too much information to memorize, one needs to be able to work on and repair systems without knowing every little detail of them.
Example: way back in 1993 or so, we needed some disk space added to our Solaris workstation (leased from/maintained by EDS at the time). We had a couple of SCSI disks laying around, so I mounted them in an enclosure, and called the EDS field circus to come out and set them up. They came out, and were completely buffaloed by the fact that the disks we had weren't on the list of whatever utility they were using to set them up. I suggested that they could select 'custom' (or whatever it said) put the C/H/S numbers off the drive and set it up that way. They refused. After they left, I set it up anyways.
Mind you, I had never installed a disk on a Solaris machine, ever, at that point. I had never attended any classes regarding that system. I was able to get the new disks set up and running, and listed in the /etc/fstab, just using what I learned from watching them wrestle with it for an hour, and my own problem-solving and reasoning skills.
Another example: I once helped a friend repair a diagnostic computer for a car dealership. This was a peice of test equipment that hadn't been supported by the dealer's support network for about four years, but they wanted it fixed because it worked with some of the older cars unsupported by the newer versions of the SBDC (Service Bay Diagnostic Computer). It was a 386, with a whacked out architecture, packed with proprietary data acquisition cards, running OS/2. The hard drive had failed. My friend, being the packrat that he is, just happened to have a hard drive of the exact model to replace it with (amazing, since it was some sort of HP/Quantum dual branded drive of 170M capacity). He also managed to get a copy of the system install CD from someone in the dealer's support network: "I can't help you install it. I can send you a boot/install disc, but after that, you're on your own," he was told.
So, after we replaced the hard disk, we discovered that the CD-ROM drive wasn't working, either. Of course, this CD-ROM drive turned out to be proprietary as well, with some kind of odd connector on the back. It was designed to allow mechanics with filthy hands to be able to change CDs without getting them all grubby. Since there was no way we were going to find a replacement for this drive, I tore it down, and cleaned the lenses with a q-tip (everything in that box was coated with a thin black soot), lubricated the mechanisms, and slapped it back in. It worked. We were able to install the OS back on the thing, and get the dealership back up and running with one of the only three remaining operational units in the state (so we were told). This from a couple of guys who knew nothing about the strange proprietary equipment inside the case, and nothing about OS2.
It's all about problem-solving and resourcefulness. The job is, anyways. The interview, sadly, seems to focus on useless minutia. "What are the command line options for tcpdump and what is it used for?" Beats the hell out of me, but I know that I can find that out by typing 'man tcpdump'. If the interviewer is more interested in what I've memorized and what certifications I've purchased than what I can actually accomplish, well... they're wasting both our time.
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.
Someone once said to me, its not what you know, its if you know where to find it.
If we don't make light of everything, we are just stumbling in the dark - Blank
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
Take a peek at the current network he or she administers. Use nmap, netstat, and the like to get an idea of how secure the network is under that person's adminstration. The more information you are able to glean, just short of hacking the network and steeping into the realm of illegal activity, the less likely you are to want this person taking care of your network. Did this person even notice your snooping?
Also, ask if someone has ever set him/her up the bomb.
If they don't get it, it's over.
Root DOWN
grep what -i sed ?
-
What happens when you boot a sparcstation over the network?
-
What happens when you telnet from one machine to another?
Questions like those reveal the technical profile of the candidate pretty quickly. "Oh, he/she is a strong network person", "knows a lot about *nix internals", "really understands the hardware", "is totally clueless".Dig deeper into the topics which are important to the job at hand, and about which the candidate seems knowledgeable.
Refer the candidate to another interviewer if it's clear that he/she knows more than you do.
(This question is also wonderful if you're hiring highschool computer teachers. There's nothing more hilarous than a roaring classroom after the teacher innocently typed http://www.whitehouse.com into his big screen browser...)
...to the No Shortage of Programmers article.
on this file I send you?
DataSquid.net, a little about me.
Agh! Anybody who clicks on this guy's sig link (the second one), watch out for pop-up ads!
/.? :)
Didn't we just have a very anti-pop-up-ad discussion on
h0w d00 j00 d0? if they dont answer something similar to "jU$+ f!n3, j00? they dont get hired
it's -t buddy. Also xyz is the most useful package to have on a production server of any kind. Anybody running a prod system without it deserves to be given an sgi enema.
Someone capable of handling a Linux UT server deserves the job ;-)
- Daniel Vogel, Programmer, Epic Games Inc.
?They leave knowing everything to 31337 Star Wars obsessed Linux jerkwads on slashdot.
I take offense to that statement.
Paying taxes to buy civilization is like paying a hooker to buy love.
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.
...is how interested the candidate is in working with and for the users. Lots of good questions have been posted so far, but listen carefully to how the candidate answers them to judge his/her feelings about users. Any ape can learn to run a server reasonably well, but it takes a whole other, and much rarer, set of skills to work effectively in a job stuck between mgmt, technical limitations, and user demands.
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
a good friend of mine told me a log time ago 2 qustions ought to be enough
1) do you like to be called a nerd
2) do you have a network at home
both answers should be yes ofcource.
the later questions should also be changed during time. nowadays every win-me boy [m/f] has a network at home, so you might want to change this towards
"do you have 802.11b at home"
or "do you have more than 1 os at home"
just my dime
-- for undocumented cisco commands, take a peek @ dotu
Tell us more, Mike!!
Best of all would be to have a savable white-board so you could compare diagrams latter. But regardless, this is a very cool idea, please mod up.
I think most interview questions should allow or even require use of a whiteboard, they're such a perfect tool for colaboration and visual learners.
Ahah! I had a physics teacher in college that also posted the equations on a sheet of paper included with the tests.
:)
Fortunately (or unfortunately) he also listed the equations in the EXACT order that you needed them.
And the thing is, after you've fixed the problem, for about 15 minutes, they care. And then they go back to forgetting you ever exist. Until the next problem shows up, and then they suddenly notice you exist again and want you to fix it now, now now.
Actually it's worse than that. When there's no crises, they're constantly making you justify your own existence. Why do they need you when you aren't doing anything, etc.
And that pager, you can't get rid of it. It's like that little bell you see in some old cartoons, where the servant is at the beck and call of his master. I got really tired of being oncall and working at 2am on a saturday morning.
I finally figured out that all of support sucks, and that most companies treat their development people better. So I ditched the root password, forgot the mount command, and started writing C++ classes. I haven't looked back since.
LOL!
If a programmer ever said that to me, I'd put him outta his misery.
And people wonder why I keep a bat in my office...
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.
It's important that an interviewer know what they are talking about. I interviewed a few months back with a VP, about a position, and he liked me so he needed someone "technical" to interview me. I went in again, and spoke with one of the admins. You could tell this guy was on the lower end of the food chain. He dealt with NT boxen in a mostly AIX shop. He started to ask me questions, I got all of them right exept for an NT question that he told me was incorrect. I knew I was right, as I had been reading up on this crap for tests. I didn't want to correct the guy, so I just let it pass by. When I went to my car I realised I had an NT exam cram book in my front seat, so I drove home, and looked it up... I was right... I figured I would get this job with out any problems... It turned out they never called back.. Oh well I figure, if that guy would be my boss, then I woudl probably have to cover up for his shit all the time. The problem is that most people arn't qualified to interview technical staff, and the ones who are, have to much work to do.
What do you have to do to change the Hostname of a Solaris box without using the GUI?
(Hint (that should not be given to them!): You have to change it in two places.)
-Tom
Sir, as a seasoned UNIX sys admin (2+ years of hardcore stuff, including firewalls, and net security), I can not think of a more ambiguous trick question to ask a candidate. If I were interviewing for a position with you, at that point I would most certainly ask you to clarify your question, and I would also be considering thanking you for your time and walking out the door. You do not give an answer in your post, but one could answer something like "regular, symbolic/hard link, socket, pipe, block, character, directory..." or "readable, writable, executable...". If you're looking to find out how resourceful candidates are by trying to throw them off and see how much information they can memorize, I believe you are on the wrong track for hiring a successful candidate. A good, skilled system administrator's primary strengths lie in quick assimilation of information and resourcefulness, as well as being able to "clean sysadmin", not in memorizing tons of information. After all, manpages will be at my fingertips, and so will the internet!
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.
Where on the start menu can you click on tcpdump?
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.
What is a LART, and when would you use one?
I have been hired many times....wait that's off
topic.
I have had some experience being interviewed, and I have been hired over many other applicants who are more experienced than I am by just being honest. Perhaps an interviewer should test for that?
I once had a group interview where the MIS manager, and director both asked me questions. I was up against 3 other applicants who had at least 5+ years more experience that I did. I was hired shortly after the interview for 2 things that I said:
1. Q. When the manager asked me if I had ever worked with ?
A. I replied no, but I have been keeping up with the technical notes and articles about it. I've worked with similar equipment, and I feel I can adapt quickly. If I get in over my head, I'll be the first one to let someone know.
2. Q. When the director asked me the last question: If there was one thing you could say to convince me to hire YOU, what would it be?
A. I said: "When you ask my manager how the sysadmin on this site is doing....he will actually be able to tell you.
sweet gawd.....can you post a link to the answers to those questions or something? I dont want to cheat your test, but i would like to know some of that stuff.
|---------------|
practically an AC
If your candidate on question 'what is netmask for 10.0.0.0/26' would ansewer 'I don't know but I'll read documentation on this and I'll sure will know', would you hire him?
Alex
I once saw a great opportunity in my area. It called for a Linux admin with firewall and security in mind. I sent some emails, made some phone calls and was treated as though I were some schmuck off the street with an MSCE coat and tie. My very well written and polite emails were responded with one line answers pointing out things I'd done wrong. (I didn't know how to send a resume to a company asking for Linux help. Turns out they wanted Word docs just like everyone else.) I quickly stopped any correspondence with them and looked elsewhere, even though the job sounded damned cool.
Bottom line, treat them as you would a current (good) employee or friend. If they answer your question with some questions of their own trying to get more information, they're interviewing you and the tables have turned. Respond to them in a manner that you would want them to respond to you.
Place witty comment here.
Ok if you're going to "ask her about backups" you might as well ask why "womanhole covers are round".
What if she's a man?
Have you ever had to involve Verizon/BellSouth/US West/etc in order to fix a problem? If so, how were they to deal with?
If they say anything positive about the telco, they are outta here faster than you can say "Paper MCSE".
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
I usually also ask them how to troubleshoot a problem, as in my experiuence.. that has to be the hardest thing to teach.
Lastly .. I always ask them to ask my peers and my associates and my boss what _I_ am like and what the environment is like so that they come in with eyes wide open and all the information at hand to make a good decision. Their decision to work with us is just as important as our decision to hire them.
"If you are falling off of a mountain, You may as well try to fly." -- Sheridans Father
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
Or to quote from a post from the current poll, the question should be phrased, "CowboyNeal?".
--- if y cn rd ths y cn gt a gd jb n cmptr prgmmng!
Red Shift: a distant light source moving away from you appears more red; due to the dopplar effect the lenghs of the waves becomes elongated, thus more red (red's wavelenght is longest of visible light)
Wake Turbulance: as a solid objects passes through a fluid medium (think wing through air), you get high pressure under the wing, and low pressure on top, and the fluid spirals as the high pressure fluid tries to move up to where the low pressure is.
Distance Formula: d=sqrt( (x2-x1)^2 + (y2-y1)^2 )
Go green: turn off your refrigerator.
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
freenet:KSK@Microsoft_Windows_CE_3.0_source_code_w ince300.tar.bz2
o mm ander.2000\fo-sc2k.zip
( Pr ofessional)_l3codecp.exe
w it h.SBLive.Support.REGISTERED-BEAN_-_boss394a.zip
- WO RD+.DOC+format%29.zip
freenet:KSK@\warez\Applications\System\System.C
freenet:KSK@Fraunhofer_MPEG_Layer-3_Audio_Codec
freenet:KSK@\warez\Linux\OSS.v3.9.4a.for.Linux.
freenet:KSK@McDonalds%27s+Food+Recipes+%28In+MS
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.
pop in *nix boot-CD /mnt/evil /mnt/evil/Program\ Files/* /mnt/evil/temp/
mount vfat partition on
cp -r
Or do you really believe that (Windows-E) and your 1337 tabbing skillz would be impressive?
This sig is intentionally left blank
Hope this helps some, I am so sick of interviewing, and I'd like to go back to being the interviewer. I am also however tired of being asked the same, bad, questions again and again. I guess your prospects need to remember that they're socially retarded geeks being interviewed by a socially retarded geek, and that nothing good can come of that
I like music
What does 'rm -rf /export/home/luser' do, and are you willing to use it on stupid annoying tech support nightmare people?
-Ben
Say what you mean, mean what you say! But please know what #$@% you are talking about!
'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.
and should we toss them for mis quoting?
Old timer questions? That sounds like trivia, and I'm not interested in people who fill their heads with the more arcane of useless knowledge since it won't get the job done. The first couple of Qs were good, though.
The salt goes with the tequila that you drink to celebrate taking out a marketoid... ;)
I just want to take over the world...Why does that automatically make me EVIL?
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
Someone deleted /dev/null and rebooted... your pager is going off... what do you do.
It's a Linux box...
No wait... it's a Solaris box.
I thought 7.1 fixed it... make bzImage worked fine on the test box I set up. 7.0 is the stupid one where you have to set gcc=kgcc
I want transparency effects. I want so much transparency, I can see the back of my monitor! http://www.andrew.cmu.edu/
You are right on. I have interviewed a lot of people for sysadmin jobs and myself interviewed in the past for jobs. In the past when I interviewed I made the mistake of asking people too specific questions... while you may get the answers you are looking for that is definitely not a fair gauge of how good the person will be.
Situations are the best thing to ask about and not really things related to sysadmin. Ask them questions about cars, planes, boats, trees. Get them to show you they have a real base of problem solving skills. Most admins don't and can only parrot back things they have already learned. While they are useful for doing their jobs, it is these people that crack under the high pressure situations.
Also when I interview people I am overly candid about my views on the company, the people and my opinions on text editors and OSs. You need to see how people will reacte to opinions that don't mirror their own. Because a great deal of sysadmin work is dealing with problems created by people higher up who don't/won't understand the underlying technology.
--- I do not moderate.
I know from personal experience the (lack of) value to be found in the piece of paper a burgeoning sysadmin totes with him/her everywhere they apply for (not so) gainful employment.
My first questions are usually _really_ basic ones (e.g., "foo" part on your server or workstation isn't functioning; what do you do?). If the answers I get back are in the category of applying the latest service pack, they can walk back out the door just as quickly as they walk in.
Being an IT professional is, IMNSHO, more about problem-solving skills and thinking "outside the box". I can hire twenty people a day who can recite the OSI model from their CCNA prep book. What I'm _really_ looking for is someone I can trust to SOLVE PROBLEMS!!!
+that's funny...I don't FEEL tardy.+
Easy. Tell them to take an on-the-spot BrainBench certification for Linux Systems Administration.. If they score 3.00 or higher, hire them. Anything less and they're probably clueless.
Bowie J. Poag
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
His views in security, how often and where he checks warnings would also give you an idea if he's willing to keep up to date with his tasks or just with his bank account :))
In fact, I agree with other posters that it's infinitely more valuable to have somebody that doesn't claim to know everything, but rather has an idea and knows where to look for it.
Linux *is* user friendly. It's not idiot-friendly or fool-friendly!
Funny, my first thought was "Where can i get a copy"
Reboot macht Frei.
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
Sounds like questions for game programmers, not sysadmins. (Yes, I know the original was meant to be sarcastic.)
A fairer way to gauge a candidate in this respect would be to ask "If you were asked to do X, how would you do it?"
Easy: Always Murdock.
Not only because he was crazy, but also due to the fact that he managed to create a time machine out of an old fridge, some corrugated steel and an oxycetelin torch, and throw himself 500 years into the future.
Good work fella!
A friend of mine would ask his candidates how many 3 or fewer letter unix commands they could name in 10 seconds. If they started out with, "uh.. DIR", they would get the boot.
it's a sig, wtf?
Bah! Real men use root exclusively and don't waste their time "sudo"'ing or "su -l"'ing constantly!
In all my years of running as root and not some lame user I've not once had a serious screw up that couldn't be fixed with a few minutes of greps.
BAH!
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).
"Nobody ever got fired for using Bob!"
DO NOT HIRE FSCKING JOB HUNTERS (i will not repeat this one)
:)
do you mean that one should not hire people who are unemployed and actively searching for jobs? or do you mean that one should not hire people who are always looking for the next step beyond you, showing that they consider you to be a temporary position?
I dislike people who bounce around all the time, but there's nothing wrong with unemployed folks. during this time there are a lot of great people out on their luck, none of which is their fault or a reflection of their competence level.
I'm guessing I probably misread what you meant there
EOM
... stop looking down at their own shoes first.
"ARE YUO A l33t haX0r?"
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...
When I ask 'Vi or Emacs', I'm not trying to find out which editor they like. I'm watching how they react to the question. If they go on a Holy Rant (tm) then I round file their resume. The last thing we need is a BOFH let loose on our users.
Ummm...What's a 'sig' for?
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
Shalom.
would be system admins and network technicians at least once a week. Most of them come from our local community college which is a Windows school (and buys nothing from the community, btw). Our first question is always the same: "Name three operating systems NOT made by Microsoft". You would be amazed how many wanna-bees fail.
No one ever had to evacuate a city because the solar panels broke!
I don't think that is a good question for sysadmins. Some of the most baffling problems I've worked on have finally been fixed by changing one line in a config file and HUPping.
Sticking a couple of lines in named.conf doesn't sound too impressive as "the most difficult thing I ever did" but it might have taken a day of debugging, chasing down blind alleys and trawling mailing lists to do it.
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.
Actually, with sufficient provocation I could probably quote the whole ad. I should just go lie down until this feeling passes.
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.
high karma is low...
a link would have been helpful, dont you think?
Skill / hiring test one
Skill / hiring test two
--Moo
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)
Some of the biggest morons I've ever worked with had 4.0 GPAs from places like CalTech and MIT. Some of the sharpest had no college education at all.
here.
Linux *is* user friendly. It's not idiot-friendly or fool-friendly!
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:
Having worked with several failed dot-coms as a consultant, I strongly disagree. Anyway, arent pretty much all dot-coms failed dot-coms these days? When we built the system, we planned on having it running for years and scalable to the traffic we were hoping to get. Its not the engineers fault that the company didnt make any money - the systems worked fine, it was the whole dot-com business model that was flawed. Also, I've known engineers working for Fortune-500 type companies who go home promptly at 5 every day. At least with former dot-commers, they know what it means to do whatever it takes to get a problem resolved.
The problem with SA's are they are a haven for people like you who get neglected in the real world but are kings of your castle in SA. I work in SA and i hate other SA's like you. To set the record straight, implementation skills can vary but whats underneath the hood is what counts. If you hire a sysadmin with a BS degree in CompSci, he is going to be better than the hoodrat up the street (unless he is edgy and hungry). Your file type question can be interpreted in many ways, most people interviewing would just think you are a wierdo for asking a question like that. Get out of your hole and realize that your bad looks have nothing to do with knowledge, and that normal people are not clueless. Some focus on other skills other than the ones in your small ass world of your specific blend of SA. Sun SCSA Perl Coder Pretty and still get chicks Had the childhood you wished for See how it balances out? Thats called life
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?
If the code is truly ugly, a competant person would question WHY the code is so ugly, and decide not to work for you. The "tribunal" is a way to find how people react under certain types of stress, but tends to alienate good potential candidates. If their job is to be routinly in a tribunal like setting (sales engineer), it may be appropriate, but for a sysadmin? Please.
- 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
Having interviewed more folks than I care to remember for a bunch of positions over the years, I've given up on asking almost anything that can be answered with a quick glance at the man page.
Lets face it, a sysadmin almost always has the man pages at their fingertips, so who cares if the person knows what flag to tar will produce a listing of what is in the archive.
What I am looking for is a conceptual understanding of the system. How do they work? what is their problem solving method? Are they a 'hacker' in their problem solving methodology or do they take a more scientific approach (and change only one variable at a time and retest)? (give you a hint, hackers are great in the development lab and the last thing that you want in a production environment)
I also look for the ability to understand how a group of systems are put together and why one would or would not use certain applications based on a given environment. For example, in our env the dev systems all use NIS and are generally wide open (I work in a mostly sun env with a few linux boxen) but production systems never have nis and never run inetd. ssh and the server application itself are the only things on those systems. If some sysadmin walked in and installed package xyz on the production systems cuz it is 'cool', they'd be shown the door real quick.
I tend to be a bit biased toward folks with a degree simply because it tends to show the ability to organize large amounts of information and stick with a task (that said, I'll substitute 4 years of real world experience for that degree). I also tend to prefer folks with degree's in the practical hard sciences (chem, physics). Comp sci degrees are nice but not of any importance if the person knows at least 3 other computer languages.
overall, I look for somebody with good organization and problem solving skils. If they have those then the rest they can learn on the job fast enough.
Well, I only know that MCSE (NT4) can be taken by 14 year olds w/o a network at home... I'm not too sure about any Linux Certifications but, I imagine that its different. Win2000 MCSE is actually pretty hard, I know people who passed the exams before but, misserably failed 2000.... Just a thought. - Mick
There is loads of highly concentrated wisdom in here
See even I need to learn to spell
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?
As my previous employer used to say, "Hire on personality, train on skill". I agree that any sys admin you hire should have a general working knowledge of Unix, NT, or whatever OS you expect them to admin, but not everyone is proficient on all platforms.
Personality is a big deal. How does the person interact with you during the interview? Do they have a sense of humor? Can they actually hold a conversation? The job skills can be learned either through your help on the job, or through training courses but if they can't communicate or work well with other, move on!
Just my $0.02
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.
This is brillant :)))
I'd add have they been convicted of road rage? if yes, hire them :) explusion from an anger management course would aso be viewed favourably.
If they can't recite Monty Pyhon verbaitim, they should be put down, it would be a mercy killing
*****a man without god is like a fish without a bicycle*****
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.
For a mid or Sr. level sysadmin, I like to ask:
"A developer demands that he have the root password on his desktop system. What do you do?"
I'm looking for him to ask, "Why does he need the root password? What does he want to do?" And eventually, after I give him some need for root access, "I'll explain sudo to him, and tell him to use that instead."
If they say, screw him, he doesn't get it. I ask "So, what's the first thing that developer is going to do when you leave his office?" of course, dick developer is going to break into his machine, so we may as well give him sudo to do the things he needs to. At least that way we can keep an eye on him.
I also like to throw in "Why shouldn't a developer be able to install new versions of libraries on his system?" If they know the answer, they've worked in a dev environment before. (answer: Because Dick developer is going to install new libraries that support calls that the approved ones (on the build system) don't. Then when his code is merged, everyone is looking at lost-time and headaches)
"We are not tolerant people. We prefer drastically effective solutions"
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?
Everything else you can usually find on the island (shade, moisture from various places, firewood for signaling, etc).
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.
...always a question worth
And what do you do if you find one?
What do you do to prevent them?
"When I am in charge, every mission is a suicide mission" - Captain Zapp Brannigan
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.
Did you read their handbook? It's mostly an outline -- only fleshed-out up to section 1.2.5 (long before the outline addresses the issues raised in this article.) Maybe it will be a useful link after they've actually written the handbook.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
I have absolutely asked questions I didn't know the answer to in interviews. If you get an answer you have solved your problem AND located your new hire.
Why? Because the work they did largely didn't matter! Who cared if the servers could run forever, or if the backups were made correctly? The company probably failed before these "foundation" skills were ever put to the test.
At my company, resumes with only dotcom experience go straight to the trash, and people who came from a failed DOTCOM are highly suspect.
wow.... I must be really good....I take naps in my office and read slashdot all day. I actually work maybe 2 hours a week.
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.
Ask him (or her) if they are a paranoid sociopath who hates people and would like to put everyone in jail personally, especially people who are superior to himself (or herself).
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.
Of course one cadet DID pass the test, James Tiberius Kirk, by cheating. He reprogrammed the simulation so that it was possible to win it. I guess that paved the way for him becoming the youngest Captain in Starfleet history (at that time) of the USS Enterprise.
To be a proper geek, you MUST know these things.
Mac OS X and Windows XP working side by side to fight back the night.
'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. /it department
No, that's a help desk monkey, or a jr. sysadmin. A sysadmin keeps the infrastructure servers and/or the production servers running.
That all depends on the size of the company
Don't Tread on Me
... somebody you do not know asked for your advice about some text he wrote?
> If you're trying to find someone to do both, good luck finding
> a good, experienced sysadmin that won't wring the user's neck
> half the time. That's what jr. sysadmins are for.
Well, damn, and here I am wringing the users' necks myself, when all along I should have delegated it to the Jr. sysadmins!
Virg
I usually conduct the interview wearing a tux includng bow-tie and jacket on my top half and a dress on the bottom half, I use this to see if (like all good techs) their acquistive nature forces the interviee to ask about my attire.
Who is CowboyNeal?
just remember that there's a difference between someone who goes to one of those boot camps (usually paid for by The Company) to pass the test and someone who takes a test when he/she feels they have enough knowledge about the subject to pass it. I've seen the guy who went and studied to pass the test, and i've seen the guy who went and studied to learn the subject material. I'd personally only hire the second guy.
Free Webmail
Seriously, what useful info do they expect to gain from these questions?
Overcaffeinated. Angry geeks.
Do a search on dejanews for their name and email address. If there are any matches, the kind of questions they are asking or answering should tell you something. :)
He did not know UDP was from sun ?
Are you a BOFH?
:) [The cosmic kind. Not the /. kind.]
What's a LART?
Do you find yourself calling the people who use your system users or lusers more often? Why? [The answer will tell you the amount of experience.]
How many accounts have you cancelled? ["More than I can remember" is a good answer.]
When a user asks for more space in their account, what is the proper response? ["Halve their space", or "Delete half their files" are both proper responses.]
Was your last boss afraid of you? [If no, not a real sysadmin]
Does the sight of blood frighten you? Annoy you? Excite you? [The latter 2 are preferable.]
Would you mind helping to man the 'help desk'? [If yes, not a real sysadmin.]
Is Customer Service your #1 priority? [If yes, not a good candidate.]
Quick, the server is down. Give me your top 3 reasons. [Sunspots, solar flares, earth's magnetic field are all valid responses.]
I used to sysadmin. Had to give it up due to high blood pressure. Now I program and give my System Administrator fits. I'm not sure if I'm gaining or losing Karma.
Splitting up drive partitions between /var and /home keep users from using the log space... and runaway logs from killing the users. (IMHO)
These questions ALSO probe depth... so do they know what a FAT table is... is a SIMPLE question... but if they know it, that can tell you history
Yes.. some of these questions are dated.. yes .. some are inaccurate.. but they are designed to provoke an answer, which may not be the answer to the question.. but the right one means more..
"If you are falling off of a mountain, You may as well try to fly." -- Sheridans Father
I think you're a little harsh on MCSEs. At least ask people how they got their MCSE. [And eliminate people who went on a course for every exam, mentions practise tests/braindumps.]
Ask how they chose their electives [easiest = boot.]
--
Adam (who teaches MS official training courses, rarely paying attention to the text in the book)
I'm not sure that a hostile approach is necessary for sysadmins. If they don't know what tcpdump is for, it doesn't mean they're stupid. What, it takes a whole 5 minutes to learn? What sort of idiot couldn't learn that if he had to use it?
What I'm tired of is sysadmins who have no fricking communication skills and sit there like a fat fucking lump of shit... maybe if I'm lucky he'll be arrogantly expousing the truths of some sort of esoteric problem.
In general, Geeks talk a lot and I am so goddamn tired of listening to other sysadmins talk about themselves.
Aside from being good thinkers, sysadmins are patient and will work quietly behind the scenes to solve a problem.
That's how we filter them out, at least. We care about tech skills, sure, but if the candidate doesn't shut the fuck up or he looks like he doesn't bathe (a real turn-off if you have to spend time near him), then he's out.
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--
Apperently your former employer had some crippling form of Downs Syndrome.
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.
I was handed a big pile of resume's by HR. I then sifted through those looking for glimmers of intelligence. I of course had to throw out resume's from people claiming knowledge of operating a microwave oven to a girl wanting an IT job, yet putting her measurements on there.
Finally after a couple hours of sifting, I had already narrowed the pool down to about 4 people worth interviewing. Two additional people were added by my boss...mainly because they were getting MBA's. One of the MBA students couldn't describe to me typical top level directories of a unix file system. (ie
My typical questions are as follows:
What technology do you find interesting?
Why do you want to be a sysadmin?
What are your experiences with Unix?
What unicies have you used? Solaris, HP/UX, OSF/1, OpenBSD, Linux?
Describe something that you have done.
How many users were on your system?
Was your system ever hacked?
What are some typical top level directories?
Have you ever patched your system?
If so, how often?
If not, why?
What is your favorite OS and why?
What are your outside interests?
and my personal favorite...yanking a hot swappable hard drive out of a disk array (a hot spare--I had two of them in that array), and watch their expression. If they looked like they just soiled themselves, that was the end of it. If they were like "cool!", then I knew they actually were somewhat interested in technology and would be willing to learn.
Yeah, I'd have to admit most of my questions are pretty basic and almost have no substance. But it was amazing how few people actually managed to make it through just those. Most of the people were clueless and lost with those questions. *sigh*
"If you insist on using Windoze you're on your own."
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
Say one candidate has most of the general skills needed, obviously takes pride in his work, has ambitions and are very enthusiastic about the position, whereas the other is an expert on all relevant topics, has longer relevant working experience, are a bit laid back and has no long-term professional goals.
I'd hire the ambitious applicant any day.
Working is thinking followed by action. If you have extensive knowledge on some topic, you need to do less thinking to do tasks related to that topic. You still have to think, to some degree. The ambitious person, eager to solve the problem, do a good job and get a raise, will enthusiastically push his mental throttle all the way. The expert run dry will give up or postpone the issues as long as possible.
Knowledge is simply the result of having thought about something. A person that knows a lot has a good track record with regards to thinking. But the fact that you were taking good care of your mind five years ago doesn't mean you do today. That's why personal qualities, and especially ambition, is an important element when judging how good a job a candidate will do.
"I swear by my Life and my love of it that I will never live for the sake of another man, nor ask another man to live for the sake of mine." John Galt in Ayn Rands "Atlas Shrugged".
Your questions suck and are variable in answer depending on what operating system context you're using--which you haven't defined. Thus your questions are completely useless. Do you really run all those OS's in your shop? Do you really think that the ability to decode a .tar.gz.shar.uu is an asset? Besides that, what if the file contents are different? UNIX don't give two shits about the filename, and nor do most utilities.
/usr /var and /home directories onto separate partitions is useful when the underlying drive structure hasn't been defined? If it's a single drive what do you save by splitting them up? Maybe /var, but the point is valid.
Not only all the above, but how can you possibly expect to get a decent system admin who actually uses rsh rather than ssh? Do you really think that separating the
Do you honestly think that the ability to customize an xterm (when everyone uses Eterm anyway) is somehow an asset to a decent system admin?
chgrp isn't needed, either--so your questions about "what three utilities control file permissions" is also lame--use chown with the user:group format on systems that support it.
So let me ask you--you only question whether the applicant knows different UNIXen and then ask a lame seemingly DOS-specific question about the FAT table?
What the heck does question #6 in your networking section mean? Usable internally and freely? Or usable on the internet with proper SWIP/allocations?
Your disk controller questions are woefully out of date--the SCSI chains are different lengths dependong on which SCSI controller type you're using along with which SCSI drive types you're using. SCSI U160? SCSI old-style 50-pin?
Your NFS questions are also broken and depend on the implementation and compiled-in defaults. I can enable root access by default on my NFS. Can you? Do you think it matters whether the applicant knows about ypxferd or not? If you're so hot on man pages (in previous questions) then why are you asking application-specific questions in these sections?
Bah. The questionnaire is utter crap. If I ever had a job interview with you (thankfully that will probably never happen) I would smile warmly, shake your hand, and tell you I don't think I would fit in at your shop.
ttyl
Well Ive been working for a paricular law firm for some time now doing basic IT work and looking into doing SysAdmin work after getting out of school, however today my CIO came to my office and asked me why I had a linux box and asked that it be removed implying that it might constitute a comprimise in security to the wonderfully IIS fed network here.
I used the following to initially weed out "cupcakes with shell accounts" versus folks who have done some SA work. It has always served me well.
/OSF1
How many years of Systems Administration experience do you have?
Please describe your expertise level on the following operating systems:
SunOS?
Solaris
Digital UNIX
HP-UX 10.x
DG/UX or any other SVR4 Operating System
AIX
Linux
Please describe your expertise in the following areas:
DNS/BIND
HTTP
Internet Services/Firewalls
Security Tools - Cops, Satan, Tiger, Crack
Sendmail
TCP/IP
Usenet News
What commands have you used to do backups? How about remote backups?
How would you look at the routes on a system?
If you lost your root password or root's environment became inoperable, discuss how you could recover it?
Differentiate between run levels:
0
1
2
3
User information is primarily stored in what 2 files?
Differentiate between physical and logical volume?
List 2 common 'kill' signals and discuss their use?
Discuss a situation where you could have space available via 'df' but still could not write to a disk drive?
Discuss the significance of IP address 127.0.0.1?
How would you look for any manpages relevant to the subject "kernel"?
If you had to migrate 25 users from system A to system B (both are running the same versions of your favorite OS), what are some of the issues you would need to consider in your planning?
That's an absolutely superb technique. No one can know everything about system administration. How to find information, both primary and secondary sources, is vital in any technical field.
People forget: A job interview isn't a test. The person with the most correct answers isn't necessarily the one that gets hired. The one who can do the job best should be.
Never play leapfrog with a unicorn. Or a juggernaut.
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
Do you also believe in Father Christmas?
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
I realize, as a programmer for a large webhosting company, that finding good candidates for each job can be daunting. As a member of the 2600 community, I also realize there's a lot of BS floating around relating to job skill, etc.
Basically... give them a test... think up anything your company might face, that wouldn't give away too much of your security procedures. Make them implement something to stop/fix/help/whatever you've put in front of them. Don't rush them... a few hours if they need it might be a better judgement of what kind of attention to detail, accuracy, etc.
Anything you can do to relax the work atmosphere always helps.. not interviewing the candidate(s) with 2 guys in suits may help them relax and feel more at home.
DO NOT HIRE FSCKING JOB HUNTERS (i will not repeat this one)
Good luck!
"During times of universal deceit, telling the truth becomes a revolutionary act" -- George Orwell
The great thing about sniffit is that other people will, uh, install it for you on Internet-exposed machines...
- This will show if they have a
"screw the user" attitude or have a realization that the user is the job.
It depends on what they're doing as to whether or not the "user is the job". If you're hiring a jr. sysadmin to do desktop support, then yes, that's a concern. If you're looking for someone to run your server farm that handles all your production traffic, then "screw the user!" If you're trying to find someone to do both, good luck finding a good, experienced sysadmin that won't wring the user's neck half the time. That's what jr. sysadmins are for."We are not tolerant people. We prefer drastically effective solutions"
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)
When I went for a admin position, my interviewer had setup a small LAN with some laptops and a small hub. He unplugged one of the laptops, but made sure the cables were hidden. I ended up getting the job because I knew within seconds that this wasn't a software problem and then started tracing cable. What's the point of all this? I know how to BS my way through an interview even though I don't know the material. That's how i got my first programming job. If they would have asked me to write code, I would have been SOL.
Great idea... we do stuff like this...
:)
:)
Actually my favorite is a good test of those skills. I see if they know a programming language (currently perl or C are the only 2 I look for) and pull out my "Really evil code" for that language.
Uncommented, lots of shorthand, useless variable names etc. About half a page of 8x10 paper worth of code. Not obfuscated, but something that only someone with more than "sysadmin" code reading ability will easily get.
Say "Please read this and tell me what it does, its hard code, so don't expect to be able to get it all". Then see what they do.
Do they just stare at it and throw up their hands? Do they miss the stuff that even someone who just once looked at the camel book should get? Will they admit lack of knowledge and ask "what does split do?"
Actually, the least telling scenario is when they are a real hacker and read right through it in 10 seconds. Course, its only ever happened once.
Another thing we like is "the tribunal". Let the manager do an interview, then lead the guy into a conference room with his possible future co-workers. He has to work with these people, they can make quite a good judge.
Just lead in, talk for a bit, then manager makes a quick exit with some pithy remark about "I'll leave so that you guys can all talk freely".
Provides a great time for the candidate to get information about the workplace from the workers, to make sure that there are no personality conflicts, and can make for a great technical grilling
So far, in over 2 years, only 1 person has made it through that process and not worked out here.
-Steve
"I opened my eyes, and everything went dark again"
And don't forget: What is the air speed velocity of an unladen swallow?
If I ever ask about writing kernel modules that talk with Oracle, the correct answer is "That is a really fucking stupid idea."
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`.
Where do you want to be in five years?
My answer in the future: I want to be on the
beach drinking a margarita. Where do you want
to be in five years, here?
Well of course... the code is ugly because its a small little snippit that we like to use to test people with.
:)
Or more specifically, it is because I was bored one night and wanted to see how few lines I could impliment a specific algorythem in, still using proper indenting and lin ebreaking
Its mor ethan just to see how they do under stress, its also to see how they interact with people, and specifically the only people that they will have to interact with oin a daily basis.
-Steve
"I opened my eyes, and everything went dark again"
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.
I've always liked starting with this one: "Name all the fields of the /etc/passwd file
in order"
Plenty of people can name the fields, but you'd
be absolutly amazed how many people get the
order wrong.
Generally after that I pose several "have you work ed with this, have you worked with that", and then I start narrowing down.
The term 'manhole' is realy kind of sexist. Women are alowed to be utility workers too, dammit!
I (and a few other people, obviously) can claim a NULL original Slashdot ID, as there are archived posts of us back when you could type in ANYTHING as your name/subject/URL and it would go in the post.
Being AC wasn't even an issue then.
A sysadmin who never crashes anything is worthless.
-- Sigs are for losers
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 always like to ask how the candidate would kill multiple processes on a solaris box, by name and not pid. maybe httpd. if they answer 'killall', fsck them off pkill , or ps -ef | grep name and pipe to awk to grab the pid and then to a kill is always pleasing to hear.
HR Puke: Have you seen Star Wars?
Me: Of course!
HR Puke: If you could be any character from Star Wars, who would you be and why?
Now, I said "Obi-Wan Kenobi, because he is wise and all knowing and a mentor etc", but I was really thinking "Obi-Wan because he can control people's minds. Now, you want to give me this job, don't you?"
I was a little tempted to say Princess Leia.
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.
... and, presumably, bonus points for low karmas?
James F.
Sysadmin candidates need to be asked, How prepared are you for artificial intelligence and for http://www.ugcs.caltech.edu/~phoenix/vinge/vinge-s ing.html -- the Technological Singularity as described by Vernor Vinge?
make sure the candidate doesn't know anyone named simon...
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.
When I interviewed prospective sysadmins, the one thing I was looking for was curiosity. You have to be able to dig into stuff that you don't understand to be able to do the job and if you're a curious person, you're gonna be inclined to do so. Example questions: Q1. What scripting languages are you familiar with A1. (should be lots) Q2. Which is your favourite? A3. (doesn't matter) Q3. Why? A3. (should be able to articulate answer) To test experience, I ask: Q: You install a new version of a 3rd party closed source app and it doesn't work. What do you do? A: (bad) call vendor A: (good) strace/ptrace If they're arrogant about their knowledge (most are,) I ask some old-time questions, like: Q: How do you get a directory listing without ls, du or find? Q: What's the ed command to do X? Old timers will know the answers. Good new-timers will have been curious enough to explore and find the answers already...
This looks like a dam interesting section but where is the darn artical to read
my 2 cents plus 2 more
-- ac
Ask them what they hate most about their job, if they answer anything but users, they are lying! Actually, there is one thing worse than ordinary users, that is programmers who think that they know enough to sysadmin....
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!
There are some questions they can't ask. Then, there are some questions you shouldn't be asked.
"Please tell me about all the revenue generating products you have helped to produce and explain your role in producing them." Ask that right after you place the coffee cup on his or her various programming certificates. Oh, and of course... "Have you ever been arrested?" asked in your best Officer Obie (sp?) accent.
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.
"foctothorpe and star" or just fock for short.
I don't want knowledge. I want certainty. - Law, David Bowie
emacs or vi? Wrong answer, and the interview is over.
Seriously, though, I wonder how many interviews for technical positions have been for the education of the interviewer on the position's subject matter rather than the applicant... I know I've gone to a few suspect sessions...
Instead of asking specific utility questions present your candidate with a problem scenario and ask them if they've ever encountered the scenario. If they haven't; ask them how they would solve the problem. The IT field evolves so quickly that your new hire must be able to self-find and self-teach solutions to new problems. If your candidate can't do that they will be useless in five years.
-ted
Oops. s/karma/ID/. Apologies.
James F.
Ask them if boxes they have maintained have been hacked and why they were and what they did to fix them...... Friends don't let friends use Microsoft....
Try to make him fit into this: Freshmeat's Egoless Admin
It's probably not only a nice way to admin, but a also a nice way of living...
Think about it!
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
USENIX has put together an extremely effective guide for hiring sys-admins. Check out http://www.usenix.org and look under the SAGE section. Yes you're gonna have to buy a book but you'll get over it.
You know what to remove for e-mail. Don't you?
Ask enough factual questions about the technical items on their CV to establish that they have the skills they claim. When discussing these issues, always say "do you know/have XX" instead of just going by the CV, because agencies often rewrite CVs and they may (well, they do) tell lies on behalf of the applicant that the applicant would not have. So, if is says "foo" on their CV, it may be that they actually know "foobar" and the agency doesn't know the difference. However, if they really have lied on their CV, just put it in the bin.
Don't ask questions like "what is tcpdump for", ask about a situation that they would want to use tcpdump for and see if they "get it right". But don't be too prescriptive. It's sometimes also worth asking "how else could you approach this problem".
Always work from their experience, avoid the hypothetical. If the interview reaches a point where most questions are hypothetical, the candidate almost certainly doesn't have actual experience of the things you want - this is usually but not always going to mean they're unsuitable.
Look for general skills like problem solving, communications skills, can they take initiative (EXAMPLES!), and can they win someone over to their point of view (i.e. if they know a good technical solution to a problem, and one would hope that they would, can they convince people that this is the right approach?). Look for evidence of planning, risk assessment (we can to the upgrade this way, but that's too risky; we'll roll it out that way instead -- very valuable skill). Can they estimate tasks? Do they hit their estimates. Ask for an example of what happened when they didn't (e.g. did they tell their boss? Did they ask for help?).
Can they understand issues from other people's point of view? Are they flexible (look for multiple ways of solving problems), resourceful, cautious, measured, adventurous - can they take and avoid risks, judging according to the circumstances which is the right to do?
Ask simple questions and then hard ones. But don't launch right in, let them get comfortable first. Explain the purpose and structure of the interview, how long it will take and what the result will be. Maybe explain your own job and how theirs will fit into it.
Ask them about your own organisation -- that is, can they do research? Ask them about their own organisation -- that is, do they pay attention to their own organisation.
Look for exampes of how they have analysed their own workplace, dicovered a defect and gone about changing it (or persuading someone else to change it). Work from their own experience. Make some allowance for situations where the candidate works in a shop which is totally different to yours, but also draw a line -- if they have no evidence that they can do what you need, you can't usually justify hiring them.
Ask them what their strengths and weaknesses are. Then ask them what they really are. Ask them why they're leaving, and why they want to come to you.
Can they describe things (i.e. sequences of events or problems) clearly and simply? Do they make sure they understand the question? Ask them for examples; anybody can guess at a good hypothetical answer, look for evidence they they've really done it.
Another poster talked about "fit". It's essential. Can they work in your environment, did they win you over, are they easy to talk to, can they assert their own point of view when this is important, can they give a viable rationale for their courses of action? What special skill(s) will they bring to your environment?
"Linux"
"You've got the job."
(this actually happened)
Omg. *You* should be fired.
"How do you patch and compile a kernel" is a very stupid question. "Why would you patch a kernel" is a much better one.
"What is the CIDR ?", "Are the non-continuous netmasks legal?" Are you sure your are looking for a sysadmin, or are you just playing a dick contests with the candidates, to boost you ego ?
> And believe me, it was rare that any candidate would pass this part.
Of course. Most of the good candidates have already left the interview.
-- Of course I'm paranoid. I'm a sysadmin.
It goes something like this... ask them "A user comes up to you and says that file transfers are slow. What do you do?"
As they ask questions to zero in on the problem, tell them what happens each time (outputs of commands, etc.). Kind of a D&D approach. At some point, they're going to throw up their hands and say "I have no idea". The goal is to keep count of how many questions they asked, how soon they got flustered, and how many different avenues of attack they pursued, which will give you some idea of the depth of their knowledge.
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
The best sys/network admins always have good war stories. Have the prospect tell you about the goofy situations (like a weird IOS bug which only crashes quad serial cards running broken-ring with IOS XX.X) and how they found it and fixed it. Have them tell stories about the dumb users they have helped in the past, how much they have wanted to strangle a certain "l"user who kept coming to them on stupid problems.
At least that should tell you what their technical level is and their experience. After that, you should have a decent idea how they will act in crisis mode (i.e. every day) and how they will trest your users...
B
Flamebait
Serious inquiries only.
Man, you're exactly the kind of prick I'd never work for. Why bother figuring out the netmask for /26 when you can just use a tool like cidr found on most *NIX boxes. Sheesh.
I think he's saying someone who has max karma (which is 50, not 25), sits around on slashdot all day. Which, is probably a good thing because it probably means she is so good at her job there are few problems.
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.
I'd give bonus points. :-)
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.
What do you do now?? What do you do now?!?
/usr/ucb/cc: language optional software package not installed
5. If you had female and male candidates, what would be the reason to choose or not to choose a woman ?
Could you please tell me how the fact that the candidate is male or female, has ANY bearing whatsoever on the selection process?
Hire the most qualified candidate, and be done with it.
Actually, I always counter by asking what is the worst aspect of working for [company name]?
...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!
Are you saying high karma is bad? or low?
"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.
What sort of sysadmin are you looking for NT or Unix/Linux? Or someone familiar with both. Ask if they have any certifications (MCSE, Redhat, etc...) and how current they are. Ask questions that you would be able to answer and throw in a fgew that you couldn't (just for kicks). Another thing to ask is of any programming experience in Perl, Shell scripting... and throw in 2-3 questions on that.
ask how many system problems he's encountered... then more importantly if he was the cause of it ;)
This doesn't seem to have been mentioned yet, but what about looking into a canidates background? Would criminal activity play any role in your decision (obviously not a pot arrest, but how aboud a hacking conviction? What about embezelment?)? Would you consider a criminal background check? What about drug tests?
The biggest thing is that if you aren't an excellent sysadmin yourself, find a nuetral but qualified consultant to help with the interviewing process!
I'm reminded of the time that Mudge from the l0pht (now @stake) told the story of how he did this for a company seeking a security professional, and the interviewee proceeded to tell Mudge how the interviewee wrote L0phtcrack! (For those who don't know it, it is Mudge who wrote L0phtcrack.) Mudge went on to quite Sarcastically tell the Manager he was consulting for: "L0phtcrack is a great program. You should hire him!"
Needless to say, the Manger was quite happy he followed the aforementioned advice!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Personally interviews should be gaged on finding out about the type of person they are not so much on how good they are. Sure you don't want some crack pot in there but IMHO you should never hire the dude that you have to lock in a room and slide pizza's under the door ...god I hate those kind.
Don't hire the geek ...or if you do at least make him/her have some sort of social life.. Because from what I have seen ..these guys just eventually burn out.... I know lots of people that were too damn busy being bookworms all concerned about getting a 4.0 gpa cause they thought that if they get that , it would make up for the lack of personality and backbone. guess where they are now ..still stuck in the trenches miserable as ever..some have yet to find an I.S. job.
The guy that said never have a test I agree...friggin waste of time..
The one thing I think would be cool ..is if you had your interview in a room that had a computer right next to the interviewee turned on with a noticable flaw .. to see if they person would have the backbone to say anything .... I like people with an opinion ..those that go through life with the I don't know style get boring real quick ..
Hire someone that has some personality ...knowledge can be obatained ..
This is in general a very good question to ask anyone who will be in a position to make important decisions and work with things and situations on an emergency basis they have never encountered before.
CAREFUL CAREER MANEUVERING WILL ALLOW ME TO CONTINUE PLAYING ASHERON'S CALL ALL DAY WHILE THE PAYCHECKS NEVER CEASE
The relevant example starts about halfway through.
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
Technically you can learn anything ('nough said on that theme too). Social skills, espescially for a sys admin, not teachable (hardly) and very valuable. This is a service environment, right?
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
If you were a tree, what kind of tree would you be?
I kiss you!
1) How would you implement a backup strategy? 2) How can you prove that you can restore all systems to the same state they were in prior to a catastrophic failure of all systems? 3) Why are manhole covers round?
Ask me about my vow of silence!
Really? I haven't ever heard that before, and I've been hanging out here awhile....can you find me a link to such an archived page?
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.
Wow, sounds like the same people I interviewed at my old job. One of the first things I'd do is check the dummy lights, then the link status (up/down wtih ifconfig). Granted with some of the people who are looking for IT jobs are totally clueless, yet want tons of cash. *sigh*
I have to admit this is a pretty good test...
"If you insist on using Windoze you're on your own."
I ask them about their CV - "I see you've worked with A5200s - what volume management did you use?" - if they give a valid answer to that, I ask them more about that product. If they don't know, I note that, but prompt them - if they've only worked with one, they're not so likely to know what it's called, just that it's the tool they use.
There are certain things we need them to be experienced in, so I'll ask about them, if they don't know, you can normally get a feel for how easily they'll pick it up.
I'll start to ask more awkward questions as the need arises - assuming they seem to know the basics, I'll try to gague their level by asking about scenarios - ones from their experiences, things I've seen, or hypothetical situations.
If they're good with networking, I'll give them some networking problems, if they're good with storage management, I'll go into that.
There's no point asking the difference between RAID0+1 and RAID1+0 if they've never worked with RAID, but it is worth trying to catch them out - good techs enjoy the challenge if you don't try to come over as some kind of God.
Author, Shell Scripting : Expert Re
> If he gives you a bullshit answer, kick him out the door.
Ask him if he ever gets laid. If he says "yes", then kick him out because he's not true geek material.
Sheesh, evil *and* a jerk. -- Jade
It is only a matter of time.
"Describe in every intimate detail every device a packet goes through when going between our New York and LA offices." IN ORDER.
"Tell us about some of your hobbys"
Maskirovka
I may get flamed for this but I always hire sysadmins and DBAs I can order around. Nothing sucks more than a sysadmin who thinks they own the place and gets in the way of work getting done with their fucking firewalls.
I know that NT isn't a popular topic, but none the less some companies still need NT admins. Here is the one question that allows you to gauge an NT admins ability: What is the difference between regedit.exe and regedt32.exe? The difference is that regedit.exe allows you to search the ENTIRE registry rather than just the keys, but only regedt32.exe allows you to change the ACLs for the registry (it also does a better job of editing registries on remote machines - regedit is buggy in this respect). Anyone who has handled any kind of security on an NT system should know this. Anyone who has done any real optimization or troubleshooting should also know it.
You can also ask them to describe some of the things you can do with the net command.
one caveat: I haven't worked much with Win2k or WinXP. This was accurate for Winnt4 and I suspect still is, but I can't guarantee it.
Politics, Culture, Food?
One of my friends went for a sysadmin interview, they sat him down and started. The head guy said "what does lsof do?". "I don't know". "You just failed". And that was that (I'm not making this up, that was his interview).
> Not every sysadmin knows everything
No sysadmin knows anywhere near everything about whatever little corner of the profession they specialise in. They leave knowing everything to 31337 Star Wars obsessed Linux jerkwads on slashdot.
What's the weirdest problem you've ever come across on a network?
It was a good indication of what they considered "weird" and what their approach to problems was. One of the candidates answered that he couldn't figure out how to move his bookmarks from one version of IE to another. So he was right out. He also said he'd was somewhat bothered by users and would tell them anything to "get them off his back". In the interview this is. My boss never stopped kicking me under the table.
The guy we hired answered the question somewhat more eloquently, and talked about tracking down a registry problem (we're all NT here, so we like to hear that sort of thing) by rebuilding it in halves until he narrowed down the problem, rather than just reinstalling everything, which is so popular.
The fact that he worked on a Quake mod and gave us his resume on hemp didn't hurt work against him either.
come for the naked robots, stay for the zombies
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.
The primary purpose of three-phase power is...
a) To increase efficiency at higher voltages
b) To increase efficiency at any voltage
c) To discipline the users
2
Describe in your own words your emotional connection to Halon.
3
Somebody rebooted the router because they felt it was "acting dodgy". You...
a) Kill them
b) Kill them
c) Kill them
D) All of the above
4
Your average daily caffeine consumption
5
State the purpose of internal Web caches. (correct answer == Blackmail)
6
Have you read the (check all that apply): [x] BOFH [x] BSMFH [x] BGFH [x] BHDOFH [x] BAFH
Caveat Emptor is not a business model.
1. How do you choose among candidates, who apply for their first system admin job ?
2. How do you evaluate their "experience" or "education" ? What would you want to see them to bring to the table ?
3. If training on the job is non existent, how do you come to believe that a candidate has what it takes ?
4. Which educational path do you trust most ? C.S. college graduates, or adult education with certification good enough ?
5. If you had female and male candidates, what would be the reason to choose or not to choose a woman ?
So, now when I interview, I always ask what peoples hobbies are. It seems to work pretty well!
We've got a new bloke in the BOFH-cubes downstairs. I hear that he was recruited on the basis of a bunch of equally good CVs turning up, but his standing out because he made weird welded steel furniture.
Last week, a couple of carved-up steel gas cylinders appeared in his cube, with floodlights inside like huge Jack-O-Lanterns. They're new stage lighting effects for some Goth-industrial band.
Seems to have a clue admin-wise too. Maybe you're right about this hobbies thing.
was what they consider "difficult" something you'd also consider difficult?
But in the same vein, what they see as difficult, and what you see as difficult may not be the same thing. He may find what you find difficult fairly simple and vice versa. How they handled the situation, though, is very important.
For example, I might find searching graph objects difficult, and you might find it simple (and even know algorithms in your head), but you may find J2EE difficult, and he/she may be certified in it.
(cheesy examples, I know, but its morning here).
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Beyond grilling the candidate tech and non-tech, if the person says "no" and just sits there after this question, I think you know what to do w/them. Also, ask them a really large question. A user sends mail from A.com to a user in B.com. Tell me everything you can about what needs to happen. This will give a good indication of their thought procresses, level of concept understanding, etc. D'ont worry bout the exact answer but the way the answer it. -john
Let me guess. MCSE?
It seems the hero is misunderstood again - Marillion
Me: Have you read the BOFH manuals?
Candidate: Bite me.
Me: Welcome aboard!
Ask them what they think of an MCSE qualification. If they say that it's a waste of time and they only got it because employers were requiring it, then they're in. If they mention they have their MCSE twice, they're out.
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?
Have you ever implemented or worked with LRF support???
;-)
(LRF = Little Rubber Feet)
System administration is arguably one of the most demanding jobs around, spanning from hardware tinkering over hardcore programming, webmastering, database administration and even well into actual business decisionmaking. And then we havn't even touched upon anything *nix/nux, networking and weird driver configurations. A good SysAdm is the quintessential Jack-of-all-trades.
I do not believe it is possible to draw up a comprehensive list of specific qualifications for a job like that, but raw intelligence, contempt for the concept of "impossible" and total sleep-cycle control would rank high.
BTW, whenever I get into actual makework with a customer, I take considerable steps to befriend the local SysAdm, as this person knows EVERYBODY in the organisation, and everybody (who knows what's good for them) wants to be on friendly terms with the SysAdm. It just makes everything run smoother.
For the sufficiently clueless, even trivial applications of common sense are indistinguishable from wisdom
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.
Sometimes sysadmins cant get their way because of corporate policy (like being FORCED to switch to NT). Ask some questions about how willing they are to switch to something new, or to never be allowed to upgrade.
... the most well-known web site of the Christmas Islands?
From the BOFH Archive:
So I'm interviewing for new Operators, and, as the Bastard System Manager from Hell, I have high standards. And as the Immediate Past Bastard Operator from Hell, I have even higher standards.
I get the first applicant in.
"Ok" I say "I'm just going to ask you some simple questions to guage your knowledge of Computing and Networking in relation to the Operations Field"
"Sure"
"Right. Question One. What's the best way to stop an individual posting nasty articles to news?"
"Close their account"
"Good - But can you elaborate?"
"Delete all their files, Change their password to `Knobhead' and Erase any backups of their account"
"Excellent. What is a killfile?"
"Uh. It's a list of usernames/topics/news items etc that you wish the news- reader to automatically skip so you don't have to wade through rubbish"
"Uh No. Remember I said pertaining to Operations. A killfile is in fact a file with a list of names of people you are going to kill."
"Oh. Of course."
"Never mind. What is DCE?"
"Delete, Close and Erase"
"Good. DTR?"
"DON'T TRY to RING. The Operator's watchword"
"Well done. DBMS?"
"Dont Bug My Supervisor. Probably the most important acronym around"
"You betcha. Ok. A user comes to you with a complaint about another user sending sexually explicit email messages to them. What do you do?"
"Take a copy of the messages, close the complainant's account (by accident) and extort money from the mailer by threatening to show their parents"
"Good. I think you'll do nicely. Hang onto this wire..."
"I don't think so."
"Excellent. You passed the final test. You start tommorrow. Please leave by that door so as not to disturb the other applicants."
BZZZZZEEEERETTT!
Electrified Door Handle. Gets them every time. I think it's the "Complaints Dept" sign that draws them to it like moths to a globe...
I push the body out onto the fire escape.
"NEXT!"
Burn the land and boil the sea, you can't take the sky from me
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.
In the past I have interviewed SysAdmins with questions starting from basics like "Describe some simple backup strategies you've used." Hopefully, they begin with tar or cpio and move on from there. The direction they take is usually indicative of their level of procificiency. Then questions relating to system performance and network performance. Something like what sorts of bottlenecks affect system performance and how would you begin searching for those problems? What I would be looking for is a clear understanding of troubleshooting techniques rather than an "I use vmstat, top, tcpdump, MRTG and NTOP" type of answer though the latter would be a bonus. Often a question or two about heterogenous systems is good - in which ways can one intergrate Unix with Windows in one network. I am NOT looking to hear "SAMBA and X-Servers" rather some understanding of why one would do this. Sharing files, sharing printers, as FTP download sites, running DBs for client front ends, etc. Lastly I try the "do you play well with others?" type of questions which are a bit trickier. Like the original post, real world scenarios are often good here and I generally ask questions like a database hosted on a system which is running slowly and the DBA insists that it is the Unix box which is at the core of the problem. How would you solve the problem? Diplomacy and tack are important answers here rather than raw skills. My favorite, however, and one I save for very last is "Do you have Linux running at home?" I have had answers ranging from "Yes" to "No, Linux is not really stble enough for my personal work." to "No. But I have an old SPARC running SunOS4.x. Does that count?" I would suggest that one can find out if the candidate is really SysAdmin material in under ten minutes but sometimes one should spend some extra time even if the candidate is not right either to learn something new or for a good anecdote. I once had a candidate for a UNIX sysadmin job who could not tell me which file stored the hostname on a Solaris machine. That interview did not last much longer than that.
I like to ask a Unix admin this question:
You have the task of training a new sysadmin in Unix, that has no previous unix experience. What are the first five or six commands you teach them, and why?
If the candidate doesn't mention man in the list there gone - as all commands can be derived from man -k
Slightly off topic, for the PC techies my favorite question is:
List the standard AT hardware interrupts and their use, in order.
Only ever had one PC tech answer this anything like close-to-correct.
I've met plenty of people who are sysadmins (mostly Windows) who have no idea how to write code. I've also met people who can write code very well but couldn't differentiate between a sound card and a video card.
When did the terms programmer and sysadmin become interchangeable? Granted, the two overlap, but in my opinion, they are far from the same job.
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?'"---
"What projects have you initiated on your own?" A good sysadmin will come up with the idea that his mailserver needs attachment filtering or similar things WITHOUT having to be told. The ones who take all the cert classes and/or simply follow the orders of their boss to the letter I have no interest in. A similar good one is: "How many OS have you loaded and played with on your home machine?" The ones who have 98 and never though to try anything else are the same kind of people I see who go through CS classes doing only the required things to get through the class and get a job. No drive at all, no love of computers, most of them.
Unix Hints & Hacks has a chapter or two devoted to this subject. It talks about interviewing candidates, and also about being a candidate. Worthwhile reading, even if most of the stuff in the book is for beginners. UH&H is, I believe, a compendium of best practices collected from Unix Guru Universe.
main(){char I,l,O[]={'-',1-1,0,(1<<5)-1,0+'-',-10-1,-10,11-0,
Any decent sysadmin knows it's a rubber hose. Breaks no bones but causes intense pain...
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."
"The same user called you in for the fifth time claiming his printer is defective. Each time you find that it is switched off line. What would you do to permanently resolve the situation?"
And no, "Shoot the user in the head" is not a valid answer.
When I interview prospective SysAdmins, I simply ask them if they have an MCSE. If they respond yes, then I politely thank them and tell them to fuck off.
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
My faves at an interview:
You have a shell script that runs just fine at the command prompt, but complains when run as cron job. What might be the problem?
You have been given a second nic card for this machine. For (choose operating system) how do you configure this card?
Note: This is truly evil for Sun.
A developer calls you to change the number of semaphores available to kernel on the production machine, how do you do that? ANY other answer besides "Get lost!" or "Tested it in DEV yet?" is WRONG and a Bad Thing(tm).
What is your favorite password? Better not have one!
During the boot process, the system hangs or reboots. How do determine the problem?
A patch has gone horribly wrong, the root disk is corrupt, etc. and you must recover from tape. Do you have a tape? How do you do it on (insert OS)? Have you done it?
What is your Disaster Recovery process at your current employer? Have your every tested it? How?
Your have been told to support a new DB app, here is a white board and a pen. Draw out a basic architecture for the hardware/software needed to support the project. Hint: if he draws anything before asking you some pointed questions, get rid of him. What questions he asks, and what he fills in by default will show what he really knows, and what his prejudices are, and what he thinks you want to hear.
One candidate put together a 3-teir Sun/Veritas/Oracle/iPlanet web enabled enterprise class using E10K's before he even asked a question! The CTO/CIO calls you to change the number of semaphores available to kernel on the production machine, how do you do that? (See above)
The other thing to do is to go down paths to see how far it goes. No question is a bad question (unless prohibited by labor laws) as it always tells you something about the candidate, even if it is only how he reacts to stupid questions. Also, don't forget to ask about carring a pager/oncall/cell phone. SOme people won't do it.
Never answer an anonymous letter. - Yogi Berra
If he bitched about "bugging him at this hour", what makes you think he won't bitch when the real emergency happens at off hours in the future?
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...
This is the greatest technical question in this forum: mod up! It's so great because it combines memorisation and familiarity with problem solving skills. Even if they didn't prep for the interview, they will still succeed according to their skill level.
What is http:slash-slash-slash-dot-dot-org
I would think you should avoid hiring anyone who says "I am Bill of Borg, resistance is futile, you will use Windows".
Then came the technical questions. The killer one was What are the file type on Unix?. Most guys answered "normal ones, directories, and hidden" (I'm not making this up), at which point I was thanking them for attendance. If the "filetype test" was passed, I asked them about common tasks like adding users (How do you add a user without using the adduser command), installing software, familiarity with packaging systems (the company used Redhat/Immunix and Debian), how do you patch and compile a kernel (a second common point of failure - esp. the patching part), how do you install software that is not packaged, what to do if this not compiles out of the box etc.
There was the networking part where the killer question were What is the CIDR? and Are the non-continous netmasks legal?
And believe me, it was rare that any candidate would pass this part.
Alex
First of all, when you're an interviewee, sometimes it's hard to tell whether you're talking to an HR Drone/PHB or someone who actually knows what they're talking about. I find myself reluctant to go into full-geek mode on an interview because most people at a given company don't really understand what geeks are all about.
Second, where the hell are the job postings from all of you!? I've been trying to find a job for a while, but my lack of "professional experience" is keeping me from getting my foot in the door. I'm reading these questions and saying, "yeah, why would I memorize all the flags for grep when I've got a man page to look at? Isn't it more important to know WHAT and WHY?" Which seems to be a common theme here, but not one I'm seeming to find "out in the world."
A true story...a placement agency I was working with had me take a Solaris test at BrainBench. Keep in mind that I had never touched Solaris before. However, the tests let you use not only your related knowledge, but any online/print resources available. I passed the test easily, and I THOUGHT that this would speak kind of highly of my abilities, but no, that whole HR drone mentality again.
I'd just ask, do you know what cl_flushentity packet is, if they say yes, gone. also, ask them favorite gun, if they answer the AWP, kick em, company has no need for people who sit back -Theed
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-
Maybe you just haven't been around long enough to know better. If they say management or upper management, chances are that they aren't lying. Pray that you don't find out firsthand what I'm alluding to.
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.
Where is your bachelors degree from (or if you're still a student, where will it be from)? Anyone who shows poor enough judgement to skip getting a real education shouldn't have root on my servers.
What certificates do you have? The best answer is "None." More than two you don't get a second interview. If you have an MCSE, you don't get a second interview, especially if I need an NT sysadmin. Certificates mean that you went to lame training courses, probably on your employers coin and missed work to do it. I want employees who know how to read to learn, instead of expecting to go sit in a course and have knowledge dropped in their lap.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
Glancing at the parts of the booklet that are online, I'm quite impressed. The approach seems to be holistic rather than reductionistic, which suits me (and apparently many other slashdotters as well). Thanks for the link.
Ben "You have your mind on computers, it seems."
Who is your daddy and what does he do?
I always start with a set of questions designed to determine if there is a potential for personnel problems--that is, weed out anyone who less than professional. (Q: have you ever had any personality conflicts with anyone you've worked with? A: No.) I have the questions written out ahead of time and always take copious notes. I give the appearance of being very non-chalant about the process to make the inteviewee more likely to say what they really think.
In terms of determining skills, I always ask questions about how they would go about determining and solving a problem. I am not interested if they know the answer to a particular problem. Sys Admins face new problems all the time. They need to be able to fix the new problems not spout knowledge from past problems.
I find it is much better not to hire someone because they have particular experience. I'm willing to hire someone who is smart and can be trained more than I am willing to hire someone with the exact experience I want. I have found that my best employees are the ones that I've trained to some degree. And the worst employees are the ones with lots of experience and training from big companies.
Frylock: That's not a toy!
Master Shake: You say that about everything you own. You should own toys. They're fun.
About technical issues. In a casual conversation you can get a pretty decent sense of someone's technical abilities and inclinations (the latter being to often ignored by employers - and its probably one of the most important things). But no, I wouldn't hire anyone who couldn't give me a reasonable explanation of the OSI model.
"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."
go jump off of a cliff and save the world some clean air
I replied "Microsoft Bob" and they hired me on the spot.
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.
Other than that question I did pretty well but I guess the other guy did a little better... *shrug*
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.
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've never interviewed a sysadmin, but when I WAS interviewed, it was a two-pass evaluation. The first pass was three generic geeks from User Support (I actually was interviewing for a User Support position)... they asked me questions like "Tell me about the last crisis you encountered in your work and how you handled it" ... "Where do you turn for information when you don't know the answer to a problem?", and "Would you feel comfortable if you were dropped into a multi-platform Unix environment and told to make it run smoothly?" (my answer was "not intially") they followed that one with "How long would it take you to get comfortable?"
...
... . The interview centered more on familiarity with, and understanding of, the concepts behind the system than the details of administration. (It's nice to be interviewed by someone who understands the questions they're asking and can actually evalute the quality of the answers they get).
Based on the results of that interview, they recommended me for a different position, I was interviewed by the person who would be supervising me
His questions included "How familiar are you with MPICH?", "what GNU software have you built from source?" (follow-up) "were your kernel builds successful?", and things of that nature
Eleven days after the second interview I started.
utter rubbish
One test that I enjoy, though have only been able to use once is to take our "test lab", and image a broken machine with a few things broken on it. The things will likely range from simple things (misconfigured ip info) to the esoteric (ethernet card installed in same slot as a previous ethernet card in win2k w/o first 'uninstalling' the first card).
Tell the canidate that they can ask any question they'd like beyond "what's wrong with it" sort of questions. Sometimes the amount of fixage is important, but usually the questions and the thought processes are very insightful to the Admin's abilities.
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.
WTF are you talking about..? Those 'Internet' keyboards are very useful.
:) My dev box at work, though, is sweet... WindowMaker, transparent Eterms, and gcc are all you need..
I have all the special keys remapped to pop up either Eterms, jcc, Konqueror, or do various other functions for development use.. even those windows function keys are useful when remapped.
As you may have gathered from above I am a software engineer as opposed a sysadmin. even then, i'd have em remapped to traceroute, ping, netstat --inet, etc...
Maybe it's just becuase I have a button fettish... who knows...
Beau V.C. Bellamy
beauATspectrumwirelessDOTnet
Just let me know when you have designed such an OS and I'll provide you with a lifetime supply of whores.
Mac OS X and Windows XP working side by side to fight back the night.
There is several things I do. I have a stock list of Soft Skill questions that I ask (I pick 1-4 of them for each canidate). These questions deal with Train of Thought and Troubleshooting skills. I want to see how the canidate thinks/doesn't think when forced to. I mix those in with the technical questions. I skim the resume before the interview, circling the keywords (DNS, NIS, NIS+, NFS, Veritas ______, etc) Then if I see multiple circles of the same word or if the sentece that the word is in states that (s)he is the almighty in that subject, I will write down the keyword on the margin of the resume.
At the interview time, I have (in my head) about a dozen or so technical questions for each of the major topics. I will ask them questions like (here is an easy one) "What is the configuration file or files for a DNS server and what is contained in them?" to questions that are about what they did "Explain to me why and how you deployed the DNS & WINS services on the NT servers at ________?" And of course my questions get much harder. I try to judge in a hour (or so) how technical they (senior, junior, average) and how well they do with the soft skills (interpersonal, troubleshooting, etc).
I try not to pick a flat set of questions before the interview starts becuase you need to adjust the questioning as you go along. If you notice that (s)he does not have any real DNS skills, why pound them with DNS questions? Move on to another subject and ask them on those. You already know that they dont know it.
Scott
National Senior Consultant
Scott
janitor
sdn website family
email: scott at sboss dot net
Ask them what 'Antsy' means. They're sure to get that wrong.
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
As others have mentioned, find out how they deal with stuff they don't know - give them some troubleshooting scenarios to learn how they approach problems.
SAs are an integral part of your business; it's important to be sure of what you're getting. Don't be afraid to grill them hard.
--
"I find your lack of faith disturbing." -- Darth Vader
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
"What UNIX flavour do you like least/most? Why?"
- If the answer is something like "Linux, because it Eleete and it Rulez" (a real answer my friend received once), say goodbye.
"What part of system adminstration do you like best?"
- Every sysadmin has strengths and weaknesses. For a good sysadmin team, you want to make sure that every member compliments the other people. Having everyone wanting to do mostly programming/scripting, or only network stuff, generally doesn't work.
"How comfortable are you working in a friendly, very informal atmosphere?" (Q may change depending on workplace)
- Some people don't work well with other people coming by to chit-chat during parts of the day. Some are only comfortable wearing dress shirts and ties, and may become annoyed with the more relaxed attitude everyone else might have. Conversely, some people wouldn't be able to handle doing nothing all day but sitting in front of the computer, not talking to anyone.
The ability to fit into the work environment is *just* as important as being able to do the work itself. Sadly enough, most companies (and employees, for that matter) don't seem to grasp this concept.
"Given , how would you go about dealing with it?"
- The process a person takes in troubleshooting, learning a new procedure, etc is very important. You don't want someone who's immediate response is "call tech support" (yes, I've known admins like that). OTOH, you also don't want someone who's simply going to start "playing with stuff to see what it affects" when something is broken, as it tends to make the problem bigger more often than not.
A sysadmin's 2 most important skills, over everything else, are troubleshooting and the ability to learn/adapt on the fly.
...never, never, never assume anything. Assumption is the mother of all uuck fups.
Case in point: Ask about skills related to your current projects that don't appear on the person's resume. Admittedly, most information about writing resumes seems to point to writing them as concisely as possible, but if a major skill you are needing (or think you will be needing) is not mentioned in the resume, ask about it.
I have seen this when it happened, where a skill that turned out to be quite critical (but since everyone else there had the skill, it was also assumed the candidate did as well) was lacking but it was only discovered to be the case after the candidate had been there for a few months. Not a pretty situation.
And never, never, never assume. And even on the items they mention that they are familiar with, ask. You should be able to ask a few questions on an area to feel them out in it without making them wonder where the bright light and rubber hose are.
And never, never, never assume. Ask them about how they feel about coworkers and their present job (or last job, as the case may be), or how their present (or former) coworkers would describe them. Everyone it seems tries to present their best mask at an interview-it is your job to remove that mask and find their day-to-day one. Ask them if they favor a n*rf gun with a large number of rounds, or one that has longer range but only holds one or two rounds.
And never, never, never make assumptions. Ask them if they have a life outside of the digital world. Ask them how they relax and let off steam. Ask them what gets them steamed or stressed. Do you really want to be going through this process again this time next year because the person you hired has to take a long vacation to the rubber-walled inn?
And never, never, never make assumptions. Read the other comments to this article-the SBR (signal-to-BS ratio) for this article has been quite high (at least to now). There are quite a few nuggets of truth in the comments for the harvesting.
Remember that you are there to find out if they will fit in with the needs and goals of your company-they are there to show they do (or at least can).
-----
"I am but an egg."
In addition to technical knowledge questions, pose a couple of ethical situations. It's important you can trust them to do the right thing...