http://qs321.pair.com?node_id=667231


in reply to Evil Interview Questions

I always feel bad putting a candidate on the spot with "tricky" questions, but on the other hand I want to give exceptional candidates a chance to stand out. I have a favorite question which lets me sneak some advanced stuff in while not putting unfair pressure on non-advanced candidates:

Take a look at the following short snippet of code. There are some problems with it. Can you point out the problems and explain them?

I include syntax errors, programming logic errors, some really bad style elements and a couple of debatable style problems. Some of them are really obvious, but others are very subtle. It gives the good communicators a chance to show how well they can explain things, and the knowledgeable Perl programmers a chance to show off. At the same time it doesn't put anyone on the defensive, because there are a few easy-to-spot errors.

Another open-ended, conversation-starting question I like: write (or describe how you would write) code that performs some specified task, without using particular perl operators or functions. I asked one question like this during our last round of interviews -- manipulate a given array without using for/foreach/while/until -- and was pleasantly surprised to get several different correct answers. When I wrote the question, the keyword I was fishing for was "map", because a lot of beginners seem intimidated by it or completely unaware of it.

Joe

Replies are listed 'Best First'.
Re^2: Evil Interview Questions
by kyle (Abbot) on Feb 10, 2008 at 06:15 UTC

    ...but on the other hand I want to give exceptional candidates a chance to stand out.

    This reminds me of an assessment technique I faced in high school once. A teacher from another school would come to the student and begin asking questions. At first, they were simple, and they'd gradually become more difficult. Once the teacher found the student's limit, the teacher would walk the questions back again. From the student's perspective, only one or two questions were too hard to answer, and they got to finish well. I could see using this method for technical assessment, but I'd have to have more questions available than I'd normally use.

    I've had the "write code that does..." questions in interviews, and I've enjoyed them. I really like the code review method that you present also.

    Thanks for your comments.

[reply]

      I've had the "write code that does..." questions in interviews, and I've enjoyed them.

      Personally I've been through one interview with "write code that does..." and I really disliked it. But in part that was due to the fact that I was given a pen and paper (yep, pen, no erasing here). I don't write code on paper.

      I was able to get a snippet of code that would work, but I write slowly -- especially if I'm trying to write legibly. So the whole thing made me uneasy and very self-conscious for the rest of the interview. If I'd been given a computer to type up the code (even a computer with nothing but Notepad) it would have alleviated a lot of anxiety. But maybe that's just me.

[reply]

In Section Meditations