Re: a question regarding resumes

[paul.joslin@sdrc.com (Paul R. Joslin)]

>>>>> "Jeff" == Jeff Lucas <Jeff> writes:

    Jeff> Bill:

    Jeff> I'm sure we'd find your list of questions useful. Would you mind
    Jeff> sharing them with us?

1)  I hate to give up a trick, but I also hate hoarding useful info.  Get the
    FAQs relevant to the job (comp.unix.shell, comp.sys.hp.*, the Solaris 2
    FAQ, comp.sys.sgi.admin).  Don't expect a candidate to know all the
    minutiae.  (If they do, they've probably memorized the FAQ, or they so good
    you can't afford them!)  If you don't know what FAQ's are relevant, get
    the SAGE job descriptions and highlight the skills you expect the perfect
    candidate to have.  Then search for FAQ's in these areas.
2)  Elizabeth's suggestion about open-ended questions is a very good one.  I
    don't expect to hire someone who knows all the answers.  I use the
    questions to determine how a candidate solves problems, and to determine
    how well they communicate.  (I make liberal allowances for interview
    jitters!) So I might ask, "Suppose you get a call, and a user on a Sun
    machine says he can't telnet to zeeblebrox.  He could yesterday, and
    you're on it, so you know it's up.  Tell me a little about how you'd
    resolve the problem."  Then you can probe his answers for technical
    detail.  If he mentions DNS or NIS, you might ask, "How do you know
    whether the system is using NIS or DNS to find the address?"  I don't
    always expect a candidate to remember "/etc/nsswitch.conf", but I would
    expect them to know the concept, and how to find it.  If the candidate
    knows the concept, but not the details, I'd like to hear "I'd do a man -k
    resolv or man switch or man gethostbyname".
3)  I almost never penalize a candidate for saying, "I don't know".  I'm glad
    they recognize that fact, and are willing to admit it.  It likely means
    they're trainable.  I'd follow up with, "How would you find out?" or "How
    do you learn best?".  Someone who thinks they know, but doesn't gets "Hmm,
    I thought it worked like ...".  Then I judge their reaction.  Again, I
    make allowances for the pressure they're under.  Someone who's belligerent
    probably won't fit in on my team.  Someone who is 'politely adamant'
    (e.g., "No, I'm pretty sure it works like ...") gets follow up questions.
    ("Why do you think so?" "How would you find out for sure?").  Someone who
    knows they don't know, but tries to BS, gets a gentle reminder the first
    time, then loses ground each other time.  (Usually, it's "I'm not trying
    to find out what you don't know, just how you solve problems.  We don't
    expect people to know everything.  Even if they did, things change so
    rapidly around here they'd get out of date!  We like to find people who
    are open to learning.  How do you find you learn new technologies
    best?"). 
--
Paul R. Joslin		paul.joslin@sdrc.com		+1 513 576 2012
If you're a horse, and someone gets on you, and falls off, and then
gets right back on you, I think you should buck him off right away.
	-- Jack Handey