You are viewing avatraxiom

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

I'm OK with hiring people from any country, if they can produce good code and speak English well enough to understand requirements and reviews. Also, some states in the US are a lot cheaper to live in than others, so I still get a fair number of US applicants. I even get some who live in California. I'd never expect you to apply for the job (and I wouldn't even have a need for somebody at your level), but I think it's totally reasonable for a lot of people in the world. In any case, it's a very-part-time job (less than 20 hours a week), and I don't think anybody would be depending on it as their primary support for existence. I get a lot of people who apply as an extra job, something to do on the side that might be more interesting than what they normally do, and also a way to make a little extra money.

-Max

(Anonymous)

Re: How not to get good applicants

I don't understand how that is a bad rate given it is not a full time position. Full time, yes I would agree, but for a part-time work at home I don't see that as bad.

Re: How not to get good applicants

Skills cost money, it's that simple. Part-time or not, I'd expect someone who's beyond the intern/student/total beginner level to charge at least 50-100% more. That's based on living in the US or some other developed (expensive) country.

Re: How not to get good applicants

Everything that avatraxiom says is fairly reasonable, but that rate is quite poor. I wouldn't expect a competent Perl programmer at that rate. If they're competent and looking for work, they can do much better than that.

Re: How not to get good applicants

Possibly. But probably not with the same flexibility. In any case, my current engineers are quite competent, and they make around that rate.

-Max

Re: How not to get good applicants

Do you mean regular employees or contractors? If they're contractors, they're woefully underpaid for what's being asked for. On the other hand, in this economy, I suppose we take what we can get :/

Re: How not to get good applicants

They're part-time subcontractors. And when I say "competent," I mean "they're good enough as long as their code goes through me first for a few reviews." Some of them we might pay more if we could do it economically, but we really can't. It's still a lot better than the what companies pay to terrible low-quality offshoring shops.

-Max

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.

Re: How not to get good applicants

I have several people at those rates currently, and I have to review their code before it goes out to clients, but I'm OK with that. I'm not looking for somebody who can produce things perfectly the first time out, just somebody who can produce a good product within a reasonable number of reviews.

And in response to your comment about OO, I did say, "There are ways to write good, structured code that aren't OO", and I also limited it with "By and large." I suppose mostly what I see there when I'm discarding things with that are things that clearly should be OO and aren't--or at least should be using modules, and isn't. :-)

And you know, I hear that argument often, that you can write good code without OO, and I've seen it in libraries, but in applications, no. I haven't seen any app of significant size that was readable and easy to understand without objects.

-Max

(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.
I've been hiring like this for years, and we deliver projects perfectly well. There's a code review process--I don't just ship people's code off to clients without review. :-)

Anyhow, it all works perfectly well. Saying "it doesn't work" is pretty silly, since it's already been working for quite some time. :-)

-Max

(Anonymous)

Please

Let's say I have a full time job (which) I do and it has great benefits (which it does). So everything that I would be making under this job would a) fit my schedule as it isn't a lot of hours and b) gravy because it is just added income. Now maybe someone who is Perl guru wouldn't take that but for someone like me who does small Perl stuff but wants to learn more it is a good opportunity because through the code reviews I would get to learn.

I see that as a proverbial "win-win".

Re: Please

Yeah, that's what a lot of our applicants say, too. :-)

-Max

Is there a Squirrel module to offset Moose?

Having seen some Moose code, and not using Moose myself, it seems that if you want Moose coders you should ask for Moose coders. Like other OO frameworks, it abstracts out isa and hasa relations and so on using explicit syntax. However isa and hasa are supported perfectly well without it, making it a crutch.

I guess if you've standardized on Moose and are finding major benefit from it, that's great for you. Moose code however is not Perl code, it is Moose code.

Re: Is there a Squirrel module to offset Moose?

There is a Squirrel module, it's in Mouse. :-)

Otherwise...did you misunderstand what I was saying?

-Max

(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?

Re: I agree, not a good rate

The posting was pulled because we just had enough applicants and enough potential contractors. It's positions (plural), really--we can hire a virtually umlimited number of contractors, since we just give out work when we have it, and the more people we have available the better.

-Max

(Anonymous)

Re:

Note: If you use Moose, it automatically turns on strict, so don't think all code is bad which doesn't explicitly have "use strict".

Re:

Of course. :-) If it uses strict, then it's fine, no matter how it does it.

-Max
To The Side

November 2010

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
282930    
Powered by LiveJournal.com