Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??
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.)


    In reply to On Interviewing Candidates by dws
    in thread Interview questions by zigster

    Title:
    Use:  <p> text here (a paragraph) </p>
    and:  <code> code here </code>
    to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others about the Monastery: (6)
    As of 2014-12-28 14:14 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      Is guessing a good strategy for surviving in the IT business?





      Results (181 votes), past polls