Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Interview Questions

by Anonymous Monk
on Apr 03, 2005 at 01:33 UTC ( #444460=perlquestion: print w/replies, xml ) Need Help??

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,
I need ur help in this. I am inteviewing tow ppl as perl developers next week. What type of questions should I ask ? Does anyone have a link to a site or somthing? I my self a begginer in perl so not sure if I will be able to see if they are the right ppl. I am looking for Sr Develpers. thanks in advance

20050403 Janitored by Corion: Changed CODE tags to P tags

Replies are listed 'Best First'.
Re: Interview Questions
by graff (Chancellor) on Apr 03, 2005 at 02:58 UTC
    Well, I suppose it wouldn't hurt to ask your applicants if they know about PerlMonks... Who knows? Maybe they've posted code or other content here, and you might be able to see for youself how other monks have reacted to their posts. (Update: seriously, if you're looking for people with advanced ability, it's not unreasonable to expect that they've had some presence in relevant news groups, mail lists and web forums, so ask about that.)

    If your own knowledge of Perl is limited, then I'm not sure that any advice we can give would be helpful. When you look at perl code posted here (or written by others at your workplace), are you able to understand it?

    You can ask the applicants to show you samples of their code, and even to explain it to you as you go over it, but if you don't understand references, data structures (AoH, HoA, etc), "map", anonymous arrays/hashes/subroutines, and so on, then you'll be better off focusing the interview on things like communication skills, domain familiarity, years of work experience, and general "compatability" factors (i.e. how much you like the person).

    There may be a things that probably are reliable indicators, which I'll list in order of greater to lesser generality. If two different people show you sample code:

    • pick one who has "use strict" over one who doesn't
    • pick one who has "-w" or "use warnings" over one who doesn't
    • if one person shows fairly brief code that uses "map" and "for" loops, pick this one over someone with a lengthy program that shows a lot of repetitive (cut-and-paste) coding
    • if they show web scripting, pick one who has "use CGI" (or and/or other web modules) over one who doesn't
    • if two people have scripts that "use DBI", pick one with question-mark placeholders in the SQL statements over one who puts perl variables in the SQL.

    If any of that goes over your head, then it's like I said above: it's hard to tell you how to assess a programmer's skill level if you're not a programmer.

      if you're looking for people with advanced ability, it's not unreasonable to expect that they've had some presence in relevant news groups, mail lists and web forums

      I disagree. That varies from country to country, from place to place.

      How many Portuguese people do you see here on perlmonks? Four? Five?

      And yet, I can point you to dozens of competent Perl programmers just in the vicinity of where I now work.

      Just because they don't have a very active part in the community doesn't make them less competent.

Re: Interview Questions
by tlm (Prior) on Apr 03, 2005 at 02:19 UTC

    Where I work we have tried various approaches, including informally asking the applicant various questions that demonstrate how well they know Perl, and written tests, but was has given us the best results is to ask the applicant to solve a simple programming task related to our field of work, something that could be completed by a competent programmer within say 45 minutes; this way we can simultaneously test both proficiency with Perl and more general problem solving/design skills. Given that the number of applicants is not huge, we can afford to let the questions be pretty open-ended, since we are most interested in seeing how the person goes about completing a task.

    On the other hand, we do a lot of "tactical programming" where I work (by this I mean programs intended to perform a one-time analysis or data processing), which requires a somewhat different set of skills from those of a developer of full-blown software products. The problem is that this set of skills is more difficult to test on the spot (at least we haven't found a formula to do it).

    the lowliest monk

Re: Interview Questions
by HuckinFappy (Pilgrim) on Apr 03, 2005 at 03:46 UTC

    I don't care too much about specific skills in this sort of a situation. What matters to me is that the interviewee actually knows perl, and that they have good problem solving skills.

    So I find a few basic questions can tell me that.

    • Show them a simple class I mock up and ask them to write a derived class
    • Ask them to write a simple few lines to load a file and sort the contents with a basic numeric sort.
    • Give them a semi-complex data structure and ask them to sort it in a certain way

    I'm looking for error checking, the thought process on the last one that might lead them in the direction of a Schwatzian Transform, and some essential problem-solving skills. In fact, to me, "I'd need to read the perldoc on sorting to figure it out", or, "I'd have to check some documentation to remember if I need to 'use Exporter'", are perfectly good responses.

Re: Interview Questions
by dbwiz (Curate) on Apr 03, 2005 at 08:11 UTC

    <OT>
    I doubt that senior developers would want to work for somebody who can't even spell.
    And don't say that English is not your mother tongue, because spell checkers work for foreigners (like me) as well.
    If you want to attract senior developers, try looking a little bit more "senior" yourself.
    </OT>

    Update
    That was free advice. It may look blunt, buth it's truthful. Don't discard it just because it hurts.

    That aside, check dws home node for some specific advice, such as On Interviewing Candidates and An Interview Quandry.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Interview Questions
by tilly (Archbishop) on Apr 03, 2005 at 19:32 UTC
    If you are not technical, then you're not going to be able to judge technical skill. Sorry, but you're not. I could tell you to ask some of the same questions that I would. (eg If you don't know something, how would you find out? Tell me about a recent programming problem that you had and how you resolved it.) Those are good questions, but you would simply not be able to get the same information from their answers that I would.

    Therefore if you have anyone technical on board already, have them do a follow-up technical interview. If you don't, it may be worthwhile to hire someone external just to do a technical interview. If that is not feasible, ask for a code sample and have a technical person review it for you and give feedback.

    I'm serious. The problem that you're up against is that you can't tell when someone has technical skill. Compounding that problem is that there are lots of non-technical or semi-technical people out there who are good at bafflegab but you don't want. Conversely many technically competent people tend to be introverted and therefore do not present themselves very well even though they might be people that you really want.

Re: Interview Questions
by dreadpiratepeter (Priest) on Apr 03, 2005 at 17:11 UTC
    I often ask candidates to explain:
  • the Schwartzian transform
  • the difference between my, our, and local
  • CPAN
  • closures
  • how to parse CGI params (if applicable)

    I ask the last looking for the answer that they use CGI.pm to do so.

    I then ask them to write a short perl program of their choosing. That allows me to weed out the people who don't use strict and who don't understand basic concepts.
    Of course, I've been using Perl for almost 15 years. You may have a problem determining the right answers. As a beginner in Perl you may have a hard time identifying good candidates.
    Good Luck


    -pete
    "Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."
      the Schwartzian transform
      Do they get extra points for knowing there is a drink named the Schwartzian Transform? (Which, like the transform itself, wasn't named by me.)
      the difference between my, our, and local
      Do they get extra points for knowing the difference between "our" and "use vars"?
      closures
      Do they extra points if they can demonstrate anonymous subs that aren't closures, or closures that aren't anonymous subs?
      my $this_is_an_anonymous_sub_that_is_not_a_closure = sub { print "hell +o" }; BEGIN { my $message = "this is a closure that is not an anonymous sub"; sub here_it_is { print "$message\n"; } }

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        To the peanut gallery, its not being inside the BEGIN block that matters. This too is a closure:
        { my $msg = "Hi randal!"; sub hi { print "$msg\n"; } }
        (Yes merlyn, I know you know this... My coworker that just pointed out your message does not.)

      Hmmm...

      • For the first 2 (of 4) years I have been using perl, I would have given you a blank stare at "Schwartzian transform". I hope your question is to give them a snippet of code and ask them to explain the snippet.
      • Simple syntax questions are good for telling the difference between a perl4 programmer and a perl5 programmer ... although I'm not sure you really get much out of it.
      • I didn't really know anything about CPAN for the first year or so. Yet I was still turning out good, reliable code (I think), based solely on past experience in other languages (mostly C++).
      • Again, dumb stares for about my first 2.5 years. Although, admittedly, if you had given me a snippet inside the first 12-18 months, I wouldn't have been able to answer that question, either.
      • My answer, still today, would be, "I don't know how to parse CGI params." You'd ask how I got any CGI experience on my resume, and I'd simply say, "I use the CGI module - but I don't know how to parse the CGI params."
      • In short scripts, I don't always bother with strict, unless it doesn't work on the first try, or I'm posting it to perlmonks ;-)
      I realise that you're just giving brief bullets on what you'd ask about, I'm just pointing out what I think could be misunderstandings which could mislead you into dismissing the wrong person (not to say that I'd be the right person, though ;-}).

      I usually ask candidates to explain their past work, their roles in that work, what difficulties they've faced, how they've overcome it. But I've never interviewed for professional hires nor contractors - pretty much only students and new graduates (where working with us would be their first "real" job), and I am not restricted to perl (we use C/C++; Java; Perl; Bourne, Korn, and C shells, all depending on what we're doing), so what I'm looking for may be quite different from what the OP is looking for.

        In your first 2 years with Perl, do you really think that you should have been applying to be a senior Perl developer?

        What you're saying pretty much applied for me as well back when I was learning, and I certainly wasn't ready then to do things like mentor other Perl developers.

      Can't resist:
      • the Schwartzian transform

        Obsolete sorting method. Inferior to the Guttman-Rossler Transform.

      • the difference between my, our, and local

        The number of letters. 'my' and 'local' and two different things - it's like comparing apples and oranges. And 'our' is like an orange, with an apple flavour. Its main purpose is to make Perl scoping even harder to explain.

      • CPAN

        Like CTAN, but then for Perl stuff. Lots of junk and trinkets, and some nuggets as well.

      • closures

        Like LISP. Subs that remember the environment they were created in.

      • how to parse CGI params

        Huh? Over 10 years of web, and we still let each program parse their parameters? Can't the server do that for us?

Re: Interview Questions
by eXile (Priest) on Apr 03, 2005 at 17:01 UTC
    I've done a few interview where I asked people to write something simple in perl (collecting client IP's and http-referrer's from Apache logs for example and do some simple statistics with that) and let them explain their script. By letting people explain their code I got a pretty good idea of their skills.
Re: Interview Questions
by jhourcle (Prior) on Apr 03, 2005 at 18:57 UTC

    It would be impossible for us to know what it was that you need the developers to do. Although it would be ideal to hire people who specifically know more than you do, you may be able to find other people in your company with better ability in the specific skill areas that you desire for the person to have. (you do have to make sure that you know the personalities of the people that you bring in on an interview -- they may feel threatened by the person they're interviewing, and try to find nit-picking details so they don't lose their reputation as the 'best' in the organization. You also have to understand that there are times when someone's skill is so far beyond yours that what they say will be right, but you just can't understand it as being right).

    I would recommend that in any interview, as the person to explain the answers they give. There are those people who can do things, but have no idea why they're doing it, and there are those who can explain why they choose every last line of code. (it's one thing to use strict;, it's another thing to know why it's important). Those people who can explain what they're doing tend to have a better understanding of what they've done, and may be useful should you need them to mentor other programmers.

    Note -- This scenario is part of my reasoning for supporting voluntary licensing in the Trained Perl professional or self-taught hack? discussion.

    Anyway, as I've gotten off-message -- you may not need (or even want) someone who knows too much, as they may become bored in an environment that doesn't use their skills well. Unless you're under a tight development schedule, it may be better to have someone with a good reputation (references, whatever), and a personality that fits well with the people they'd be working with, even if it's necessary to send them to training on the skills they'd need. A test to determine a good employee for one company may not find the best employee for another company.

Re: Interview Questions
by prostoalex (Scribe) on Apr 03, 2005 at 22:01 UTC
Re: Interview Questions
by Anonymous Monk on Apr 04, 2005 at 09:50 UTC
    There's one question that has been my favourite for a long, long time. It's not Perl specific. I have asked the question, and I've been asked the question. And the answer itself isn't even important. What is important is how well they can defend their case. The question:
    What don't you like about XXX, and how would you change it?
    From the given answers, you should be able to deduce how well they know the language/OS/DB/application you are asking about, and how much experience they have.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://444460]
Approved by graff
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2020-12-01 15:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How often do you use taint mode?





    Results (12 votes). Check out past polls.

    Notices?