How to spot bad Perl code, 2008 edition

| 1 Comment

Max Kanat-Alexander posted an article called "How Not To Get Hired.". Since I'm in the end stages of finishing my book on geek hiring, I was hoping there would be swell interview horror stories. The first bullet talks about not following instructions in a job ad, but the rest is really a laundry list of Perl practices that nobody should be doing any more, and a few more on what we should be doing, starting with using Moose.

I'm sure there'll be some crabs out there who say "Aw, that's just all common sense," but common sense rarely is. It's well worth a read.

1 Comment

Hey, thanks for the link, Andy. :-)

Yeah, there aren't any interview horror stories because generally, I actually don't do interviews. Honestly, until now I haven't had enough applicants to even consider it, but in any case, by and large I can tell almost everything I need to know from reading somebody's cover letter and their code. I just get very aggressive about eliminating people for flaws in their code. (Although you don't have to get that aggressive, really--a lot of them are pretty bad.) After all, I asked for a code sample that people consider well-written, so if they think that flawed code is well-written, they probably don't have the same standards that we do.

Also, we run almost every applicant that we're interested in through a training process where we basically just make them submit a patch to Bugzilla and go through Bugzilla's normal code review process. It shows them how our internal process will be (since we use basically the exact same process), and it's one of the best ways I know to find out what it will really be like to work with somebody, far better than an interview or any probationary period. Since the training period is uncompensated, there's no risk to us, it's possibly beneficial to the Bugzilla Project, the trainee gets familiar with the codebase, and if things don't work out, it's very easy to just say no thanks.

Now, as far as "common sense" goes, I've gotten maybe 50 applications so far ( FTW!), and out of all those, I'd say 11 of them didn't have any of those critical mistakes. Maybe two of them did anything in the list of "good things" (both of whom we have now responded to). So you're right--it may be common sense to us, but it's definitely not all that common.

One of the most interesting phenomena I'd come across was people whose code was actually fine, but they had a gigantic case of NIH. Even though most people might think of just style and architecture when they think "well-written code", I really think that code re-use is an integral part of code being well-written. So even if somebody sent me code that was nearly perfect in style and architecture, if it was all just a pointless reimplementation of things that everybody knows are on CPAN, I'd cut them from the "yes" list.


Leave a comment

Job hunting for programmers

Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.