The article Why You Can't Hire Great Perl Programmers addressed the core Perl community. We need to encourage Perl dabblers to improve their skills and to join the community.
Several commenters noted that the article did not address the employer side of hiring. Certainly an employer offering $15 an hour for Perl programmers in Silicon Valley or New York City or Chicago or Seattle will have to work much harder to entice great programmers than someone paying competitive wages.
Editor's Note: The whitepaper Where to find a programmer who knows modern Perl now addresses this question. If you're hiring, the guidelines there may help you.
There's another point to which some people alluded but no one, to my knowledge, addressed directly. It's not easy to identify good programmers in any language unless you're a good programmer yourself. For all of the flaws in the infamous interviewing systems of Microsoft or Google (and there are many flaws in those interviewing processes), they have the advantage that people who clearly don't know what they're doing tend to expose their ignorance.
You probably don't want to go through the time, expense, and nonsense of those hiring practices (as if you could afford them), and, for various reasons, there will never be a Perl certification test widely accepted as useful and informative. Even still, there are ways to identify good Perl 5 programmers. Here's a list of questions every good Perl programmer should be able to answer effectively:
- What do variable sigils indicate in Perl 5?
- What's the difference between accessing an array element with
$items[$index]and@items[$index]? - What's the difference between
==andeq? - What do you get if you evaluate a hash in list context?
- How do you look up keywords in the Perl documentation?
- What is the difference between a function and a method in Perl 5?
- When does Perl 5 reclaim the memory used by a variable?
- How do you ensure that the default scope of a variable is lexical?
- How do you load and import symbols from a Perl 5 module?
What governs how Perl 5 loads modulesHow can you influence the list of directories from whichperlattempts to load modules?- How do you look up error messages in the Perl 5 documentation? (Award bonus points for knowing how to enable explanations of all error messages encountered.)
- What happens when you pass an array into a function?
- How do you pass one or more distinct arrays into a function?
- What is the difference, on the caller side, between
return;andreturn undef;? - Where do tests go in a standard CPAN distribution?
- How do you run tests in a standard CPAN distribution?
- What command do you use to install new distributions from the CPAN?
- Why would you use the three-argument form of the
openbuiltin? - How do you detect (and report) errors from system calls such as
open? (Award bonus points for knowing how to enable automatic detection and reporting of errors.) - How do you throw an exception in Perl 5?
- How do you catch an exception in Perl 5?
- What is the difference between reading a file with
forand withwhile? - How do you handle parameters within a method or function in Perl 5?
- What do parentheses around the variable name in
my ($value) = @_;mean, and what would happen if you removed them? - Is
newa builtin function/keyword? - How do you read the documentation of a core library? A CPAN module?
- How do you access only the values of a Perl 5 hash?
None of these are trick questions. All of them have simple, unambiguous answers that demonstrate a solid understanding of Perl 5, its philosophy, and its practical use. A good Perl 5 programmer should be able to answer at least 80% of these questions with no trouble. These are not the only questions a good Perl programmer should be able to answer, but anyone who can't answer these questions with ease needs to study more Perl.
The specific needs of your business may dictate further considerations, such as experience with well-understood Perl 5 technologies, but you can begin the technical evaluation of a candidate this way.
If you're starting to learn Perl 5, this list is also a good way to measure your skills. You should be able to answer all of these questions with a little bit of study and practice. All of the answers are available in any good Perl 5 text, including my own Modern Perl.
(You can buy Modern Perl at Powell's, buy Modern Perl at Barnes and Noble, buy Modern Perl at Amazon.com, or download Modern Perl for free and then recommend it to your friends, write a great review, or otherwise spread the word.)
These are some excellent questions, and while I definitely know the answer to about 50%, I am somewhat unsure of the remaining.
Perhaps you could briefly suggest some short model answers to make it easier for people to confirm their understanding.
For example throw/catch seems ambiguous to me as there are quite a few variations. It may be that it functions better as an interview question this way, but I would appreciate learning about better ways to solve these problems I don't currently know of.
It's a nice list, but there are plenty of ambiguous or situational answers.
* What is the difference between a function and a method in Perl 5?
Do you mean syntax? For writing or for calling? Do you care about common conventions or not?
* When does Perl 5 reclaim the memory used by a variable?
That is a trick question. I asked that on #p5p a week or two ago and the answer is neither clear nor documented. (And are you counting space allocated for hash keys or not?)
* How do you load and import symbols from a Perl 5 module?
With or without Exporter or Sub::Exporter?
* What governs how Perl 5 loads modules?
What do you mean "govern"? Do you care about esoterica like .pmc? Would you expect an answer to include the prior state of %INC?
* How do you run tests in a standard CPAN distribution?
I can think of four "standard" ways to do it.
* What command do you use to install new distributions from the CPAN?
With CPAN? CPANPLUS? or cpanm?
* How do you throw an exception in Perl 5?
* How do you catch an exception in Perl 5?
With or without modules? Do you care if it's done safely or not? (E.g. do you want the guts of Try::Tiny as an answer?)
* What is the difference between reading a file with for and with while?
Ignoring that neither of those keywords actually reads files? :-) Were you expecting to hear about the special rule for a while test reading a file handle?
As I said, all good questions, but the real litmus test might be whether a candidate can explain the subtleties in the ambiguous cases. And of course, you probably need to have a good Perl programmer doing the interview to assess the answers in the first place.
I think it's perfectly fine that these questions are ambiguous. TIMTOWTDI is in effect after all and as such most of these questions can have more than one answer. In fact, being able to explain how there are different possible answers to these questions will likely work in the favor of both the recruiter and the applicant.
The important thing i see about these questions is that programmers with different experience levels will be able to answer them with varying degrees of confidence, which will tell the recruiter a lot about the person, as well as the person a lot about themselves.
Fittingly enough, the two most 'modern' Perl books (yours and Effective Perl Programming 2nd ed) cover roughly all of those questions in their opening sections*.
Frankly, I'm not very confident in my Perl, which is why I've avoided sending resumes to Perl searches -- I know that these questions are pretty trivial, but being able to answer all of them made me feel like actually giving it a shot and sending one or two.
*The three-argument form of open comes in the middle of Effective and close to the end of Modern - same deal with the t/ folder (but that's covered in Intermediate Perl if I recall correctly), which I believe are the only exceptions.
* What governs how Perl 5 loads modules?
I agree with dagolden, what do you mean govern?
though on the rest I could probably come up with more reasonable answers. though some of mine would end up being. I have stored in my memory use X for X situation, though I don't particularly remember why. example, eq for comparing strings, and use while loops for reading files 'cause it's faster, but more than that I haven't bothered to commit to memory.
If you know enough Perl 5 to answer any question "it depends" and give a reasonable explanation of why the question is ambiguous, you're overqualified for the question anyway. I don't expect every qualified Perl programmer to know to use cpanm or Try::Tiny, but I do expect most of them know enough about reference counting to give a pretty good explanation of variable lifetime and the difference between string and block eval, for example.
I know a heck of a lot of Perl but I couldn't tell you what accessing a hash in list context gets you without writing some code.
Overall, I think these are decent litmus test type questions, though I'm not sure they identify a good programmer as much as they weed out ones who couldn't possibly be good.
I would, however, probably word some of them a little differently. For example, instead of asking "what governs how Perl 5 loads modules", which is weirdly phrased, I'd probably just say "tell me what you know about how Perl 5 loads modules."
Open-ended questions like this are great. A competent programmer can give you a certain level of answer, and someone who really knows Perl well can elaborate and demonstrate that knowledge. I generally prefer questions that help me evaluate a person's range of knowledge, rather than a binary yes/no type of evaluation.
@autarch, I think you're over-thinking the question (or the phrasing). I think he just means this: @list = %hash. Or more typically, perhaps: foo( %hash ).
I'm ashamed to admit that I actually knew that a hash in a scalar context returns a string that looks like a fraction whose denominator is the number of hash buckets associated with the hash. I wasn't sure about the numerator though.
The most important thing to remember about this is that it's one of the annoying "Don't do that!" operations that can trip up the unwary.
Oh yes, and if you ever get asked, in an interview "What does a hash return in a scalar context?", you should terminate the interview right there. Thank your questioner politely and get the hell out of there at all speed. They're either clueless or insane and even in the current economy there are better people to work for. Like McDonalds.
About "What does a hash return in a scalar context?"
It is useful to know that in a kind of scalar context, namely in boolean context, non-mepty has has true-ish value, while empty hash has false value, so you can write
if (%hash) {
Piers: regarding your "Thank your questioner politely and get the hell out of there at all speed": a bad interview question (or bad interviewer) doesn't mean a bad job, just as a great interview doesn't mean a great job. I've seen some correlation between the two, but not enough that I would rely on it.
Whilst I recognize the value of this list for validating one's skills, and I joyfully went over all of the questions myself, I think this this list is not something that should assist a recruiter's decision to hire someone or not, due to many factors.
One of them is the possible incorrect assesment of the weight of each question, judged in the job requirements context as well as compared to other questions from the list. More can be found here:
http://it-quirks.blogspot.com/2012/10/modern-perl-recruitment-contd.html