Bad interviews get you bad employees

Bad interviews get you bad employees

I used to conduct interviews where they wanted us to read from a list of twenty questions of varying difficulty. They used it when they hired me in the first place, and were still using it a couple of years later. They later asked me to generate another list of twenty and I obliged without realizing I had created a monster.

Many of the questions from both lists boiled down to trivia. For instance, if I ask you about how you install software on Red Hat and you've only ever used Ubuntu, you might not know. You might know "rpm" since it's fairly common knowledge even for non-Red Hat users, but would you have known about "up2date" back around 2005? How about "yum" now?

The questions basically ensured we would select for people who had encountered those exact situations and had managed to correctly remember the details. Those same questions could have been used in a more intelligent manner by using them to vet assertions on a resume. That is, if a candidate claims Red Hat knowledge, then okay, hit them with a few basic questions in that arena. If they claim to be a long-time user and don't know a handful of rpm commands, something is very wrong.

The problem is when you use that kind of question because you only want someone who has prior Red Hat knowledge and don't care whether they can learn it or not. If you use that as a hard pass-fail filter, you might exclude someone who could answer that question successfully given a day or two to poke around on such a box.

It's unfortunate that I didn't know about this situation back then.

Still, not all of my questions were narrow trivia. Many of them involved situations that anyone claiming to be a Unix sysadmin should have encountered multiple times no matter which OS they were running. For instance, for the most part, if you're talking about time sync, you're probably going to use ntpd or ntpdate. Any other answer is either seriously scary (call the talking clock and run "date"! Woo!) or seriously awesome. The burden is on the interviewer to know which is which.

Honestly, a lot of these questions would be fine if they were just used as conversation starters. I've interviewed people from a list where they were presented as exactly that, and it tended to work far better. You would start out shallow and then deep-dive into areas where you could keep up with whatever answers they gave you. If done properly, it can yield a sense of both depth and breadth of a candidate's knowledge, at least where it intersects with your questions.

I guess I should have known something was up when they asked me for that list of questions and then also came back and asked me for a list of answers. Could it be that they were intending to have unqualified people ask questions they themselves could not answer? How could that possibly be a good idea? If the candidate figures this out, or if they don't and just get lucky, they will manage to snow the interviewer and sneak through.

Depending on how many layers your hiring process has, that might be enough to let a bozo in. Once that happens, look out. If they manage to start interviewing people, they'll approve more bozos, and then it's game over.

Speaking of hiring bozos, let me describe what happens when one slips through. Not long after he showed up, a inkjet printer appeared on his desk. I thought this was unusual, and wondered why, until one day I finally found out what it was for. He was printing the entire Plesk manual. This was some hundred-page PDF with screen shots and other stuff for one of our virtual hosting platforms.

I didn't even know that Plesk had that sort of manual. Its interface is so easy to figure out that nobody I know had ever asked for one. We just poked around and found everything we needed most of the time. Once in a while there might have been something odd which warranted a question of a coworker or (gasp) a web search, but nobody ever killed trees for the sake of handling a ticket.

This guy did kill some trees... and very little else. I guess the only good part about that story is they eventually showed him the door. Of course, when they hired him, they passed on someone else who was probably 20 times better in every possible way, but who didn't fit their idea of a tech. So now they had wasted time on this bozo, lost the actual good candidate, and still had an opening which needed to be filled.

Incidentally, none of this is enough to kill a company. It may quickly remove one from the realm of "exceptional places which do exceptional work", but it's a LONG way from that to being out of business.