How to Identify a Good Perl Programmer

[swombat]

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.

[SwellJoe]

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

[Dove]

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.

[chromatic]

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.

[angusgr]

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

[staunch]

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.

[chromatic]

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.

[gcheong]

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.

[shuaib]

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

I would be waiting for the Python one.

[Isamu]

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

[nkurz]

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?

[bugsy]

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.

[Natsu]

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.

[lysium]

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.

[drdaeman]

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

[patrickas]

I think he means something like

  perldoc Data::Dumper
  perldoc -f use

[gaius]

1) A long, grey beard

[updog]

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.

[lysium]

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

Age is not an important property of a programming language.

[nroman]

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