?

Log in

No account? Create an account
To The Side

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: ,

Comments

How not to get good applicants

You're offering $25-35 as a 1099 rate. What exactly do you expect?

Re: How not to get good applicants

I expect people to at least "use strict". :-) I don't expect high-level architecture and completely lovely code, but I expect not to see a rambling mess, which is mostly what I see.

Also, given the flexibility of the position, I think the rate is reasonable. It might not work for somebody who lives in Silicon Valley, but it's more than, say, a web developer might make.

-Max

Re: How not to get good applicants

That's a terrible rate. As 1099, you have to pay the full FICA (15%) plus your own benefits, insurance, etc. $25/hour 1099 is perhaps comparable to $15-18 as a W2. Either way, it's a shit rate.

Of course, if you're okay hiring people from other countries I'm sure you can get someone at that rate. I don't think there's any reason to think that a coder from India at that rate is any _worse_ than an American coder at that rate, but they probably won't be better.

Re: How not to get good applicants

Flexibility is great, but it's not worth $10-15/hour, especially on contract. Maybe you'll get lucky with one of those great Perl programmers that telecommutes out of Boise, but at that price you really are begging for someone from another country who programs "PERL" (a sure sign of doom) or someone who wrote a couple CGIs in college but has mostly been doing C++ on Windows since then. I'd be curious to hear how satisfied you ultimately are with whoever you do hire. (Then again, there's a recession on, so maybe I need to adjust my salary expectations. =))

I also take issue with your OO requirement, since there are plenty of problems where OO just isn't a good fit, and using it just means it's the only tool in your toolbox. There are encapsulation and abstraction *aspects* of OO that are certainly worth requiring, but to say "your design must be OO" is short-sighted.

(Anonymous)

Re: How not to get good applicants

I think that is fine given the hours and flex. If I was better I might apply as it could be just little extra income on top of what I currently do. Doesn't excuse not sending in good code examples.

(Anonymous)

Do you care about tests at all ?

What would you do if someone sends you code and they have not done any of the above mentioned but they have used TDD and have a good coverage of their code and it makes it easier to refactor.

-mkirank

Re: Do you care about tests at all ?

Oh, yeah, TDD is good too! I knew I was missing something in the list, actually. :-) Tests are another really nice thing to see.

-Max

(Anonymous)

The counterpoint, however, is to hire potentially good people at the entry-level you offer and train them in the good practices. Everyone in the industry wants to hire people that already have all of the good development skills, but nobody seems to be willing to take the rest of the applicant pool and convert them. Not everyone will end up with good habits, but a lot of people with bad habits can be properly trained.
Sure. It's all a matter of the type of job you're hiring for, too, and how many applicants you get. If you get like, two applicants for a job, you're more likely to consider training them up to the level you need. :-) If you get 50 and you can pick and choose a little more, then it's a different story.

-Max

(Anonymous)

Moose for 20$ an hour ? First of all, I can hardly imagine someone
on this rate who can use Moose consciously. The rest, may be yes.
Very much may be. You wont get a decent one, unfortunately. And your reqs which is just a tiny subset of simple perlcritic ruleset are not going to
get you even a more or less a good one. Even if this person will convince you in his credibility.
Think twice. For 50$ an hour you will get a person who can make job done in 3 times less time and delivered a way better code. If you think that a guy on 20$ will get experience on your project and keep asking 20$ then you are fooling yourself. In the past several years I never seen a decent perl coder who was able to deliver a project and was asking less than 50$ in US and less than 30$ with location in other country. Period.

(Anonymous)

OK, I'll bite...

Why shouldn't I call variables $A and $B? Just because those names are meaningless? Are you thinking of $a and $b from sort? And what do you mean by "local"? Literally "local $A = 'foo'"?

Re: OK, I'll bite...

Yeah, because they're meaningless. In a sort comparison function they're fine. But I'm talking things like "my $A;" inside a function being used for some strange purpose. Also, perlstyle recommends that all-caps variables be used only for constants (which is fairly accepted and used standard).

-Max

(Anonymous)

I agree, not a good rate

From the coders and code that I've seen in my career, I would likely choose a higher-paid but better programmer than a cheaper, worse one. Besides getting work done more quickly, that better programmer will also write code that can more easily be extended or added to, be more secure, and generally perform better. You would also need to review the code less, thus saving you time and money as well.

But then again if you're making small, non-maintained apps then perhaps an entry-level programmer with code reviews is a better fit.

Re: I agree, not a good rate

Yeah, that's what we're doing, is mostly just doing one-off Bugzilla customizations for clients.

-Max

(Anonymous)

Re: I agree, not a good rate

I see the posting has been pulled. I am sure that means it was filled. I was wondering if there was a way to get on a wait list?