Greetings fellow monks,
I’m a development manager at Whitepages in downtown Seattle. We’re a 100% Perl shop, really pushing the envelope, doing some amazing things. We’ve got a great team of really smart Perl developers and architects, but we’re under-staffed. We’ve posted job descriptions on perl.jobs.org, Craig’s List, and Monster. Over the past month, I’ve spent a majority of my life searching, screening, and interviewing candidates, but we’ve only managed to fill a couple positions. There are several reasons for this:
Some candidates are woefully under-qualified
Granted, our hiring bar is purposefully set very high, but we get several candidates who barely know references, don’t understand hashes, or can’t spell sort or map.
Some candidates over-estimate their abilities
We’ve seen a lot of resumes and cover letters that claim the moon and sky, but unlike a lot of other places I’ve worked, we require a Perl skills test of each candidate during the interview process. There have been several instances when we’ve seen candidates we expected (based on their resumes and phone screens) to be top-level people crash and burn.
Our inability to engage a lot of candidates
Although we’re broadcasting our job offers frequently, I don’t think we’re doing a good job of it. Our job titles and descriptions are lame and uncompelling, IMHO. (We’re working on rewriting these now.) But ultimately, we don’t know of any place else to advertise our open jobs. We’ve tried local Perl users groups and other places, but we’ve not been able to get top people.
Ultimately, we’re starting to get the feeling that most qualified Perl developers in the greater Seattle area are already happily employed. Either that, or we’re just doing a really poor job of evangelizing our open positions. (We don't advertize the salary ranges in our posts, but they're quite good.)
What sort of advice do you folks have about hiring? Any tricks you’ve used to find and recruit good Perl developers? We phone screen candidates, then we have a Perl skills test where we stick the candidate in a room with a locked-down laptop and a browser-based test. The in-person interviews are after the Perl test. The problem is just with finding new candidates. We’re getting very few responses to our job postings. Any suggestions? Thanks.
gryphon
Whitepages.com
code('Perl') || die;
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Developer::Perl::Find
by adrianh (Chancellor) on May 30, 2005 at 12:51 UTC | |
My usual rant on recruitment goes something like this. You're dealing with four groups of people: So you want to: Two big problems: The good news is that the Unqualified are happy to exclude themselves if they're given enough info. They don't want to waste their own time applying to stuff they they know they're not going to get. So - how do you find somebody decent? Best way is personal recommendation. Network away and see if anybody you know and trust knows somebody who would be interested. Assuming you have vaguely sane friends this is almost guaranteed to exclude the Deluded and the Liars. Huzzah. Second best way is to use a good recruiter. Unfortunately, in my experience anyway, good agents are rarer than gold dust in the IT industry. Unless you have a personal recommendation from somebody I'd steer clear. The absolutely worst way to find somebody is a job advert - but sometimes we have no choice ;-) So - how do you know if you have a decent job advert? You know the sort of person you're looking for. Pretend you're that person sitting in a fairly comfortable job, with a reasonable salary, but feeling slightly bored with your current work. Remember you know nothing at all about your company and the work you do. Read your job advert. Do you want to apply? If not you may want to consider my Patient Pending list of how not to write a job advert :-) Remember - you want the best person for the job, not the most desperate. The best people are going to be comfortable and happy to skip things. The desperate are going to read everything. So, get the attractive stuff that will capture the best up front where they'll read it. | [reply] |
by Madams (Pilgrim) on Jun 06, 2005 at 00:22 UTC | |
++ on your node. When I read the OP's job wanted as posted by kvale my first thoughts were: Is this an ad or a job listing? It mentions NOTHING valuable for determining that the job on offer is worth MY time to even look further. It is all "Marketing Monkey Hooey". If a job offer reads like a TV ad, it is (IMNHO) obvious that the people I would work with/for directly had/have zero input in the hiring process... And I should think about jumping to that ship from this one? Every job listing should have zero buzz words and a good amount of hard data. No, you don't have to give out "trade secrets", but you do need to list real skill sets that you require, and those sets you will be willing to "bring up to speed". "All too often people confuse their being able to think with their actually having done so. A more pernicious mistake does not exist." --Moraven Tollo in Michael A. Stackpole's A Secret Atlas | [reply] |
Re: Developer::Perl::Find
by etcshadow (Priest) on May 27, 2005 at 23:40 UTC | |
Anyway, one thing that I would recommend is that you possibly loosen up on the "must know perl" angle. I've found that if someone is the "right kind" of person, then learning perl is not the big issue. The hard part is finding the right people. These are people who are really (and I mean really) smart, involved, passionate, and willing to do more than just program.... people who actually want to understand the problem domain, and not just be told what to do, but carve their own path through the wilderness. Some of the best people on our team did not know perl when they started (of course many of them did, as well). Another piece of advice is: don't be afraid to utilize recruiters. If you really need to increase your staff, then: The truth is that a good recruiter is actually providing a value-added service to you. Sure, all (well, most) of those resumes are out there for you to find, but by them culling through them and bringing you the ones that you want to see, they're saving you the time of doing that searching... and your time is prescious (see above). Anyway, good luck! And if you find anyone who's good, but lives in Boston, please let me know! :-D
| [reply] [d/l] |
Re: Developer::Perl::Find
by Juerd (Abbot) on May 28, 2005 at 08:24 UTC | |
The least you can do is write the name of Perl correctly (with lowercase e, r and l). You may have brillant Perl programmers working for you, but have you even let them proofread the job ads? Many of the "required" skills I see in this ad can be acquired in a matter of days, sometimes hours. For example, someone may not have any experience using CVS, but if they're a programmer, they better be smart enough to learn to use it in less than an hour. And my pet peeve, "5+ years of experience". As if a number of years says anything. We see, even on this very site, that some people learn the language and the internals of Perl in two years, while others after 5 years still have to find their way to CPAN, and have no idea that @_ contains aliases. That doesn't mean they *can't* understand it, but it does mean they haven't needed to figure it out yet. I have 7 years of Linux experience, but I regularly learn things from people who have used it less than I have. And I myself am sometimes helping out the people who originally taught me how to use Linux. Everyone has their own interests, and a number of years says absolutely nothing about your skills. This ad really is boring :) If it said just "Perl expert wanted", with a short explanation of what you consider an expert, you'd probably get the same people to reply, but with a lot less effort from your side. And perhaps it would even get more response from the real experts. "available, responsive, scalable, secure, up-to-date, and feature-rich." - This really sets your company apart from all those companies who advertise with unavailable, unresponsive, unscalable, insecure, out-of-date sites that lack important features. All of these, I think, should be things that any good developer considers obvious and natural. In general, perhaps you should communicate with your current employees more about job advertisements. You should know how they think, what they would like to read, because the people you're looking for are just like the people you already hired. That is, if you really have the best working for you. Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' } | [reply] |
by thor (Priest) on May 28, 2005 at 12:05 UTC | |
The least you can do is write the name of Perl correctly (with lowercase e, r and l). You may have brillant Perl programmers working for you, but have you even let them proofread the job ads?Why is this such a huge deal for people? I doubt that java people get riled up when people call it JAVA. Putting a word in all caps needn't imply an acronym, it can be there just for emphasis... thor
Feel the white light, the light within | [reply] |
by merlyn (Sage) on May 28, 2005 at 12:58 UTC | |
Why is this such a huge deal for people? I doubt that java people get riled up when people call it JAVA. Putting a word in all caps needn't imply an acronym, it can be there just for emphasis...Because it's a clue indicator. If you spell it as "PERL", you're not plugged in to the community. Consider it a secret handshake. In particular, it also means they haven't read perlfaq1, and probably don't even know the FAQ exists, which probably means they don't know all (or even some of) the resources available in the Perl community. -- Randal L. Schwartz, Perl hacker
| [reply] |
by Juerd (Abbot) on May 28, 2005 at 17:33 UTC | |
by thor (Priest) on May 28, 2005 at 21:28 UTC | |
by poqui (Deacon) on Mar 13, 2007 at 18:32 UTC | |
by belg4mit (Prior) on Mar 13, 2007 at 18:51 UTC | |
| |
by herveus (Prior) on May 31, 2005 at 18:15 UTC | |
Doing it once can be chalked up to simple ignorance -- a readily treatable condition. In part, it a matter of respect -- of taking it seriously. People who refuse to respect the convention convey the message that they don't care or worse. People who get all exercised about being called on it elevate themselves to the category of stupid -- an untreatable condition. I note that the author of the original post didn't get exercised about being called on this point. Clearly, he is genuinely trying to take in such hints and clues as are being proffered here to make his recruiting problem lesser. As an aside: I don't know if Sun has defined exactly how java *should* be capitalized. I do know that Larry has done exactly that for Perl.
yours, Michael | [reply] |
by Adrade (Pilgrim) on May 31, 2005 at 23:56 UTC | |
One bit. Oh, you weren't talking ASCII? :-) Larry now uses "Perl" to signify the language proper and "perl" the implementation of it, i.e. the current interpreter. Hence Tom's quip that "Nothing but perl can parse Perl." You may or may not choose to follow this usage. For example, parallelism means "awk and perl" and "Python and Perl" look OK, while "awk and Perl" and "Python and perl" do not. But never write "PERL", because perl is not an acronym, apocryphal folklore and post-facto expansions notwithstanding. Restart: Ok, my read of the Perl Bible, the book of perlfaq1, is as such... given that the text distinguishes between the use of Perl and perl, we can assume that they are divided concepts, each holding separate meanings, 'Perl' attaching itself to the meaning { the language as an entity or conceptually } and 'perl' to the meaning { the interpreter of Perl } (the things in brackets representing ideas - and that ideas are vague and nebulous, vague and nebulous ones). Despite allowing an individual to freely choose personal word usage (You may or may not choose to follow this usage.), the text gives the instruction to never use the term 'PERL', but appends an important mention: "apocryphal folklore and post-facto expansions notwithstanding", minimally giving recognition to the existence of those two things. As metaphors, parables, and allusions abound in religious texts, could it be perhaps that this may imply that at one time the letters p, e, r, and l may have had been bundled together as acronymic representation. One, of course, cannot help but notice that on man pages from the first version until now, the name has been given as perl - Practical Extraction and Report Language, but of course, as PERL can be found nowhere in the texts, we cannot assume anything other than coincidence - attaching meaning that isn't there could be subverting these precious words. But it still mentions those things that could compel a person to PERL, assumptions made after the fact and folklore that it calls apocryphal – could it be that it wants its followers to adhere to a standard in contradiction to something that may have existed long ago (perhaps in the time of Abraham - ie., what is any type of folklore anyway, and what does it take for a person or thing to call it apocryphal). Although post-facto expansions would include ideological expansions of written text, it would not the written text itself, should something surface. This part of the Perl documentation may not write of Perl as an acronym, but I would like to cite from the book of Linux Magazine, October 1999, wherein The Larry writes:
Monks, oh wise sages of our era, enlighten! Best, -Adam P.S. This is facetious - nobody now get all explosive. As The Larry says in the Linux Mag article: Anyone who can't laugh at himself is not taking life seriously enough. - Perfect! -- | [reply] [d/l] [select] |
by merlyn (Sage) on Jun 01, 2005 at 12:44 UTC | |
by Adrade (Pilgrim) on Jun 01, 2005 at 17:41 UTC | |
| |
by Anonymous Monk on May 28, 2005 at 12:12 UTC | |
| [reply] |
Re: Developer::Perl::Find
by kvale (Monsignor) on May 28, 2005 at 00:01 UTC | |
From this I gather that you want a web programmer who has some experience with scalable apps. But the rest sounds like generic boilerplate for a programming job with a traditional software development process. It is nice that there is a software development process, but it doesn't really describe what the job will be like. Will the programmer be more of an architect, or a code monkey? Are the projects to be executed by individuals or a large team? Will the apps be built around a predetermined MVC framework, or is this an ab initio project? What is amazing about the work you are all doing? I realize that companies don't want to show their hands to their competitiors, but the more concrete of a picture you can build for prospective employees, the more excited they will get about your job. Personally, I always look to jobs.perl.org first, because if folks advertise there, they probably are clued into Perl and its community. -Mark | [reply] [d/l] |
by runrig (Abbot) on May 28, 2005 at 00:10 UTC | |
...to ensure that your sties are ... There's your answer, a cubicle farm is bad enough, but no one wants to work in a pig pen :-) | [reply] |
by Fletch (Bishop) on May 28, 2005 at 22:45 UTC | |
I don't know, considering some peoples habits sty could be an apt description. -- | [reply] |
Re: Developer::Perl::Find
by perrin (Chancellor) on May 28, 2005 at 15:05 UTC | |
Of course they are. Good developers are in demand and are rarely out of work (at least once they have some experience on their resumes). You need to make a case in your job listings and interviews that your company is a better place to work than wherever they are now, so that people who are not entirely satisfied with their current job will come to you. I sympathize about not being able to find a lot of good people, but really, there are just not that many good people. I saw the same thing when I worked in a Java shop -- many candidates were really just getting by and hadn't given much thought to the pros and cons of the tools and techniques they were using. I personally prefer to see code samples rather than give a test. I want to see what style of code people will use when working on real problems, including how they leverage CPAN and how they document things. I find that the usual concern of "Is it really his code?" is not an issue if you spend 10 minutes asking the candidate to walk through his code and explain his choices. | [reply] |
by gryphon (Abbot) on May 28, 2005 at 21:06 UTC | |
Greetings fellow monks, First off, thanks for the helpful feedback. Yes, you guys are completely correct about the job postings. They were written by HR before I came on board, and we are in the process of rewriting them now. Hopefully this will help in our search. I also agree with the PERL vs Perl thing. It's one of many things that will change in the description. Regarding the Perl test, however, I have to disagree with the prevailing opinion that it's better to ask for samples. I realize any test is not going to give me a completely accurate idea of someone's skills, but it's going to give me a good idea of what they know, their minimum abilities. Certainly, anyone with a Perl interpreter and access to Google (and PerlMonks) will boost their Perl coding abilities. The reason I'm against code samples is that I've been burned by that in the past at previous companies. In a couple instances, candidates submitted beautiful samples. One was copied from a CPAN module by a different author. (Google saved us on that one.) The other was a few 100 lines the person had been working on for many moons. After hiring the candidate, we learned that while his code was usually OK, it took him an eternity to write it. With the exception of the scary magic merlyn writes in his columns, I think it's fairly easy to read good code and explain what it's doing; so asking a candidate to walk-through their samples with us won't be an obsticle. Besides, the samples won't be as subject comprehensive as a good test. A locked-down test proves conclusively whether the candidate knows how to code at a basic level. During the interviews following, we ask about architectural design and good coding practices to fill in the gaps the test leaves. However, ultimately our testing and interview process isn't the problem. We're just not able to attract a lot of qualified people in the front door. The job posts are certainly to blame for this, but I think also the market is very strongly a candidate's market. Once we get candidates in the door, they see how cool a place we have and want to stay; our problem is getting them in the door. DISCLAIMER: I mentioned this before, but just to be clear, we're getting many resumes submitted, but the vast majority of candidates are underqualified or ask if they can telecommute from some place not nearby. I love telecommuting, and I let my team do it frequently, but the problems we face are complex enough as to require people in the office more often than not. gryphon | [reply] |
by perrin (Chancellor) on May 28, 2005 at 22:27 UTC | |
I also don't agree that it's easy to walk-through and explain someone else's good code. Maybe you need to ask more interesting questions. "Why did you choose to do the POD with these headings?" "What was your approach to testing this method?" "Have you considered using some alternative module on CPAN?" I doubt a person who lied about their code sample would be able to demonstrate competent understanding of it to my satisfaction, especially when paired with questions about source control, project tracking, and involvement with the Perl community. Meanwhile, I save myself time by filtering out the candidates whose code samples don't demonstrate the skills to merit an interview. Regarding the problem you speak of with finding good people, it will always be a candidates' market for the best developers, because they are by definition in limited supply. You can hire people who are not as good, or you can provide something (e.g. higher pay, Google-esque perks, a worthy cause, the freedom to telecommute) that makes the best developers want to work for you rather than someone else. Of course you need to get the word out as well, and you can do this in a variety of ways (networking and sponsorship at Perl conferences, local PerlMongers events, participation on mailing lists, etc.). | [reply] |
by cbrandtbuffalo (Deacon) on May 30, 2005 at 13:55 UTC | |
Re: Developer::Perl::Find
by tlm (Prior) on May 27, 2005 at 23:53 UTC | |
Joel Spolsky offers some interesting thoughts on this question in Whaddaya Mean, You Can't Find Programmers?. This article was written in 2000, when programmers were considerably harder to find (and keep) than it is now. the lowliest monk | [reply] |
by Nkuvu (Priest) on May 28, 2005 at 00:12 UTC | |
| [reply] |
Re: Developer::Perl::Find
by astroboy (Chaplain) on May 28, 2005 at 23:03 UTC | |
We’re a 100% Perl shop, really pushing the envelope, doing some amazing things. We’ve got a great team of really smart Perl developers and architects, but we’re under-staffed.Wow, that sounds more dynamic than your ad! Imagine a top-flight Perl guru hoping to escape from the tedium of his/her current job, coming across your post instead of the dry, ho-hum of: You must be passionate about web applications, scalability, and the end-user experience. You will write technical specifications based on product requirements documents, and both oversee and participate in the implementation of those products. You will work closely with Product Management, Quality Assurance, and Operations, as well as the rest of the Product Development team, to ensure that your sties are available, responsive, scalable, secure, up-to-date, and feature-rich.The fact is, your ad states what you want out from a programmer, but not why they'd want to work for you. Fuel the Perl lust, baby | [reply] |
Support your local Perl user groups
by jarich (Curate) on May 30, 2005 at 05:29 UTC | |
We’ve tried local Perl users groups and other places, but we’ve not been able to get top people. Searching for job candidates is expensive. Finding ways to reach good Perl programmers can be hard. Getting the good Perl programmers to seriously consider leaving their current job to join your business might be easier than you think. How supportive is Whitepages of your local Perl user group? Are most of your developers encouraged to attend meetings? Does Whitepages allow developers time to prepare talks to give at meetings? Would the typical SPUG member know that Whitepages was an all Perl shop? Or does SPUG only ever hear from you when you want something? This message really applies to all Perl shops, not just Whitepages. Support your local Perl user group. Provide a meeting room if there isn't one, encourage your developers to get involved (provide a budget to help transport them there after work or pay for a round of drinks at the pub afterwards), sponsor a visiting Perl expert to give a talk occasionally. This has three big benefits to the business. First you become known as a company which cares about its employees' development. Secondly you become known as a company which cares about Perl. Finally you will help the Perl community in your local area grow, thus giving you access to more Perl programmers. If your workplace is as fun to work at as you suggest, your employees will spead the word. Then, whenever you're looking for employees you'll have a ready pool of people to invite. Recruitment will become a lot easier and cheaper, saving you money in the long run. Another possible payoff will be in a mix of employee satisfaction and personal development. If you encourage your employees to give presentations at the meetings, then they'll learn presentation and public speaking skills. If you encourage them to attend, they might learn about new modules, or different ways of doing things. There are still very experienced (but closeted away) Perl programmers out there who don't know about references. Instead of a hash of arrays, they build a hash of very long strings with separators. They might be otherwise good programmers, but they need to get out more, and find that Perl has moved on a little. Perl user groups help achieve this, and you can help your employees by encouraging them to get involved. Becoming a regular Perl Monger and a (varyingly regular) Perl Monk was the best thing I ever did for my understanding of Perl. Encourage your programmers to do the same. jarich | [reply] |
Re: Developer::Perl::Find
by tirwhan (Abbot) on May 28, 2005 at 09:58 UTC | |
If you're having trouble finding suitable programmers in your area, maybe you should consider hiring someone who telecommutes? That'd open up the national (or even global) job-market for you and it'd be harder to run out of suitable candidates. I realize there are downsides to telecommuting (for both the employee and employer), but given the obvious benefits, I'm constantly surprised at the low ratio of telecommute/onsite job offers. | [reply] |
Re: Developer::Perl::Find
by Anonymous Monk on May 28, 2005 at 19:58 UTC | |
Does your staff normally work on locked down laptops? IMHO, this is a good way to find candidates who are good at working on locked down laptops, and ones who are good at passing tests. Personally this would turn me off as a candidate. My creativity is one of my biggest assets. If I see a problem, and I know that I've seen the solution on Perl Monks, are you going to require that I have memorized the solution or allow me access to the resource? Currently this is akin to my current employment situation. My boss gives me assignments by saying "Solve this problem this way". That makes solving it much harder than if I had freedom to choose the best solution. But I guess that's why I end up spending 1/3 of my time fixing the tests he breaks. | [reply] |
by dimar (Curate) on May 28, 2005 at 20:05 UTC | |
Does your staff normally work on locked down laptops? IMHO, this is a good way to find candidates who are good at working on locked down laptops, and ones who are good at passing tests. Good point, although there is always some tension between "testing methodology" and "real-world relevance" in any scenario where it is (percieved as) necessary to 'weed out' losers from winners. One way to look at it: people implement tests for various reasons, sometimes the reason is "because that's the way we've always done it, and its worked well enough so far". Considering that history creates its own 'momentum' that might also be why a particular shop uses perl only, and why a particular boss might say "solve the problem this way" ... there is always more than one way to skin a cat, but being flexible might enable you to skin it in ways that won't freak out your boss, or require someone to totally redo their testing methodology.
=oQDlNWYsBHI5JXZ2VGIulGIlJXYgQkUPxEIlhGdgY2bgMXZ5VGIlhGV
| [reply] |
Re: Developer::Perl::Find
by blahblahblah (Priest) on May 29, 2005 at 03:30 UTC | |
Going in a different direction, I would suggest that if you can't find a qualified Perl developer, you widen your range and find any qualified developer. Perl is so easy to pick up, especially since your new employee will have a team full of coworkers to learn from. At my company (a very-close-to-100% Perl shop) every developer (except our most recent hire) learned Perl on the job, and did so very quickly. All of us knew Java and/or C before starting, and easily made the transition. The one exception at our company is our most recent hire, who we found on jobs.perl.org. The site worked out great for us. We did get a lot of throw-away responses (like people who wanted to telecommute cross-country, even though the ad explicitly said we didn't want that), but after weeding them out we were left with a few really good candidates to choose from. The guy we hired has turned out to be great, and because of him I can definitely understand your desire for Perl experience. But if you can find a quick learner with the right attitude and general programming knowledge, you'll be able to turn him/her into an knowledgeable Perl programmer in no time. -Joe
Update | [reply] |
Re: Developer::Perl::Find
by zentara (Archbishop) on May 28, 2005 at 11:44 UTC | |
Move the ship down to the Baja in the Winter, and up North for the Summers. What fringe benefits too. No drug, gambling, or prostitution laws on the high seas....it would be "geek heaven". I would sign on for a few months of that, and work for free. :-) I'm not really a human, but I play one on earth. flash japh | [reply] |
Re: Developer::Perl::Find
by wazoox (Prior) on May 29, 2005 at 18:09 UTC | |
And what about experience? Well, our interns are just students, but they can code quite efficiently. After all, a less experienced programmer is less payed too, therefore perhaps may you hire 2 young people eager to learn and have two very experienced Perl specialist 2 years from now! | [reply] |
Re: Developer::Perl::Find
by tinita (Parson) on May 29, 2005 at 13:45 UTC | |
i personally like small programming tests. of course the test must fit to the candidate's experience. i wouldn't say one has to know A, B and C to get hired. it depends on what one did before. a perl starter who doesn't know references might learn them quickly. an expert in OOP who doesn't know how to debug efficiently might not be the best candidate. also a trainig day might be a good idea. | [reply] |