Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

On Interviewing Candidates

by dws (Chancellor)
on Jan 22, 2001 at 23:21 UTC ( [id://53569] : note . print w/replies, xml ) Need Help??

in reply to Interview questions

I'm a hiring manager, though I don't get to play one on TV. (That's probably a Good Thing :-)

One of the challenges in interviewing is to plan out a set of questions that gets at

  • what a candidate knows right now,
  • how the candidate solves problems, and
  • how they'll fit in with the culture

    "Closed-ended" questions ("what do the symbols $ @ % and * mean...") will tell you how well a candidate knows the mechanics of Perl, but if you limit yourself to them, you're liable to hire a complete doofus who happens to know some facts about Perl.

    "Open-ended" questions can get at how a candidate thinks ("tell me about a gnarly problem you solved with Perl") and what their values are ("what are the characteristics of a project that is well suited to Perl"). You want a few "values" questions thrown into the mix to help judge how the candidate will fit in with the culture. But, if you limit yourself to open-ended questions, you risk hiring a thinker who can't produce.

    To complicate this, imagine that you have a 30 minute interview slot.

    What to do?

    A technique I picked up from a good manager a while back, and have since refined, is to pose a "vague problem with no right answer1" and ask the candidate how they would approach it. The value of being vague is that you'll quickly see whether the candidate will stop and ask questions. (A candidate who jumps right in without taking the time to determine whether they're solving the right problem is not someone I want on my team.) I'll often throw a few hints to a candidate who gets stuck. (Would you want someone on your team who would rather stay stuck or plunge headlong down a blind alley rather than take a hint?)

    The vague problem typically involves some simple elements of OO modeling (simple enough to tell me within a few minutes whether the candidate "gets" objects). After getting them to do a sketch on the whiteboard (which tells something about how the candidate will communicate in design meetings -- doubly important here since many of the folks I work with aren't native English speakers). I ask them to sketch out a class definition in whatever language they're most comfortable with, and pseudo-code one or two methods. (This tells me whether they can implement with objects.) As necessary, I'll toss in a few close-ended questions.

    Finally, if we've gotten this far and have some time left, I'll ask them to discuss the strengths and weakness of their approach. (Can this candidate reflect on their work? Are they self-critical?) The candidate who asks how I would solve the problem gets extra points (for showing that they can seek new viewpoints, not for stroking my mighty ego).

    With a little practice using this approach, here's what you can find out in 30 minutes:

    1. Can the candidate cope with vague problems? Will they try to get requirements clarified, or will they charge blindly ahead?
    2. Will they take input (hints, clues, ideas) from others, or will they burn up valuable project staying stuck or pursuing dead-ends?
    3. Can they explain themselves at a whiteboard?
    4. Do they understand objects, and can they implement with them?
    5. Are they thoughtful about what they do?

    It's been my experience that a candidate who nails these is the one you want, unless you have really narrow technical requirements that they can't satisfy within your time window.

    * * *

    1 I ask the candidate how they would model and implement the inner workings of Minesweeper (avoiding UI details unless I'm hiring a UI developer). There are several approaches to Minesweeper that "work", and several wrong approaches. A few candidates have demonstrated that there are also seriously wrong approaches. I've had candidates use C++, Java, and Perl. (The few who've tried straight C tended to flunk badly.)

  • Replies are listed 'Best First'.
    Re: On Interviewing Candidates
    by jamiguet (Initiate) on Jan 26, 2002 at 00:35 UTC
      Where is it that nice dreamland you work in? I want to get hired there !!!!!!

      Where is my mind. Oh yes, Down the pub.
    Re: On Interviewing Candidates
    by Jenda (Abbot) on Aug 26, 2005 at 23:39 UTC

      I once implemented Minesweeper in Prolog and another time in Concurrent Clean. In both cases the minesweepers could optionally solve the easier cases for you. It was up to the level of "this square needs one more bomb, so these three squares may contain only one bomb so if that square needs two bombs, then the square over there must be a bomb, and the other will be in one of those two so this square is safe, ..." Shame I lost the code. I wonder though how much would it tell you about my understanding of objects ;-P

      XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.