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.

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).

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.

<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.

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.

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";
  }
}
[download]

-- 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";
   }
}
[download]

(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?

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.

What don't you like about XXX, and how would you change it?