[svlug] Interview questions?

[Karsten M. Self]

on Thu, Jan 19, 2006 at 12:27:16AM -0800, Ian Kluft (ikluftatthunder.sbay.org) wrote:
> On Wed, Jan 18, 2006 at 10:16:46PM -0800, Mark Jaffe wrote:
> > I will be interviewing a candidate tomorrow for a QA position, and  
> > would like to quiz his *nix skills. Can folks here suggest some good  
> > questions to pose a prospective colleague?
 
> As it turns out, I just interviewed someone for a somewhat similar
> position yesterday.  Basically, let the topic areas in the job
> description and the candidate's resume become categories for
> questions.
> 
> You (the plural you, all the interviewers) have to verify that they
> actually have the experience they claim.  So anything on their resume
> becomes fair game for questions anyway.  Split up some topics between
> the interviewers ahead of time.

Good advice.  I try to focus on specific positions, tasks performed,
what the candidate can tell me about same.

If they claimed to have solved world hunger but can't spell "F-O-O-D", I
start to get dubious.  Similarly, someone who's claimed to run DNS
servers but doesn't come up (prompting allowed) with "updating the
serial number" in response to "what do you always have to remember to do
when changing zonefiles" starts to smell funny.  You'll know it if only
because you've forgotten to do it.  Multiple times.

I focus a lot on *why* specific tools are used, which gets away from the
(IMO frequently irrelevant) topic of which tools are being used.  Face
it:  for anyone with any significant level of experience, they've been
exposed to a different environment -- teachers, mentors, peers, problems
-- than you, and may not like your editor, shell, desktop, scripting
language, or mail tool of choice.

*But*, if they've spent any significant time using Linux or other 'Nix,
they're very likely to have some reasonably (or not) strong opinions on
which of these they prefer and why.


I also generally like to throw out task-related questions.  "You want to
do foo, how would you do it", and system understanding questions
"Describe the process of booting Linux on x86 hardware" are vastly
better than scraping manpages for obscure program features (what's 'set
-f' do, or $TMOUT, in bash?), or having cookbook answers (which of 'swap
-l', 'swapon -a', or 'swapon -s' would show you current swap status)
which omit a perfectly functional and equivalent solution ('cat
/proc/swaps', which is what I'd do).

I don't particularly care _how_ someone does something, or if they know
all possible ways to do something, so long as:

  - It works.
  - It's not horribly broken.
  - They understand why it works and / or isn't horribly broken.

The Linux skills test site I posted a few minutes ago is unfortunately
very much obsessed with minutia of commands, or use of some now-arcane
features (e.g.:  sendmail.cf) no longer standard on most Linux systems.

 
> I got some additional ideas just Googling for "interview questions"
> (keep the quotes around that) with various keywords applicable to the
> position.  Although most weren't directly applicable, they did spark
> other ideas.

There's a book out, _Conducting the UNIX Job Interview_, which I've
scanned, and seems reasonably sane:

    http://www.bookpool.com/sm/0974435562
    Conducting the UNIX Job Interview: IT Manager Guide with UNIX
    Interview Questions
    Adam Haeder
    Rampant TechPress, Paperback, Published July 2004, 163 pages, ISBN
    0974435562

Eleven and a half bones.
 

> For a QA position, how have they tests software before?  

See Cem Kaner's book.

> You'll probably have them writing in a preferred scripting language or
> two (or more).  It doesn't really matter which one - but that'll be a
> line of questions.  What code have they written in it?  Have them tell
> you about it.  Do they know where current code/resources for that
> language/tools are located?  Are they familiar with the docs?  You can
> show them snippets of code and ask them what it does.  A second chance
> for some language feature questions might be knowing where to look it
> up - not everyone can recall facts the same way under the pressure of
> an interview.  How honest are they about their level of experience in
> the language/tool/etc?  Have other questions ready to double-check
> that.  You need to shake out anyone who's just faking it.
> 
> But balance the questions with not being excessive to the point of
> scaring away the candidate.  You might not be their only opportunity.
> Just thinking about it that way should help maintain some balance.
> You have things you must verify - but you still want them to like you
> when it's done.

... or at least respect you in the morning ;-)

Remember that a job interview's there to assess a number of things.
It's a place for both the candidate and the hiring company to sell one
another, to assess fit, to see if they'd work well together, and enjoy
doing it.  It's a hell of an environment in which to do all of that, but
do as much with it as you can.
 

Peace.

-- Karsten M. Self <karsten at linuxmafia.com>
http://linuxmafia.com/~karsten Ceterum censeo, Caldera delenda est.