Modern Perl recruitment - cont'd

This is in response to some recent posts on linked-in, some of them leading to http://www.modernperlbooks.com/mt/2011/01/how-to-identify-a-good-perl-programmer.html

I think compiling a list of questions for the recruiters to ask for when filtering candidates is wrong and irrelevant for few reasons:

First of all, the weight of each question in the list should be judged in the context of the particular job requirements. No-one knows everything about Perl (maybe with few exceptions, see below the "top N").

Then, the weights of two questions could appear comparable to the recruiter and the candidate could get rejected based on wrong assumptions. Take these 2 examples from the list:

"What's the difference between == and eq?"

-- versus --

"Where do tests go in a standard CPAN distribution?"

One one side, if a programmer doesn't know the difference between == and eq, then we might have a problem (still debatable if the guy is coming from lots of years experience in PHP for example).
On the other side even an experienced programmer might have never been in the situation to care about the tests in the cpan distributions: if everything installs correctly and never created a CPAN module, why should one bother?
You can find more pairs of "extremes" in the list to prove this point.

The list also proved its limitations as a lot of people on linked-in already started to ask for clarifications. Assuming that someone really fixes the list's "bugs" as feedback is received, discussed and changes agreed on, probably endless iterations will be needed.

As for the relevance of asking somebody these questions, as the present list's answers can be found in only one book (Modern Perl), if anyone really wants to fool the examiner can do it by just reading this quite small book. Even easier, any perl wannabe can find now the list on the internet and can prepare the answers for potential future interviews.

Finally, knowing everything about perl is quite impossible: everyone has strong areas and weak areas and the capacity (or lack of) to improve in the weak ones if the job requires it.
Not everybody is Larry, Damian or Randal (and the list might continue to a top N). On the other hand not every company would need (or afford) any names from this shortlist. Bothering one of the top N programmers to write scripts for a company that sells ladies bras, briefs and stocks would seem a bit out of proportion, much like using a hammer to kill a mosquito.