I work for a company looking for Perl developers, and I have a friend who is a manager at another company looking for Perl developers, and one thing I notice is that we although we're both looking for "Perl developers", we don't really mean the same thing. And I suspect many people aren't really aware that they mean something completely different from other people, because they have such a strong association with Perl being used for a particular application domain.

For example, to some people Perl is the heavy-lifting tool for system administration, so a "Perl developer" is going to be working on automated systems for managing applications, servers, etc. Or maybe log file processing. These developers need to know a lot about how machines work, shells, IPC, security, networking, etc.

Other people assume that Perl is a shorthand for "server side web applications". The job reqs here often include HTML, Javascript, application architecture, scalability, load balancing, etc.

Another group, not completely distinct from the previous, just thinks of Perl as a language for building large applications. Those developers will need some of the same skills as the previous list, but will also benefit from domain-specific experience, which could be graphics, networking, social networking, banking, streaming porn, ....

A fairly small segment uses Perl as an extension language to a larger system, probably written in C or C++. A candidate for such a job would need all the traditional CS skills plus experience with extending and embedding, cross-language resource management, understanding of linking and compiling and licensing, etc.

All of the above, of course, also require knowledge of Perl. Or maybe not -- there are enough other constraints on the position that a lot of employers would be happy to find all of the other qualifications, and let the employee pick up Perl on the job.

But my point is that the phrase "Perl developer" is too restrictive a definition, and one needs to be more explicit to get useful feedback. Admittedly, I usually complain about the difficult of finding Perl developers too, without bothering to qualify it with exactly the sort of person we're looking for. But it's easy to find people who know Perl; it's just that 99% of them know it for a purpose far too distant from what we need, and unsurprisingly don't have the rest of the qualifications needed for the role. A strong sysadmin is going to have a much easier time picking up Perl than a strong web Perl programmer is going to have picking up systems administration.

Oh yeah. And if you happen to be a very good Linux applications developer, preferably with a knowledge of Perl and/or OpenGL but not necessarily, drop me a /msg. Or if you do web site backend database-y application stuff, which is what my friend is looking for. I think. (Oh, and sorry -- no >50% telecommuters for either of us. Why not is a whole separate topic.)

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.