From interviewee to interviewer in seven months

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.

11 Responses to “From interviewee to interviewer in seven months”

  1. Kelly Martin Says:

    I once interviewed candidates for a systems administration position that would include Microsoft Exchange administration. My “stumper” question was “Can you tell me one of the differences between Exchange Standard Edition and Exchange Enterprise Edition?” I, myself, had only encountered this a few days previously (we were running Standard, and had recently exceeded the total store size limit, which at that time was 16GB).

    I didn’t expect candidates to know the answer. (It’s easy enough to find out in practice by going to the Microsoft Exchange product website.) I was more interested in seeing how candidates reacted to being asked this question. I had one (who we did not select) whose response was basically “I’m an MCSE, I should know this!” repeated over and over again. He spent the rest of the interview obsessing over this, apologizing almost continuously for his lack of knowledge.

  2. William Says:

    Huh, I thought it was just my imagination. I’ve noticed that many of the students in my CS classes are totally stumped by even basic programming problems and fail to apply any sort of basic programming theory. Saw a guy make a true/false array instead of an int. And instead of making an actual array object, he made 18 different boolean values, one for each possible. I can understand that sort of thing from one guy, once in a while, ’cause he wasn’t thinking. But this sort of thing seems to be done by half the class for some of the assignments.
    I’m trying to avoid this trap, myself, but I’m not having much luck. I realize the whole idea is basically to grab a book and go through it, grab a new one, rinse, repeat, but…
    Well, good luck on having a pleasant interview. I’m curious to see your, for want of a better phrase, after action report.

  3. The hallmarks of a good programmer | Cyde Weys Musings Says:

    […] qualifications, gives me a good idea for what types of questions I should be asking when I do more potential employee interviews. I’ve already subconsciously realized that one of the aspects that makes me a good programmer […]

  4. Tawker Says:

    public class FizBuzz{

    public static void main(String[] args) {

    // Write a program that prints the numbers from 1 to 100.
    // But for multiples of three print “Fizz” instead of the number and
    // for the multiples of five print “Buzz”.
    // For numbers which are multiples of both three and five print “FizzBuzz”

    for (int i = 1; i< 100; i++)
    {
    if(i%3 == 0)
    {
    System.out.println(“Fizz”);
    }
    else if(i%5 ==0)
    {
    System.out.println(“Buzz”);
    }
    else
    {
    System.out.println(i);
    }
    }
    }

    }

    Actual time needed, 1 minute.

  5. Tawker Says:

    Err I made a typo

    add if(i%5 ==0 && i%3 == 0)
    {
    System.out.println(“FizzBuzz”);
    } as the first if and else if on the rest

  6. Cyde Weys Says:

    Dear God, that’s so much whitespace. Allow me to Perl one-line it, if you will:

    for (int i = 0; i < = 100; i++) { if (i % 15 == 0) { print "FizzBuzz"; } elsif (i % 3 == 0) { print "Fizz"; } elsif (i % 5 == 0) { print "Buzz"; } else { print "$i"; } print "\n"; }

    Everyone seems to check mod 3 and mod 5 individually, not realizing that checking for mod 15 is equivalent and more efficient. I haven't yet seen one person implement it using mod 15. More recently I've just taken to asking people to write a recursive function that calculates the nth Fibonacci number. That's a good weed-out question.

    (I should point out that your solution is slightly incorrect because you don't print out anything for 100, which is in the inclusive range.)

  7. Kelly Martin Says:

    Checking for mod 15 more efficient? How in the hell do you figure that? You’re doing three integer divides, which are pretty expensive instructions. If you check for 3 and 5 separately, you only use two integer divides.

    I don’t want either one of you writing code for imbedded systems, video codecs, or anything else where cycles really matter. You both suck.

  8. Cyde Weys Says:

    I didn’t go that route because it made the code messier, requiring keeping track of more state. I didn’t say that my code was optimal, only that it was more efficient than his (three divides versus four divides). So no, I don’t suck. Here’s an off-the-top-of-my-head approach at two divides (omitting the for-loop as it’s not relevant):

    bool flag = false;
    if (i % 3 == 0) {
    flag = true;
    print "Fizz";
    }
    if (i % 5 == 0) {
    flag = true;
    print "Buzz";
    }
    if (!flag) {
    print i;
    }
    print "\n";

    I do think if I ever ask prospective interviewees this question again, I’ll ask them to optimize it down to two divides just to make sure they know how to do it. And if I’m really feeling evil, I’ll also ask them how to do it without defining an additional state variable (hint: think gotos).

  9. William (green) Says:

    I’d have to do research to know how to calculate any numbers in a Fibonacci sequence, ’cause I don’t remember what they are exactly. Whereas Fizzbuzz is just simple programming, and fairly easily done.

  10. Cyde Weys Says:

    Well I would typically start the question by making sure they knew what the Fibonacci sequence was. It’s really easy though. F(1)=F(2)=1, for all n>2: F(n)=F(n-1)+F(n-2)

  11. A better solution to the FizzBuzz interview problem | Cyde Weys Musings Says:

    […] months ago, I wrote about a simple programming problem that I was administering to interviewees at work to assess their programming skills. The basic problem is this: loop through a range of integers, […]