See the Seven Stages of a Perl Programmer.

If you Super Search for "interview" here, you can find Assessing Perl skill level in job interviews, Phone interview, Perl Interviews and Interview questions. How to convert the results you get to a number between 1 and 5 is left as an exercise to the reader.

Oh, and even if it's been controversial, PERL as shibboleth and the Perl community.

That can be a huge task. In addition to the issues with understanding what drives programming (some combination of artistic bent and scientific discipline), there's the fact that the broad syntax and intriguing complexity of Perl makes it hard to see if someone is a good programmer overall in Perl.

I emphasis "overall" because I recommend that, instead, you try to find out if a programmer is a good fit for your team. Oftentimes, you don't need the "superstar" programmer, but someone who writes steady, lean code that's well-commented and self-contained enough to work with other person's code on the team. that's something that "raw" programming talent won't show, but, to me, is more critical than if they can write Slashdot 5.0 in 2 days flat.

Having said that, I just pulled my copy of Perl Medic from the shelves, recalling a piece in it. I highly recommend this book, in general, as it covers many Perl coding practices that get overlooked, are are signs of good/great programmers. Specifically, for your question, he mentions, on pg. 65-67, Tom Christiansen's somewhat-tongue-in-cheek Seven Levels of Perl Mastery, and then goes on to list 10 of his own, updated for things like using CPAN. If you really need "levels", get Perl Medic, and read Tom's list, as a starting point for your own considerations with regards to your team's needs.

Does that help? without knowing more about what you're looking for, it's hard to say exactly what source of information will aid you in eval'ing programmers...

This is a very difficult question. About the best you could hope for is to weed out the totally inept, and hope whoever's left is reasonably competent.

The problem (IMNSHO) is that there hasn't yet been developed a consistent measure of code quality. Is it better for someone to crank out lots of workable code, or to write a few terse lines that get the job done? We might be tempted to choose the terse programmer, but perhaps the verbose one included code to check for inappropriate input; or (s)he wrote code that would be much easier to understand, debug, and maintain. What objective test could you use to decide a question such as this?

As I see it, fluency in Perl is only part of the question. Another part is the ability to develop appropriate, efficient algorithms. Without this, the fluency will be wasted. They will express their unclear thinking in fine Perl idiom.

Outside of that, you'll probably also want someone who works in a standard coding / commenting format, and who knows at least one other programming language (C/C++ or PHP). But this isn't absolutely essential.