interview questions

Here's the general direction I'd take with respect to Perl knowledge (vs. a lot of other things I'd want to consider when hiring):

A) Tell me what sorts of things you have used Perl for.

B) Have you used the object-oriented side of Perl a lot? If so, tell me about a module you have written. What were your considerations in creating objects and methods?

C) How familiar are you with the resources at CPAN? [Here, if I had a particular knowledge area (such as, say, bioinformatics) needed for the job, I'd ask if you were familiar with modules for that particular application area. Even if there's no current need, I'd want to know if you've used DBI and related modules to work with a database.]

D) Have you ever found that someone else's module came close, but not quite close enough, to doing what you wanted? What did you do then? [Looking to see whether the impulses towards rewriting vs subclassing are in proper balance.]

E) Have you had occasion to either extend Perl with functions written in another language?  Have you ever had occasion to embed Perl into another application?

F) What do you know about Perl compilers? Have you used them? What problems did you encounter, and how did you resolve them?

G) When you are developing a Perl program, how do you go about it? Do you have a favorite editor or IDE? (Have you even _tried_ an IDE?) How do you debug your Perl program? Tell me about a recent bug you had, how you went about uncovering it and what you think caused it.

H) Are there any other Perl-oriented products that you have experience with? [e.g. extending VIM with Perl? Apache mod_perl? Mason?]

I) Can you contrast the features and qualities of Perl with some other programming or scripting language? What things do you consider Perl to be especially well-suited for? [And are there things for which you don't consider perl to be well-suited?]

J) What can you tell me about Perl6? Parrot? [Just to see if you're keeping up-to-date.]

I would expect through the discussions arising from these questions to get a better handle on how well you know various details of Perl, something about your style of solving programming problems, and perhaps how well you'd be able to interact or mentor other Perl programmers.

My list of books:
(Learning)
1. Learning Perl 3rd edition - O'Reilly.
Since you're pretty knowledeable about perl, it will, in the best case, streamline your knowldege, nothing more.
2. O'Reilly - Learning Perl Objects, References and Modules
More advanced perl. Same author as above, same (great) quality. (It's Randal L. Schwartz whose columns you can read on http://www.linux-mag.com/ and http://www.stonehenge.com/merlyn/columns.html)

(Hardcore books)
3. Perl Cookbook (yes before programming Perl) - IMHO, THE book. You can use it as a learning tool, i.e read the question, try to solve it, and go on and see how the gurus has solved it.
4. Programming Perl - "The Camel book", great reading, reference and whatever you wish and more.

(Two goldies-oldies)
5. Advanced Perl Programming
6. Effective Perl - great tips and idioms. Part of it was available at http://www.effectiveperl.com/ but now it seems down.

(Specific areas)
7. Manning - Object Oriented-Perl (good but I've had no time to read even a third of it)
8. Addison Wesley - Perl Medic. Transforming Legacy Code (VERY good)


Want more? ;-)

Putting PERL instead of Perl in your resume is a big red flag to say you are not too experienced with Perl.

See the Perl FAQ regarding the difference.

manav:

In the past, when I've done interviews I generally asked for a portfolio or samples of the person's work. I have also been sneaky and preceded the question by asking what projects the person has previous completed. I have caught more than one person who indicated that they've done 'X' project but couldn't provide any samples or insight as to how they did it. (At least at the organization I work at) We have never hired someone for a dev position that didn't provide code samples.

In our development departments, there are very few (if any - I can't think of any off-hand) people who know only one language. Most have at least 3 or 4 in their toolkit (With perhaps a specialty in just one) and cursory knowledge of far more than that.

Another item that we've focused on is whether or not the person has any knowledge of software design and how to manage large projects. Version/Release management, CASE, design patterns, modelling (UML) are some of the soft skills you should be prepared to discuss.

As Tintin mentioned above, for any role requiring Perl knowledge, I immediately throw out resumes which indicate 'PERL' in place of 'Perl'. The language is called 'Perl'. The interpreter is 'perl'. There is no 'PERL'. And as a side note, only perl can parse Perl.

Hope this helps.