In addition to concerns for your development shop's technical maturity and your development shop's culture, a good Perl shop has certain characteristics.
As always, you don't have to have answer these questions the same way I do. It's not a contest—but if you haven't considered these questions, or if you don't understand them, or if you think they don't really matter—you'll probably have trouble finding and retaining talented developers.
The best development shops I know have remarkably similar answers to all of these questions.
- Do you build your own Perl?
- Do you build your own Perl because you have custom patches?
- Do you stick with the vendor Perl because it's what's available?
- Do you use CPAN modules?
- Do you have a defined process for adding new CPAN modules to your stack?
- ... in less than a week?
- Do you have a defined process for updating to new versions of CPAN modules?
- Do you report bugs in CPAN modules?
- Do you report bugs in Perl?
- Do you include test cases or patches when applicable?
- Do your developers have PAUSE accounts?
- Do they contribute to CPAN (docs, tests, patches, feature requests, bug reports, mailing lists)?
- ... on work time?
- ... in their personal time?
- Have you extracted CPAN modules from your code and released them?
- Does your interview process include writing (and explaining) real world Perl code?
- Do you reuse code between projects?
- Do you have your own company framework?
- Is it built around a CPAN framework?
- Is it a CPAN framework?
- Do you use automated tests with the standard Perl testing tools?
- Do you participate in a local user group?
- ... sponsor it?
- ... sponsor a workshop?
- ... sponsor a YAPC?
- Do you post job openings on jobs.perl.org?
- Does your company library include multiple copies of the standard Perl books?
- Do you use the standard CPAN tools for organizing your code?
- ... for documenting your code?
- ... for testing your code?
- ... for distributing your code?
- Do you have your own DarkPAN?
- Do you test it against new Perl 5 releases when considering when to upgrade?
- Do you test it against Perl 5 release candidates?
- Do you test it against monthly blead releases?
- Has your company contributed time or money to Perl 5 core development?
- ... to the development of a CPAN distribution?
Many great shops can't answer "yes" to every one of those questions, and that's fine. If you answer "yes" to at least half of them, you're in good and rare company.
What else should be on the list?
If you'd like a detailed discussion of how to apply this list to your own company, I'm available for consulting.
It might be worthwhile to reconsider the wording on some of the list items in light of this closing statement.
e.g. Do you stick with the vendor Perl because it's what's available? and (more arguably) Do you build your own Perl because you have custom patches? typically aren't desirable.