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).
Our Company
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.
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
From an applicants perspective (not that I applied for this role), it's very frustrating to see jobs posted with no indication of pay range.
Words like "Competitive" are also very subjective; competitive for where? India? According to a tight fisted CFO? For the city?
It also gives the impression that what the advertiser really wants to say "as little as possible".
There are a lot of jobs that go by on jobs.perl.org and other sites. If you put effort in to every one, jumping through all the required hoops and making sure your emails looks like you are really interested, that amounts to a lot of time. If at the end of it you find that most of them are offering a fraction of what you expect (or are currently on), you're left feeling pretty fed up - as you are dealing with the divas.
As you say, they may only be completing one test for you, and that you have lots of tests to mark... but it's unlikely that you are the only job that they are applying for. They also have limited time, and need to focus their efforts on the jobs that look like more promising/genuine offers.
Your blacklisted friend may well have come hot of a week long interview/test process to be offered peanuts at the end of it. It doesn't really excuse the behaviour, but does explain it.
When pay rates are clearly listed it lets you know what ball park the company is in, and how realistic their expectations are. It gives transparency and creates confidence. I suspect this also cuts out a lot of the divas that you refer to.
You may of course be assuming that your good reputation in the community should be enough to give people confidence. However, that would be limiting yourself to developers who are relatively active in the community... Maybe that's part of your screening process.
Hope some feedback from the other side helps!
Hi Lyle,
I understand your point.
However, at the end of the day people needs to have basic communication skills.
I believe than starting by saying hello is not too much asking. I also believe if pay range is a concern, you can easily send an email and ask about that. But again, please start by "hello" and ask nicely. You will usually get an answer, as for us, also, it's an issue. There is no point going through the all recruiting process to realise at the end that you cannot meet the candidate expectation.
You ask us to understand the frustration of candidates that had been going through 'hot of a week long interview/test process to be offered peanuts at the end of it."
I can understand, but I would like to return the question to you. if under stress this person cannot manage basic communication skill are you sure you want to work with him? Are you sure that you want to work with someone who considers himself too good to work on some part of the project and leave everyone to deal with what he considers beneath him? Are you sure you want to work with someone who considers that he is so good that he does not need to work as much as everyone else?
I do not. And I do not want my teams to have to deal with that. I want them to be as happy and relax as they can. I want to be able to support them as much as I can. I do not want to extinguish a fire because of one person.
Therefore, I am sorry, with no basic communication skills the answer will be no and you know why? Because I care about the people who are working with me.
Hi,
I saw your posting for a Perl programming position on the Perl jobs site.
My salary requirements are in the 50K-60K range. Can you meet that requirement? Just trying to save us both time and effort up front.
Respectfully,
The guyIs that so hard??!?!
I found your post really interesting and it's heartening to hear that there are loads of Perl devs who, like my old friends, have the skills to match their personalities. It's shocking to read that there are so many "divas" still around. I know the type—they're the ones who think that they're entitled to make people's lives difficult, even when applying for a job, where they should really be on their best behavior.
This underlines how much Perl feels (to me, at least) generationally embedded in the bad old days of what I like to call "Usenet culture". I know we've been talking about this as a community for years now—and I do wonder what it will take to dislodge it. Part of the traction other programming language communities like Ruby and Python have is that we don't have to write posts like this—we have successfully made being nice part of the culture. I wish that for Perl, too, but these days I'm hardly part of the Perl community.
As an experienced Perl programmer, I know the name Ovid / Curtis Poe. Based on his contributions to the Perl community, I must believe he will respect capable Perl programmers, and offer an appropriate salary.
On the other hand, it IS nice to have a feeling for what range you are competing.
Tom
We also have a programming challenge that helps with a no divas policy. I had one candidate who was very impressed with his solution, and asked if we had seen a faster one before. His solution was actually fairly middling at about 60 seconds, so I told him my gold-standard solution ran in about 18 seconds. His response was "That one must be cheating..." I don't even know how a program that solved the problem could "cheat," but we didn't hire him.
These things are important. If they behave that way when trying to sell themselves to you, how are they going to behave with a client?
In the old days when I was going to interviews and taking tests I remember I used to be able to find out how I had done, or where I had gone wrong, or what I had done well. These days all I can get is, "Thanks, but don't call us, we'll call you."
In my opinion the companies these days are chicken. They are afraid to give an applicant the slightest thing they might get sore at. Is it because of the litigious culture we live in? Is it just prudent to avoid hassles but keeping mum? I don't believe it, strongly. There have got to be ways to protect your time and money from people who feel unfairly treated and still be just civil to every applicant.
I think the application and interviewing process is a two way interaction. There aught to be give and take from both sides. I have taken tests and known I've done poorly, but some explanation of where or what to look at in order to improve salves the wound. I've had interviews that seemed to go well, where they've asked to keep the code samples I brought along and not been called back. Okay, not every company wants me, I can take it, but tell me why?
It looks like Ovid is not chicken and that he agrees with me that if I take his test he can at least answer a question or two of mine. So, hooray for him.