Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

wickline (135)

  (email not shown publicly)

Journal of wickline (135)

Friday February 21, 2003
09:24 AM

hiring a perl geek

[ #10723 ]

About three months from now, some perl programmer will have my job, and I'll be unemployed... or so I hope.

Currently I spend most of my time documenting procedures and practices and reviewing existing code and code-level documentation with two coworkers who will inherit said code. They're both relatively new to perl. They've each written two or three perl scripts, and are otherwise primarily Uniface programmers (think "visual basic database apps" but w/o microsoft).

I learned yesterday that managment has agreed that it would be wise to hire a perl person as my replacement. They also agreed that it would be ideal if this person could be hired before I leave. So, I'm in the novel (for me) position of having some say in hiring my replacement, and being the primary person to evaluate their technical qualifications.

We'll be asking for code samples. I'm thinking that I'd like to see something over 100 lines to get a sense of what sort of documentation they typically include, how focused and reusable their subs are, whether they copy/paste instead of using subs/modules, etc. I'll also be asking some perl questions to get a feel for how familiar they are with common idioms, how they approach problems, how well they can take in someone else's code (mainly my code, since that's most of what they'll be working with for a while).

I've already got some questions/problems in mind, but I'm wondering if anyone has input about what sorts of questions they've found useful or useless in the past (from the perspective of the employer) and also whether folks have input from the perspective of the interviewee. Feel free to throw in non-technical questions if you'd like. I'll be asking some communication-skills-type questions too.

Also, does anyone have input about soliciting/reviewing code samples? What sorts of code have you requested (or had requested of you), or was the request always stated in very general terms? What sorts of things did you look for in the code?

If things move smoothly, I expect we'll be looking at resumes within a couple of weeks. Depending on the quantity and quality of applicants we may begin interviewing anywhere from three weeks to ??? from now. In any case, I've got some time before interviews and reviews of code would begin.

Any input? :)

Oh, for the curious, this would be in Saint Louis, MO (USA). I can't say more than that as all of the applications need to go through HR for legal reasons (so don't send me any resumes/code). Yes, I will be posting this opening to relevant perl fora once I've been cleared to do so... probably the perl jobs list, and to, and in this journal. I'll look to see if perlmonks has an appropriate section too. I expect I'll be able to do that some time next week (maybe later if HR needs to clear the exact text I use in the posting).


Update: the position is now available.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • One of the things I have always been glad of is having a bunch of programs (of varying quality) available on the net that I have written.

    Surprisingly very few interviewers have more than glanced at it. I would be very surprised if you had time to read through 100's of lines of perl code.

    In the past I have done about 6 or 7 perl quizes during interviews, I think they are a quite good indicator of knowledge but are very limited - after all much of the time you only actually use a small portion of perl mod


    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;
  • Questions (Score:3, Interesting)

    For the last two hires I had, I threw together a few questions about Perl to smoke out anyone who obviously had never done anything with the language.
    What are the differences between C<our>, C<my> and C<local>?

    What is C<$!>?

    What is C<$_>?

    What is C<$&>?

    What is C<$1>?

    How do you delete a file?

    What does C<TMTOWTDI> mean?

    How do you implement a list of hashes?
    I figure that someone who's been using Perl for a while will know all these. I don't like memorization questions, but if you don't what $1 is, then something is wrong.

    For my/our/local, I'm OK with an answer like "I always use 'my'".

    The "delete a file" is there to see who knows the difference between delete() and unlink().



    • Re:Questions (Score:3, Interesting)

      FWIW, I would not expect everyone to know what our() or $& is; the former is new, the latter is rarely used. I would not care if anyone knew what TMTOWTDI is. Of course, that they cannot answer the question accurately isn't a bad sign, necessarily.
      • Right, none of them are necessarily exclusionary. It's just to get a feel for what the person knows overall. None of them are make-or-break. (Well, maybe $_ is)

        I make a big point of starting out the interview by saying "You will not know the answer to everything I ask. You will not have experience in everything I ask about. Please don't think that any one question is going to kick you out the door."

        It's not just Perl stuff that I make that comment for. For instance, I was looking over some sysadmi



    • Once upon a time I went for interview with Overall I'd have to say I didn't like the location or the atmosphere, and I was glad I didn't get the job, however the random test at the interview was actually quite good.

      Without any warning the sat me down with a glass of water, a pencil and a sheet of awful HTML and asked me to fix it. At once I said it was not possible without knowing the DTD I was correcting it too, they said "current", and left me to it. I know I scored well they told me so wh

      -- "It's not magic, it's work..."