America's Next Top IT FNG

[tuba-man.livejournal.com]

No rant today, just a question. (Though I'll be working face-to-face with Costa Rica tomorrow. That should be interesting...)

So I'll be taking part in the hiring process with the first round of new hires at this company. Exciting stuff, I suppose. I'm worried though. There are almost as many horror stories about terrible IT-wannabes (Because IT is so hip and cool?) as there are terrible users. Sometimes even kickass IT guys hire idiots, it's just the way it works out.

We've all worked with idiots before. Does anyone have any signs they watch for that warn of impending OMGDUBM?

Edit: Thanks for the suggestions everyone, they're greatly appreciated!

Comments

[reynardo.livejournal.com]

Ask a question about an imaginary protocol - "So, you're trying to diagnose a client's WINXP machine, and you start getting a 'Security Warning - Triltain Protocol error' - what would you do?"

Look for the "how" - do they admit it's not one that's familiar to them? Do they mention using a manual or even looking for a solution in the appropriate places? Or do they try to bluff their way through? Bonus points if they actually know what a protocol is and where to find the controls.

The guys that bluff their way through are the ones who will grab any cable to plug into a socket, who will install their mate's special software on the company machines (including the secure ones) and who will not work well with the rest of the team.

[glitteringlynx.livejournal.com]

I agree with this. The trick of a good worker (for any area, really) is not what they do when they know the problem, but what they do when they don't.

[jokergirl.livejournal.com]

Sounds like a good plan.
Luckily more and more people are realizing that the right attitude to problems is in fact a lot more important than actual hands-on skills in a long-term hire (of course, if you need a short-term fix, you still want that).

;)

[mix-hyenataur.livejournal.com]

if they 'google it', give them +5.

[cheezemeister-x.livejournal.com]

Out of 5.

[pyrtolin.livejournal.com]

Bonus points on that if they remember to say "On a known good machine"

[eyeamahuman.livejournal.com]

OMG I love that one! I've had so many calls because of that when the faculty got new laptops.

[vulpisfoxfire.livejournal.com]

What happens if they realize that the error is complete BS and call you on it? Do they get *your* job? ;-)

[yanni85.livejournal.com]

If they hear the name of a service they don't recognize and immediately assume that it's fake that sounds arrogant to me. No, you don't actually know every possible service out there.

[tullamoredew.livejournal.com]

Last time I was hiring a sysadmin, two guys came for the interview, whose CV did mention the needed experience.
first one instead of answering my questions kept flattering me for knowing all the stuff I was asking him about, and tried to tell me how good he was at administering oracle (not required for the job at all)
the second guy was able to answer about 70% of the questions, and with every question he didn't know the answer for, he simply said so, and offered to google the solution up in 5 minutes, providing a rather good search string.

I don't think there's any doubt as to who got the job

Try these:

[tecie.livejournal.com]

Ask corner questions that will:
1) Show that they're willing to admit when they made a mistake.

2) Show how they react to when colleagues make mistakes

3) Ask questions where the premise is basically wrong to begin with. This one is important, because they have to be able to stand up to you and tell you that you're wrong.

4) Ask them to walk you through a very large and complex emergency outage they were a part of. What's important here is not only what the candidate did, but what everyone else did. If there are more techs in the story: extra sysadmins, DBAs, developers, managers, etc, and they are doing something then the tech person is worth their salt. The reason is he knows how to delegate and recognises that it can't be a one man show.

5) Ask about standards. For example, in *nix, I'll ask about root filesystem general sizing, and how the best way to size them is: a one size fits all approach, or switching it up per group of servers.

6) Ask about how the candidate came to try to get to this position. I'm a big fan of working your way up the support chain. Basically tailor some questions around seeing how the candidate thinks about and treats the help desk and operations. If they are not only clueless about how a helpdesk functions, but also have zero respect for them, then it's usually a bad sign.

7) If possible, ask about some variation on ITIL. Not that I'm a particular fan of it, but I've seen too many tech people go through without a clear concept on what the difference between an incident, a problem, and a change is. And it eventually trickles up to the executives, who will get it into their heads that *everything* is a change. This one is self preservation.

8) Take the weirdest problem you've had in the last six months and give it to the candidate and see how he would handle it. Don't bother looking for specific command syntax, look for concepts.

Re: Try these:

[tuba-man.livejournal.com]

2) Show how they react to when colleagues make mistakes

I /really/ like this one! Judging team interaction has always seemed like the sort of thing that we try to do intuitively. Even if the person isn't exactly accurate with how they think they handle people, it'll give a good idea of the way they think about other people.



I like these suggestions in general. On number 7, I think you're the first person I've seen mention ITIL specifically aside from here in the office. :) That's one of the interesting parts about small business IT. It's almost exclusively a mom-and-pop mentality. As much as I love playing around with tech stuff, there's a time and a place for it. I feel like most tech guys in the small business world think of the business systems as a playground. It took me a long time to understand that for most small business owners (and I guess normal people in general), the computers they use are the means, not the ends.

Re: Try these:

[jamoche]

3) Ask questions where the premise is basically wrong to begin with.

One of the people interviewing me did this by mistake - he misread my C for-loop and was convinced I had an off-by-one bug. We argued politely back and forth a few rounds until he spotted it and was properly - and good-naturedly - chagrined.

I was impressed with how he'd handled being corrected, he was impressed with how I handled correcting him, major interview points for me - and a job :)

[lunatic59.livejournal.com]

Unless you are hiring a very VERY specialized support staff, nobody will have all the answers, so if they claim to, they probably are pumped up on vitamin-B(ull$hit). If they are wearing a postal uniform and respond to "Cliffy", thats a bad sign too.

[ursulagoddess.livejournal.com]

I always like to know what someone liked best and least about their last job, just to try to get a small bit of their personality.

Also, ask a random not job related question such as, "what is your favorite recipe" or "Do you prefer Star Trek to Star Wars" or, "who was your favorite Sesame Street character when you were a kid?" This will throw them out of their groove and hopefully you'll be able to see an more honest answer and not something rehearsed.

Good hunting!!!

[cheezemeister-x.livejournal.com]

I agree with the first suggestion, but I've always viewed random non-job-related questions thrown out in the middle of an interview to be extremely bad form. It will likely be viewed by most candidates as a deliberate and transparent attempt to throw them off their game and will make the interviewer look like a jerk. The time for non-related small talk is at the end of the interview, as you're wrapping up and escorting them to the door (this is still part of the interview and any good candidate will know this).

I've interviewed quite a bit (and have also sat on the candidate's side of the table enough times as well). One thing I've noticed is that many interviewers treat candidates as if the candidate needs the job. They seem to forget that often the best candidates are the ones that DON'T need the job, and no one wants to work for a jerk.

[shirenomad]

Those interviewers aren't looking for the best. They probably can't afford the best. They're looking for the ones who are willing to grovel, for they will never need to offer them a raise.

[wolfhound668.livejournal.com]

My favorite interview was when the hiring manager sat me down at the table, kicked his feet up, leaned back, and with a perfectly straight face said, "name the seven layers of the OSI model and explain what each one does".

Nice opening question I've always thought.

[azurelunatic]

Attitude toward the users is probably important. Neither "the customer is always right" nor "the asshole is probably a moron" is really a good scenario.