1) I'm of the school that measuring trivial knowledge is not a good way to identify good programmers - merely knowledgeable ones. The two can be correlated, but it's certainly not surefire. Lots of java programmers have passed the certifications, which are similar to this list of questions, but are not "good".
2) Good hiring effort for programmers should, imho, focus on hiring great programmers in any language. They need to be willing to learn Perl, but unlike, say, C++, Perl isn't the sort of thing that should take more than a month or two at the absolute most to be proficient at if you're a good programmer.
On point 2, one of the best Python programmers I've ever known was a great Java programmer until the day he was hired by a Python shop...and then he became an amazing Python programmer. Great programmers are not tied to a particular language, though they do tend to prefer better languages (one of the reasons the great Java programmer took a job at the Python shop was so he could work in a better language).
Also, while the article describes a reasonable way to identify programmers with Perl domain knowledge, I've rarely worked at jobs where that was "enough" to hire someone. System domain knowledge and problem domain knowledge are both at least as important as language domain knowledge.
I've never needed to hire "a Perl programmer", I've needed to hire people in much more specific categories like "someone to work on a webapp written in Perl for a travel company" - where system domain knowledge (knowing about things like SQL injection, XSS, character encoding, SOAP and it's lack of and "S", session management in http, authentication and security), and problem domain knowledge (some understanding of the travel industry, ecommerce, online credit card transactions) is at least as important as their Perl knowledge. I suspect in a lot of cases it'd be easier to buy a copy of Perl Best Practices for a candidate with strong system and problem domain knowledge but limited production Perl experience and have then thrive in the above role, compared to someone with a complete understanding of Perl's syntax and gotchas who's never worked on a consumer facing web app. By the same argument, all the ecommerce specific perl web app experience in the world won't on it's own win you a bioinformatics/data mining job (with me) over a Python or Java guy with in depth biology knowledge...
On an even higher level, it's easy to poke fun at Google/Microsofts hiring gameshow style questions, but they're trying (however badly) to identify/recognize problem solving skills, which are completely language agnostic. A solid grounding in algorithms and data structures, and the ability to do back of the envelope calculations based on reasonable assumptions/estimates (with supporting reasoning and error bounds for those estimates) is a very different skill to "just programming", and people possessing those skills, while in a small company will still be "a programmer", in a larger shop (like Google) would have a role perhaps better described as "project architect" or "system designer". Being able to answer with good explanations behind your reasoning "how many gas stations are there in America?" or "why are manhole covers round" might not be relevant if your hiring a programmer to modify Wordpress or write a Magento plugin, but people who _can_ discuss and answer those sort of questions are demonstrating a much higher level of skill than just knowing whether arrays are passed by value or reference in programming language de jour...
Medium and large companies need the article's advice much less than smaller companies, where the difference between someone who knows enough to download example code and modify it until it does something and someone who has current and effective language domain knowledge is much, much more significant.
I'm of the school that measuring trivial knowledge is not a good way to identify good programmers
I'm right there with you, but this list isn't trivia. It's a broad set of basic questions. In fact, these three . . .
- What's the difference between accessing an array
element with $items[$index] and @items[$index]?
- What's the difference between == and eq?
- What do parentheses around the variable name in my
($value) = @_; mean, and what would happen if you
removed them?
. . . are so critical that if you can't answer them instantly, I would expect you to experience long, painful debugging sessions on a daily basis.
You don't have to know about array slices to answer that question effectively. You get a bonus for knowing about array slices, but the most important point is understanding the difference in context.
I'm of the school that measuring trivial knowledge is not a good way to identify good programmers....
I've been studying how to train novice programmers for a long time and programming even longer. Any decent Perl programmer should know the answers to these questions. (Anyone who can't answer most of these questions with ease doesn't understand the language.)
Certainly these questions are not the only questions you should ask in an interview to find the right person, but if you want to know if the interviewee understands Perl 5, these are effective questions.
" ... but if you want to know if the interviewee understands Perl 5, these are effective questions."
Yep, the more I think about it the more impressed I am with that list.
It very neatly encapsulates a whole lot of Perl idiom and knowledge of common Perl errors (and "modern" ways to write Perl to reduce them), as well as more general "modern" programming techniques as used in Perl and the way other language's concepts are used/described in Perl.
Great list Chromatic, consider it added to my hiring resource arsenal.
2) Good hiring effort for programmers should, imho, focus on hiring great programmers in any language. They need to be willing to learn Perl, but unlike, say, C++, Perl isn't the sort of thing that should take more than a month or two at the absolute most to be proficient at if you're a good programmer.