How to Identify a Good Perl Programmer | Hacker News Reader

How to Identify a Good Perl Programmer

modernperlbooks.com

60 pointsrcfox37 comments

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).

I did the same thing. Got tired of .NET and the attendant environment, walked into a Django job mostly blind, fell in love.

The next job will be Python too, although I've always got me eye out for that chance Clojure gig. :)

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'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.

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 can write a lot of Perl code without ever needing array slices, but I agree on the last two questions.

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.

Oh, certainly. But it's hard to write a lot of perl code without accidentally writing an array slice. At least, I find it hard.

I like that as an answer: "the difference is you almost always want $items[$index] and rarely @items[$index] but somehow frequently type the latter"

Indeed, as this poor student discovered the hard way...

http://yro.slashdot.org/story/01/03/13/208259/Sophomore-Uses...

Believe the Camel when it says -- third edition, page 69 -- "You will be miserable until you learn the difference between scalar and list context."

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. ;)

No. You just look at their code. You can scan sample code in 5 minutes and determine how well someone knows the language.

I won't even consider having an in-person interview with someone until I've seen their code. It's just too often a waste of their time and mine.

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.

My advice to people in that case is to pay some well respected person whatever it costs to help you hire (evaluate code samples at least).

http://www.stonehenge.com/consulting.html

"Human resources hiring support, including interviewing and evaluating candidates"

I would at least have someone like merlyn hire your first person.

P.S. I do think it's a good list of basic Perl knowledge. Id on't think it's smart for someone who doesn't know the language to hire people though.

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.

[1] http://www.stonehenge.com/staff.html

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.

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.

Well said. The bulk of my recent code is simply not available for public 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. :(

Now lets wait for a stream of posts titled, "How to Identify a Good X Programmer".

I would be waiting for the Python one.

"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'm not certain it's the answer he's looking for, but I'd probably start with 'perldoc -f keyword'. Are there better ways?

That's the approach I had in mind.

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 about 1/3 of them and have been programming in Perl for 8 years now. Perl's not one of my primary languages though.

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.

I was wondering why I should know how to write tests in CPAN modules or when Perl 5 reclaims memory to be a 'good' perl programmer.

Still a good list, though.

> 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?

I think he means something like

  perldoc Data::Dumper
  perldoc -f use

1) A long, grey beard

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.

Unless you are trolling, just define 'more productive and useful'.

Age is not an important property of a programming language.

If their code is an unreadable mess of slashes and dollar signs they must be a good perl programmer.

Reply on news.ycombinator.com