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.
If I was trying to find a good Perl programmer, I would try to read some of their code before asking a single question. If I could read it, that's a good first step.
Because you can know the answers to all of those questions and still write "write-only code." Easier in Perl than in most languages. ;)
That's a better approach if you know the language well enough to analyze their code. I didn't write that list for people who already know how to hire good programmers.
so.. if you don't have any knowledge on perl and you want to hire a perl programmer you first.. hire a perl programmer to help you ? won't that put you back on the step 1 ?
It's much easier to check the credentials of the relatively few people who offer such services. For the above example, you'd find that the Stonehenge people [1] have a long history of contributions to Perl and an excellent reputation.
How much code and what type is enough? All of the perl code I've written is safely behind company firewalls that I no longer have access to. I could probably whip up something of a trivial nature on short notice, but nothing that would have seen any production use.
I'm thinking that's a good reason to contribute to some open source projects. Unless, of course, your employer prohibits you from doing so... in which case I has a sad for you. :(
More code just increases the reliability of the assessment. Even a very small amount of code is enough to decide whether to skip the resume or follow up on it.
Unless their name is on a (good) Perl book I'd skip over anyone who won't submit even a small code sample.
"How do you look up keywords in the Perl documentation?"
I hope there's a new clever answer to this that requires fewer keystrokes than google instant.
Because the Perl docs are a ... heap. To some extent finding what you really want but can't remember is a real skill - I don't know what novices do. They probably do without, truth be told.
And I say this with some affection, having spent countless hours of my life wandering the docs. And the various books.
I don't want to sound like I'm slamming perldoc, but you see, even its use is a programming aptitude question. The help is probably not that helpful for novices.
Note that offering 'perdoc -f' shows that you are interpreting "keyword" in the original question as "something that resides in the perlfunc list". Fairly specialized knowledge.
I can answer a lot more than that, but, err... I don't use POD much thanks to Google and my bookshelf. And my programs live in places where the only people who ought to be reading the documentation are other programmers, who will be looking in the script itself.
> How do you read the documentation of a core library?
Ahem... I have read a lot of Perl5 documentation and the only response I can think of is "I don't know, probably with my eyes open" (yes, that's rude). I just find what I need (by means varying with the situation) and read it.
No, seriously, could someone explain me this question, please?
Easy, the one that dumped perl a decade ago. It is truly archaic and has no place in a production environment anymore. The only people still using it are resisting change to a more productive and useful language.
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.