Divas Need Not Apply
A couple of days ago, we posted a job on jobs.perl.org. We wrote:
Description: Want a remote Perl job working for a great company with colleagues from all around the world? We're considering both permanent and contract positions for a variety of Perl roles. Front-end skills are always welcome and experience with parallel programming comes in handy more than you would think.
We do set a high bar on who we employ, so if joining a bunch of Perl hackers who love the language sounds like fun, send us your CV and we'll send you our programming test. In return, because we value your time, Ovid will be evaluating the test and will send you feedback on how you did and areas for improvement, if any.
Desired skills: Perl. Strong Perl. You love the language. This is the only solid requirement.
Front-end skills (HTML, CSS, JS, not design) are often very useful.
Expertise with parallel processing, including event-driven programming, is needed.
Good communication skills.
Understanding databases is important.
The specifics of the job are vague because there's more than one position (and NDAs), but the requirements are reasonably clear. Note that as of this writing, we posted that two days ago, and that's when the fun began (and if I grade another Perl test, I'm going to scream, but boy, does that weed out candidates quickly).
But before I discuss that, a bit about our company so you can know where I'm coming from.
First, if you've never run a consulting firm, it can be hard to appreciate the work involved in finding good developers. Hiring the wrong person is a huge disaster, particularly for a consulting firm which can quickly have a contract cut off. So we try to be careful. However, we have a lot of stuff to do. The amount of work in running a company like ours is enormous, involves overtime, and trying to do our best to ensure our devs have everything they need to succeed, but still keeping clients happy, too.
I think we're fairly flexible. We have more than one dev who's only working part-time. That's harder for us to juggle but we understand work/life balance. We just had a dev give very short notice on needing two weeks off to visit his mum. No problem. If you ask for time off we assume you need it. Worked late and want to shave some hours the next day? Not a problem. Like to sleep in? Guarantee four hours overlap with the client and you can set your own hours. In short, if you deliver, we've got your back.
In the process of all of this, we've discovered a certain class of developer we refer to as "divas". You know them: they're very talented developers with difficult requirements. Here are some issues we've had to deal with:
- Won't answer email
- Will reject any project they don't find interesting enough
- Refuse to listen to suggestions from other developers.
I don't care how good their Perl is, we have repeatedly found that these diva devs take up so much management time that they're costing us much more than they're worth. We've found that putting together groups of solid Perl devs with pleasant personalities and good communication skills produces far more value for our clients. There is a night and day difference between the two groups: being "good" isn't enough.
Fortunately, I'm insulated from most of this because Leïla handles it and she's very good at it. She's very focused on getting the job done and divas invariably introduce an element of randomness which makes it so much harder to guarantee we can deliver. So no divas.
The Job Advert
Getting back to that job advert.
Oh boy. We have been flooded with respondents. And while I'm trying to deliver for our clients, be a husband and a father, I also have a huge pile of Perl tests to grade. Leïla, on the other hand, has to deliver for our clients, be a wife and mother, work with our lawyers, and answer all of the candidate inquiries. And she quickly weeds out the unsuitable candidates because otherwise we'd be swamped.
Before working for my primary client, I grade tests. After working for my primary client, I grade tests. Leïla takes my assessments, rewords them to be gentler, and communicates with the applicants. And she's doing that while running projects for clients.
Can you imagine how much time that takes? Thus, almost any "red flag" about the candidate is enough to disqualify them. First, the test states its requirements very clearly. These are firm requirements. The test took me two hours to finish (but I wrote it, so that's unfair). For many devs, it will take them a day. We generally give candidates a week to finish it and promise a code review from me in exchange. That's much more work on our side than theirs because they only need to take the test once. Thus, I quickly disqualify candidates who don't follow instructions or take too much time. For example, we deal with stuff like this:
- You asked me to use SQLite but I prefer MySQL, is that OK? (Hint: no. If you can't learn SQLite in seven days ...)
- I didn't include the README you asked for because it should be obvious what's going on. (Hint: no)
- You asked for a Web interface but I provided a CLI instead because it fit the task better. (Hint: no)
- Instead of sending you the code you requested, I've uploaded it to X and I need you to provide me with a public key to access it. (Hint: no)
Honestly, that's the sort of stuff we have to deal with. And the test? It's basically "Here's a data file. Upload it via your Web interface, parse it, store it in SQLite and generate any reports you think are valuable in any format you prefer." The data file, I should add, contains only eight lines of data, including the header. This is not a difficult project.
Because we so routinely get people who don't follow the instructions we send, or ask permission to not follow the instructions, and grading the tests is so time-consuming, we are more than happy to weed out candidates long before they get to that point. That's hard to do because jobs.perl.org is sending us many excellent candidates who send great introductory emails and are strongly interested in the positions.
However, many other candidates send us email like this:
From: Some Developer Date: October 12, 2015 15:17 Subject: jobs.perl.org posting Here's my CV.
You wouldn't believe how common that is. When your subject line is longer than the body of your email, you didn't pass the "good communication skills" requirement.
Or we get people saying "I don't know Perl, but ...". Sorry, I sympathize with you, but our clients need Perl expertise.
Or this one (paraphrased):
The job posting said I need to love Perl, but I only use it when needed.
Or my favorite:
From: ...@hushmail.com Date: 12 Oct 2015 15:21:18 Subject: Re: [Perl Jobs] Perl Developer (telecommute) Are you offering a real job or will this just be waste of time?
Dear Mr. Hushmail: yes, it's actually two, possibly three, real jobs. Some of the work is very hard and requires expert developers. We have tons of responses to wade through and at least half of them are deeply serious responses, with strong CVs, we simply don't have the time or inclination to deal to such an aggressive email. So the response was:
Hello, Considering your communication skill, I do believe it will be a waste of our time. Best Regards, ...
To which they replied (censored by me, not by them):
WOW! Very professional! Yeah. Kinda figured this was a scam just by the wording. OH! ...and since you have gone there. Please do accept my most heart felt, and sincerest feelings of "go **** yourself!"
They're now on our blacklist. They're not the first and they won't be the last.
As an aside, the next time you meet a recruiter who's even halfway decent at their job, thank them. This is what they have to put up with all the time.