Slashdot Mirror
How Should You Interview Your Replacement?
legLess asks: "I've been the Alpha Geek at a 50-person firm for 4 years, and now I'm leaving. The firm didn't have a real IT person before me (they'd only had a network for 6 months), but they absolutely need to hire one now. I'm going to need to be present for the interview, and I'm going to have to ask the tough questions, because nobody else here can. But I've never interviewed anyone before, and I've done very little interviewing myself. What's the best approach?" I'm sure quite a few of you have been in this position before. What help can you offer for those folks who may soon find themselves in this position?
"It won't be too hard to tell if someone's a good fit, personality-wise, but what about skills? Decision-making? Reaction in a crisis? I dislike the aggressive, confrontational style, and I believe it's counter-productive. I don't want to skirt concrete technical issues because we must be sure the person's qualified. OTOH, I don't want to give someone a written examination or stage a bunch of fake system emergencies to see how he or she performs. Do you have a stock list of questions? (e.g. What is the last mistake you have made? How did you solve the problem and what did you learn?) What's been successful for you (on either side of the desk), and what's failed?"
Really? You're leaving to go on to better things. Don't sweat it, what you need is someone good enough. You shouldn't consider it has to be someone with the same skills as yourself, you won't find them without a mirror. Get the resumes, throw away the useless ones and determine who has the closest skills. Once you have two who are close to the requirements, ask them in for an informal battle with sticks, while playing the music from the gamemaster episode of Star Trek.
Your job is technical. It is up to HR to look at someone and say "They may be good, but they are really here as a theif/spy." It is up to your boss to figgure out if the new guy's style will fit in with the rest of the company. You are not trained in doing their job and should not try to do it. You are an expert in technical issues, they are an expert in people issues. Don't take their job from them, as they are not taking your job from you.
Your job is to assess technical knowlege. He should be asking the questions. Since you are leaving make it clear! Hint strongly that this interview could easially be the guys last chance to figgure out how the system is run. That is when he starts he will get a slip of paper (that you wrote just before you left) with the root password(s), nobody else in the company will know anything abouyt the comptuers. The right guy will respond by grilling you to get all the details. Look for things like "I would have done y instead", but some people are shy about criticising so that might not happen even though it is good.
Have your boss get a non-disclousre if needed so you can take the canidate on a tour of the machine rooms and wiring closets. Ideally you can spend cpend a couple hours doing an overview. (Use judgement, any canidate that is obviously unqualified shouldn't waste your time, but your replacement will appreciate the time spent showing him around. You will appreciate not getting a personal call next month asking questions about the system.
Interviews are a two way process, not only is the company assessing the canidate, but the canidate is assessing the company. You are the expert on the company and the job. Be more prepared to answer questions then ask them!
Don't have one? Throw them out.
Then ask for their karma. Then apply the simple formula: R = (1,000,000 - UserID) + Karma*20000.
Whoever has the largest R value is your perfect candidate!
(that was a joke, in case you couldn't tell).
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
I really don't think that it's a good idea for people to do interviews if they've not been trained, especially in the states where there are pretty strict discrimination laws.
However, assuming that you'll have to do it anyway...
Technical questions about particular technologies are easy, I'm sure you can manage that. (Just make sure you know the answer and can tell if they're bluffing!)
More important is to test their problem solving skills and their 'fit' into the companies culture, but that's also more difficult. Putting them on the spot might not be a good idea -- we all get nervous -- so you need to ask stuff about what they've done. Ask them about their current job, problems they've had and how they solved them. If you focus in on enough details you can find out if they're making stuff up.
It's also important not to ask about hypothetic situations (unless there's no alternative). Would they do what they say, or is that just what they think you want to hear?
So please don't anybody come yelling at me for claiming to be irreplaceable. It's all a matter of how you look at it.
www.HearMySoulSpeak.com
"Chase him down a rathole." If every answer sounds perfect, go depth-first on him and keep getting more specific until you can get him to say "I don't know. I would have to look that up or ask somebody." People who refuse to admit that they don't know something are usually not great hires.
Figure out what you think your skills are that AREN'T technical. Good sense of humor? Casual attitude? Do you walk around and visit people alot, and keep morale high? Find out if he's got similar skills. One thing I've always thought to be true is that if it comes down only to the technical, then plenty of people could fill my role, and that it's the extras that a given person brings to the table that make him most valuable.
Realize that hiring your own replacement is something of an oxymoron. I personally look at jobs by saying "I will convince these people that I am the exact person they need for this role. I want them to throw away that paper that says 5 years java, 3 years unix, masters degree, blah blah and say wow, this is the exact guy we need." If I succeed, then there is no way that I could hire my replacement, short of convincing them that I am no longer the right person for the job anyway, and that this new guy is better. That's a weird way to approach it, I know, but it all depends on how confident you are in your position there. If you really believe that you contributed something unique to the place, then there's no shame in acknowledging that it can't be replaced.
For the record I was asked to do something similar, once, and write down the requirements that they should look for in my replacement. I couldn't do it. It's hard.
www.HearMySoulSpeak.com
Ask them if they've ever read Simon Travaglia's BOFH (the originals and the new ones at theregister.co.uk). A good icebreaker, and, uh... it presents good reference scenarios... yeah...
--
"It's tough to be bilingual when you get hit in the head."
Practical, under pressure tests are the only real way of weeding out the capable from the incapable. A really good test would be to give someone a broken system using an OS variant or piece of software they'd never seen before, and ask them to fix it. Give them a PC with web. Most will panic, others will chose options at random, hoping things will work, but some will tackle it laterally, using whatever resources are available, performing web-searches and .
I've had to do things like this under pressure. I once was sent to a customer to fix a number of things, one of which was some obscure NT backup software which wouldn't backup. I didn't even have any practical experience of NT at the time. By a process of elmination I discovered the the cause of the fault and fixed it in around 10 minutes - the customer had had the problem for months.
I also attended a training course where we were given servers that had been broken in about 5 different ways (missing executables, corrupted data files etc) and was expected to get everything working ASAP, without resorting to a full system restore from OS media and data backup. A really nasty test, but I was the only one to pass it with flying colours.
I've interviewed a number of people in the past year or so. I've had quite a few things which come to mind...
There was a guy who had worked at a company which did mail and something else in India... I asked him what port SMTP was... he didn't know. He had Oracle on his resume... so I tried to get him to give some details... it took 20 minutes to get him to admit that they had DBAs who did the actual work *and* made sure the processes were running, and all he did was make sure that an app which used the Oracle stayed running.
I interviewed a guy who worked exclusively on DNS for three months and he didn't know what port it used... and stared at me blankly when I asked.
I interviewed another guy who called himself a UNIX sysadmin and was going for a Senior Systems Engineer position, but he didn't know what to do if the root password was lost/forgotten on a Solaris box.
WHAT!?!
Insist upon an honest self-evaluation, and be ready to call them on the honesty...
--
Find the obvious, but that which people don't worry about when they play with something at home. Any schmo can run NT/2K at home and set up a PDC, printer and file shares, etc.
You don't need someone who has done everything... you're unlikely to find one of those without paying boatloads... you want someone who has done enough to be comfortable and know the basics without thinking, and can figure it out with anything else.
--
When I was being interviewed for my first computer-related position, as a Cluster Consultant (TM) for the labs at Carnegie Mellon, when they asked how I'd handle a question on XYZ (which I'd never touched), I answered that I'd grab the manual and walk back to the user's station with them and work through it with them.
When I later got to the point where I was able to read the post-interview discussions on the ACS bulletin board, I found out how much they'd thought that it meant that the first thing I said was that I'd grab the manual.
Nobody should be expected to be infallible or omniscient. After a certain amount of knowledge, it's the approach which counts.
-Nev
...make some computer related jokes, see how they react. if they are nervous in front of another geek, they'll be even more nervous by themselves while the whole company's network is going down.. and perhaps not being able to survive it.
wow, I'm optimistic today.
-- There are two kind of sysadmins: Paranoids and Losers. (adapted from D. Bach)