Interview question - What is your favourite Perl CPAN Module?

[OwlHoot]

I have an interview for a perl contract soon, and the job spec
mentions "familiarity with CPAN", which leads me to believe
they may ask some off-the-wall question about this.

In an interview I was once asked what was my favourite Perl CPAN
module, and instantly gave the honest answer Data:umper. As
I didn't get that role, despite successfully contracting in perl for
several years, I gather they were looking for something more
impressive, (or something other than a core module ),
such as those modules summarised on the excellent perl
Advent calendars.

So anyway, to help me "gird up my loins" and prepare for this
interview, perhaps some Perlites here might like to suggest
answers, or offer their opinion (with reasons ideally) on the
following:

1. What is your favourite Perl CPAN module?

2. Which (realistic) CPAN module or framework would you
most like to see that doesn't currently exist or is only
partially complete?

and please feel free to suggest other "interviewy" kinds of
questions relating to CPAN. Perhaps that will be more
useful than anything - Answering questions I haven't even
thought of asking!


Cheers

John Ramsden

 

[Peter Makholm]

In an interview I was once asked what was my favourite Perl CPAN
module, and instantly gave the honest answer Data:umper. As
I didn't get that role, despite successfully contracting in perl for
several years,

If this is the primary reason for not getting the job I wouldn't like
a job there. They are too simplistic in their view of perl knowledge.

I like the question, but as a interviewer I couldn't care less about
the exact module you answer would be except for a few modules like
Chooser.pm (What the hell that it abount?).

What I would really like to use the question for was to start a more
free form discussion where you could prove or disprove you general
knowledge of perl. For you favourite module you should be able to talk
what you would use it for, existing alternatives on CPAN, how to
implement you own alternative, possible improvements, the worst part
of the API, when not to use you module, and probably much more.

Not neccessary a long discussion about each question, but at least
something sensible about many of them. For example I wouldn't expect a
lot knowledge about reimplementing PadWalker if that was you favourite
module.

So anyway, to help me "gird up my loins" and prepare for this
interview, perhaps some Perlites here might like to suggest
answers, or offer their opinion (with reasons ideally) on the
following:

1. What is your favourite Perl CPAN module?

JSON::XS would be high on my list even though it is even more
primitive than Data:umper. The interesting thing is where the
interviewer and I could take the discussion from there.

2. Which (realistic) CPAN module or framework would you
most like to see that doesn't currently exist or is only
partially complete?

I would very much like Moose and Plack reach a point where the versions
provided by my OS-vendor was sufficient for 95% of the uses.

But just saying this is the boring answer. The interesting part is the
'why?' that the interviewer shoudl follow-up with.


Just being able to give pre-cooked answers isn't going to get you an
intersting job. You should be able to argue for you answer.

//Makholm

 

[Scott Bryce]

1. What is your favourite Perl CPAN module?

Whichever one best helps me solve the problem I am currently working on.

 

[Martijn Lievaart]

1. What is your favourite Perl CPAN module?

The one I need, and is installable as a package in my current OS.

I install modules from CPAN as needed, but try to keep to the ones
distributed with $current_OS. Obviously, this is only mildly portable.

M4

 

[sln]

One obvious question, which I've used in the past, would be "how often
do you use CPAN?" If it's not very often, I can speculate that the
person is writing a lot of his own code instead of using what's already
out there.

--keith

If often, I can speculate the person doesen't know how to write
code and shouldn't be considered a developer.

-sln