Max (avatraxiom) wrote,

How Not To Get Hired

So, I recently posted a job on jobs.perl.org (which, by the way, I highly recommend if you're looking for Perl programmers) and a few other places. One of the things that the posting asks for is a code sample--one that they consider to be well-written. Reading these has been a very interesting experience, and I thought that perhaps some of you might find it enlightening (or amusing) to know what particular things will make me immediately discard somebody's application:

  • If somebody doesn't submit a code sample at all, that's a very easy "no." If somebody can't follow a simple instruction like that (which is very clear in the job posting), then imagine trying to communicate client requirements to them!

    Some people have the problem that they always wrote proprietary code and they don't have the code available now to send. Okay, I understand that. But that also means that you've never written Perl for any personal project, and never contributed to any open-source project, neither of which are good indicators. (This is a good reason to work on open-source, by the way--it'll get you code samples that you can show prospective employers, later.)

  • The very first thing I will notice in a piece of code is bad indentation or no indentation. If your code has no indentation or the indentation varies all over the place (or you mix spaces and tabs), I'll just toss it immediately. It could be the most amazing code in existence, but who cares? I have about two minutes to read your code, and if I can't read it easily, I just won't read it at all.
  • Send me any code that doesn't "use strict", and it will go into the garbage. This is 2008. Perl 5 came out in 1995 people. Let's get with the picture, here. I don't care if somebody doesn't "use strict" in their little personal projects, but I ask people for a code sample that they consider well-written. If someone thinks that a lot of undeclared globals make for good code, then I don't really want them writing for my clients.
  • If you name local variables things like $A and $B.... I don't think I have to explain this one. Reading the perlstyle manpage is not such a bad thing to do.
  • If you write a few long comments without any punctuation, grammar, or complete sentences, then that's what I expect you're going to do when writing code for clients. I understand that some people don't speak English as their native language, but from what I've seen, the problem is more likely that the coder doesn't care or is a native speaker but doesn't have the requisite command of English to actually communicate sensibly.
  • Don't print out a bunch of HTML in your Perl code, please. Just use templates. That's what they're there for. There's like, a zillion templating languages available for Perl, and it's really not that hard to use them. The Bugzilla Project put a lot of effort into moving to templates many years ago, because templates are a good idea.
  • By and large, I'll discard anything that doesn't use at least some sort of object-oriented principles. There are ways to write good, structured code that aren't OO, but they're not that common, particularly in Perl.
  • SQL that doesn't use placeholders makes me suspect that either you're not that familiar with DBI or you're traditionally a PHP coder. If you're at least inserting things with $dbh->quote, that's good, but given the number of applicants that I'm getting, it's not good enough.
  • Even if your code is good, if you're re-inventing the wheel, that makes me suspect that you'll do the same when I give you work. I want my engineers to use the CPAN modules and great open-source software that already exists, not re-write their own webserver or something else like that.
  • Using features correctly is good, mis-using them is bad. For example, I love to see POD in modules, but please use it standardly. There are ways to make lists of items (=over and =item)--if you want to make a list of items, that's what you should be using.

Also, some people are clearly spamming every job posting that they find--they have no cover letter to speak of, they don't respond to any of the specifics in the posting, and they attach no code sample. Maybe they think they're improving their chances by emailing everyone, but it's just spam--the chances are that it will be deleted without your resume being read, really.

Now, just to balance things out, there are a few things that I really like to see:

  • Use Moose! This tells me that you're up on the latest developments in the Perl world, and that you probably have some good grasp of CPAN.
  • Write POD for your modules. It's nice when people care enough about their code to document it properly.
  • Correctly use CPAN modules, particularly modern ones.
  • Use taint mode in your CGI scripts. Most people don't send me CGI scripts, but if you do, it's nice to see that you care about security. And Bugzilla uses taint mode, so it's cool to see that people can use it correctly.

Really, I want to see that people care about their code. This is professional development, not just local sysadmin Perl hacks. And anyhow, you're sending your code to me--and I put a lot of care into even my local sysadmin Perl hacks. Probably the hackiest thing I ever contributed to Bugzilla was recode.pl, and it's still better than most of the code that people send me.

-Max
Tags: perl, tech
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded  

  • 31 comments