That's a really difficult (and somewhat pointless) question -- because
Perl is so many things to so many people, what questions you ask a
candidate are going to be based on the kind of programming you do.
If your primary application for Perl is lots of little scripts, then
you'll probably concentrate on their one-liner skills, use of the file
test operators. [1]
If you do a lot of Perl-as-OO-language stuff, then you'll probably
want to look into their skill at Object techniques and good design.
Interface design is far more important than implementation - a poor
implementation can be replaced painlessly. A poor interface haunts
you forever.
If you run a stritly procedural-programming shop, then I'd concentrate
on their use of complex data structures in the absence of objects.
Before someone interviews with me, I'll have read through as much of
their code as they're willing to send. That will tell me most of what
I need to know, so the bulk of interview is just to see if they
actually WROTE the code they handed me, or swiped it from somewhere.
That, and to check if they can effectively communicate in human
languages - a programmer who can't produce effective documentation is
worthless.
When I interview a programmer, I put her in front of a whiteboard and
have her sketch out some data structures. I'm of the Wirthian school
in that I think data structures drive code design, so the ability to
represent data well, given vague mission objectives is important. The
ability to refactor the structure as objectives change is also
important - if not more so.
Since the most painful parts of perl (for me) are regexps, I like to
poke into a candidates facility with them -- looking for a good
complement.
Finally, I just want to see if the candidate is socially adept - are
they going to fit into the psyche of the organization? I'm going to
spend some time with this person, possibly under very stressful
conditions (Hey, guys -- the VP of Sales just promised that we can
reverse entropy, cure cancer, and guarantee the Cubs a World Series
win -- you didn't have planis this weekend, right?) so, as unfair as
it may seem, personality has a LOT to do with the go/no-go decision
for me. To get hired you have to demonstrate that you're going to
mesh with our team. (Perhaps counterintuitively - I think this is
even *MORE* important in a 100% virtual job, like the one I have now).
I've only ever seen face-to-face *ONE* of the people I work with - yet
I think we mesh together as a great team.
Footnotes:
[1] Short, shameful confession; Outside of working through the
exercises in the Camel book back when I was first learning Perl, I
hardly ever use `perl -pe' and kin. I was putting together complex
grep/awk/sed pipelines when I started programming Perl, and just kept
doing so up to today. I was tracking down some name service problems,
and as I was building a six stage shell pipeline to extricate the
succulent nutmeat from a busy logfile, I thought to myself, "Hey -
st00pid - you've been programming Perl for ten years. Why not use
THAT tool instead of these pipelines to find the logfile entries
you're looking for." The moral of the story: There is *ALWAYS*
another corner of Perl to explore, even if you've been living there
for a long time.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Lawrence Statton - [EMAIL PROTECTED] s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
sort them into the correct order.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
