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.