In April, I was an interviewee at the IT consulting company at which I am currently employed. Just seven months later, I’ve reversed positions, and am going to be the interviewer. It happens tomorrow.
It’s not quite as dramatic as it sounds. I’m not growing a tail and whiskers and going into Human Resources or anything. I won’t be the only interviewer. We bring prospective candidates on-site and have them talk to about five different people on staff. And now my turn has come up. I won’t lie, I am excited by this (whereas some people dread having to do it). I find it exciting, helping to chart the future of the company by having a say in its future employees. So I’ve been figuring out how to do the best job possible.
The most pressing concern weighing on my mind is that the majority of applicants to computer programmer positions cannot actually program. Seriously. Whether it’s people who simply don’t have any background in the field but are attracted by the lucrative salaries, or non-nerds who somehow managed to pass less-than-rigorous compsci programs without actually picking up the skill, the hiring prospects in this field are frighteningly dim. So I’ve come up with a simple programming exercise that should take someone who actually knows how to program just a few minutes, but will completely stump a faker.
Our interviews look at two main areas: whether the applicant actually has the skills to do the job, and whether the applicant will fit into our company culture (which is a bit oddball). It’s easy to do the latter; just chat with the person and see if they’re likable. That’s the problem. As I was talking with our company’s president and asking him what I should do for my first interview, he heavily suggested that I focus on the technical abilities of the interviewee. This is because most of our employees feel more comfortable simply chatting than asking technical questions that may reveal a lack of technical knowledge in an embarrassing manner. But I don’t mind having to deal with that.
My other main interrogation (err, interviewing) technique, in addition to the simple programming test, is going to be looking over the interviewee’s resume and getting into discussions about all of the technologies I see listed on it that I am familiar with (Java, C++, Perl, XML, MySQL, whatever). I put a lot of things on my resume, but I legitimately know a lot of things, and when someone asked me about them, I was able to deliver. I expect nothing less from the person I’ll be interviewing tomorrow. If there’s one thing I can’t stand, it’s a liar, and someone who puffs up their resume with all sorts of buzzwords, but can’t back any of it up with actual knowledge, will get an instant veto from me.
I have thirty minutes with the candidate. That’s more than enough time to evaluate his technical prowess. I’m not planning on making it thirty minutes of hell — actually, it should be very easy and enjoyable if he actually knows his stuff. But if he doesn’t, well, it’s going to get awkward for him, and I’m going to discover exactly how low the extent of his knowledge lies.