When I look around at the good Perl people that I know, most of them did not start in Perl. Good programming translates pretty well from one language to another.

However there are catches. One that was brought up on LA.pm is that good OO programmers who program in Java are generally more interested in remaining Java programmers than they are in becoming Perl programmers. So while there is a selection of good people, they aren't all available for a Perl shop.

If you don't go for experience but just go for smart people, there are two problems. The first is that they will become good but they have a learning curve ahead of them. How do you shorten that learning curve and avoid the pain of some of those mistakes? Hopefully without detracting too much from the performance of your small team?

The second problem is, of course, how to identify them. For instance we have a relatively straightforward CRUD application. So our tech interview hits the skills that you need for that - you need algorithmic common sense, basic knowledge of Perl, to come up with a reasonable database schema for a concrete problem, be able to query that schema, understand OO, and get along with the existing group. The test is fairly language neutral, people both can and have passed our interview with flying colours even though they were very rusty on Perl. But it is not programming neutral. You could be very, very smart and flunk it. You could even be very, very smart and very, very good at Perl yet flunk our interview.

I don't see how to come up with a good test of intelligence that is useful for programming that doesn't share this flaw. Certainly it is known that interviewing is a horrible way to pick them. You could give a general IQ test, but that isn't going to tell whether they have the concentration, personality or motivation to be a programmer. (OTOH I have a horrible personality for a computer programmer, yet I seem to get by.) If you gave me 50 candidates, and there are 5 great ones in that list, I have no confidence that I'd be able to correctly identify any of them.

But suppose that we have a reasonable solution for this problem. How would you propose organizing a Perl team to take advantage of Perl's strengths, yet have room for the mentoring that a smart junior programmer needs?

How would you propose organizing a Perl team to take advantage of Perl's strengths, yet have room for the mentoring that a smart junior programmer needs?

Having the least experienced team member pair program with the most experienced has worked well for me, with pretty much zero drop in productivity of the team in general (over the team sans the inexperienced programmer that is.)

I could have sworn that I'd read a study that backed up my opinion with some vague attempt at research - but Google has failed me.

good OO programmers who program in Java are generally more interested in remaining Java programmers than they are in becoming Perl programmers

Sure, but not everyone is so loyal to a language. I know I'm not loyal to Perl and have taken jobs that didn't involve it. Opening your doors wider is bound to improve your odds.

The second problem is, of course, how to identify them.

All the standard interviewing advice applies. Getting candidates to talk about how they solve problems is usually the gist of it. You try to find people who are interested in programming, rather than just looking for a paycheck.

How would you propose organizing a Perl team to take advantage of Perl's strengths, yet have room for the mentoring that a smart junior programmer needs?

The usual things seems to work: code reviews, scanning the checkin e-mails from Subversion, holding regular meetings, letting people choose what they want to work on, paying for books and conferences, encouraging participation in open source projects, etc.

It isn't that they are necessarily loyal to Java. It is that they have heard such bad things about Perl that they don't want to go there.