Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Developer::Perl::Find

by gryphon (Abbot)
on May 27, 2005 at 23:17 UTC ( #461258=perlmeditation: print w/ replies, xml ) Need Help??

Greetings fellow monks,

Im a development manager at Whitepages in downtown Seattle. Were a 100% Perl shop, really pushing the envelope, doing some amazing things. Weve got a great team of really smart Perl developers and architects, but were under-staffed. Weve posted job descriptions on perl.jobs.org, Craigs List, and Monster. Over the past month, Ive spent a majority of my life searching, screening, and interviewing candidates, but weve 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, dont understand hashes, or cant spell sort or map.

Some candidates over-estimate their abilities
Weve seen a lot of resumes and cover letters that claim the moon and sky, but unlike a lot of other places Ive worked, we require a Perl skills test of each candidate during the interview process. There have been several instances when weve 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 were broadcasting our job offers frequently, I dont think were doing a good job of it. Our job titles and descriptions are lame and uncompelling, IMHO. (Were working on rewriting these now.) But ultimately, we dont know of any place else to advertise our open jobs. Weve tried local Perl users groups and other places, but weve not been able to get top people.

Ultimately, were starting to get the feeling that most qualified Perl developers in the greater Seattle area are already happily employed. Either that, or were 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 youve 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. Were getting very few responses to our job postings. Any suggestions? Thanks.

gryphon
Whitepages.com
code('Perl') || die;

Comment on Developer::Perl::Find
Re: Developer::Perl::Find
by etcshadow (Priest) on May 27, 2005 at 23:40 UTC
    Well, first of all, I'm in a remarkably similar situation (in Boston, not Seattle, but still). I won't mention my company's name in this context, because that may be seen by some as bordering upon using PM for a job postings board... and I wouldn't want to come accross that way. (However, if there were some easy way for me to translate my PM presence into some bonus to my recruiting pipeline, I would certainly enjoy it).

    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:

    • Getting them, and getting them sooner rather than later, actually has an economic value to you... something worth shelling out actual money for.
    • Even worse: hiring the people you need is consuming your time, right now... and your time is the time you need more of! (via the hiring of more people like you). If you could pay cash to get more of your time, you would... because that's exactly why you're trying to hire people.
    It's easy to see recruiters as just a pain in the butt. They're salespeople. They have all the typical annoyances of dealing with salespeople. There's the added dimension that they are, in fact, selling people (which is a little disturbing, if you think about it). What's worse, they sort of don't seem to be doing much of anything for the money you have to pay them! All they're doing is forwarding you resumes that you could find for yourself off of Monster, right?

    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

    ------------ :Wq Not an editor command: Wq
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

      Whoa. I was just reading that article. Then I came over here, saw this node. Then your response pointing to the article... weird. Then again, it's been a weird day.
Re: Developer::Perl::Find
by kvale (Monsignor) on May 28, 2005 at 00:01 UTC
    I think part of the problem is this description from a recent posting of yours for "Senior PERL Developer & Conusmer Services Lead":
    We are seeking an experienced Internet developer to lead the developme +nt of our high-traffic Web properties including WhitePages.com, WhitePages.ca, and PhoneNumber.com, as well as hundreds of affiliate s +ites. 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.
    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

      ...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 :-)

        I don't know, considering some peoples habits sty could be an apt description.

        --
        We're looking for people in ATL

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' }

      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
      Be your own disciple, fan the sparks of will
      For all of us waiting, your kingdom will come

        Why do you NEED emphasis, it's a JOB posting, its not as IF you don't know you're SEARCHING for a PERL job now IS it? HMMMMM?
        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
        Be sure to read my standard disclaimer if this is a reply.

        Howdy!

        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
        Wise sages, I compel your wisdom - I have questions and am confused... If I may - for reference, disply the portion of perlfaq1 in discussion:
          What's the difference between "perl" and "Perl"?

          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.
        Well, if this was the bible or some other religious text, we could read it as such - wait a second, I'm in a monistrary... err... I take that back.

        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:
          Perl not only stands for the Practical Extraction and Report Language, but it also stands for the Pathologically Eclectic Rubbish Lister.
        What is this? The Larry writes of not one acronym, but of two! Even the main perl manpage mentions this latter acronym (dare I say). I wonder what then is an acronym if it isnt a word that stands for a phrase with words the first letters of which make up the acronymic word. In fact, the Merriam-Webster dictionary defines it as such: word (as NATO, radar, or snafu) formed from the initial letter or letters of each of the successive parts or major parts of a compound term. Yet, the perlfaq1 explicitly explains that Perl is not an acronym - is the manpage trying to express an (perhaps the) innate contradiction of our universe - is it covertly trying to say that two opposing sides can both be correct, or wrong, is it opposing moral dichotomy - is morality multidimensional? Please, saints, monks, shed some light on this troubling issue. Perhaps it is expressing that the whole essence of community counterindicates dogma, especially as it relates to the Perl community, for which the major founding principle of timtowtdi guides this premise.

        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!

        --
        Impossible! The Remonster can only be killed by stabbing him in the heart with the ancient bone saber of Zumakalis!

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.

Re: Developer::Perl::Find
by zentara (Archbishop) on May 28, 2005 at 11:44 UTC
    I've been hearing on the news lately that the new brilliant scheme is to park decommissioned cruise ships just outside the international boundary( 3 miles), and hire people from around the world, who won't need green cards.

    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
Re: Developer::Perl::Find
by perrin (Chancellor) on May 28, 2005 at 15:05 UTC
    Ultimately, were starting to get the feeling that most qualified Perl developers in the greater Seattle area are already happily employed

    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.

      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
      Whitepages.com
      code('Perl') || die;

        Frankly, I doubt I could code my way out of a paper bag without access to the Perl docs, books, mailing lists, etc. that I normally use to attack problems. It's like taking an experienced magazine editor and saying "if you're such a great editor, write me a poem." Creating an artificial environment that's completely unlike the one I expect a candidate to work in just doesn't seem very useful to me.

        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.).

Re: Developer::Perl::Find
by Anonymous Monk on May 28, 2005 at 19:58 UTC
    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.

    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.

      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
Re: Developer::Perl::Find
by astroboy (Chaplain) on May 28, 2005 at 23:03 UTC
    from your post:
    Were a 100% Perl shop, really pushing the envelope, doing some amazing things. Weve got a great team of really smart Perl developers and architects, but were 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
Re: Developer::Perl::Find
by blahblahblah (Priest) on May 29, 2005 at 03:30 UTC
    I agree with pretty much all of what's been said so far, especially the idea that you need to make your ad more enticing.

    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
    I just checked the Big Monk Map and found that I'm in a very Perl-dense area (NJ), so maybe that's why we had a better jobs.perl.org experience. Maybe as a last resort you could send a rescue party out into the Pacific for Anomynous Monk or SpongeBob?

Re: Developer::Perl::Find
by tinita (Parson) on May 29, 2005 at 13:45 UTC
    we find it difficult, too, to find good perl developers in our area (berlin, germany). many overestimate their abilities, or they aren't team players.
    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.
Re: Developer::Perl::Find
by wazoox (Prior) on May 29, 2005 at 18:09 UTC
    OK, I can't help but talk about my experience too :) I agree fully with the "find a developer" trend. One of our summer interns didn't know anything about Perl 2 months ago, now he's using CPAN, he does OOP happily... A good developer will learn quickly Perl if there's someone to hold his hand for the first steps :)
    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!
Support your local Perl user groups
by jarich (Curate) on May 30, 2005 at 05:29 UTC
    Weve tried local Perl users groups and other places, but weve 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

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:

    1. Qualified: the people who have the skills you need and would want to work for you
    2. Unqualified: honest folk who either don't have the skills or don't want to work for you
    3. Deluded: people who think they can do the job despite the fact their computing experience consists of knowing somebody whose cousin owns a Playstation
    4. Liars: people who know they can't do the job and will lie to get it anyway

    So you want to:

    1. convince that first group that you have a wonderful job working for a competent company that's just right for them
    2. convince the others that they shouldn't waste everybody's time

    Two big problems:

    1. Almost by definition the Qualified are in work. Why wouldn't they be? So you need to make sure that you're going to make something attractive enough for people to consider jumping ship for.
    2. It's a complete bugger to get rid of the Liars and the Deluded because... well... they're liars and deluded :-)

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

    1. Lie. Nothing attracts that ideal recruit more than showing up at the job interview to discover that the salary is ten grand less than was advertised and that they can't telecommute like the agent told them.
    2. Bad spelling and grammar. Would you trust a company that cannot even check the spelling on their job adverts?
    3. Bad technical terms. The Qualified are not going to apply for a position as a "PERL programmer with Central Gate Interface experience" :-)
    4. No company info. Put your company name and URL on the advert. Good candidates will want to google you and find out whether they want to work for you. Let them. That way you'll let the Unqualified filter themselves out. Does googling your company results in stuff that would make the brave run away screaming? If so fix that first :-)
    5. Bad job title. Treat the job title like the subject line of an e-mail. It should be informative. It should be an abstract of the job. It should not be "Programmer" or, even worse, "GREAT POSITION IN TOP COMPANY!!!". Something like "Perl/mod_perl e-commerce developer". The Qualified are only skimming the job ads to keep a weather eye on what's happening. Don't give them an excuse to skip over the ad. Being specific also makes it harder for the deluded to remain so.
    6. No salary. At the very least quote a range. The Qualified are probably working and need to know whether it's worth their while to jump ship. It's also a good indicator of what kind of role it is. This will let the Unqualified filter themselves out and reduce your pile of useless CVs.
    7. Over general terms. Don't say "Perl programmer" say "Perl programmer. Must have experience writing OO modules and unit/acceptance testing of web based applications". Make it easy for the Unqualified to filter themselves out. Make it harder for the Deluded to delude themselves.
    8. Not knowing the difference between a job requirement and "it would be nice if...". Make the difference obvious in your advert. Far too many ads are a shopping list of every possible thing that might be vaguely useful. Are you really going to reject the perfect candidate because they only have four rather than five years experience? Are the Qualified going to spend the time figuring out what the job actually involves? Nope - they have lives.
    9. Hiding the job requirements. By the time they've got to the third paragraph of market speak about how wonderful the company is the Qualified's eyes are glazing over. Job requirements should be front and centre.
    10. Not saying what the job is. For god's sake mention what they'll be developing. It's one of the things that attract the Qualified. At the very least mention the domain.
    11. Not mentioning the work environment. If you have a small agile development team using TDD then you don't want somebody who uses RUP in a group of forty, or somebody who will only telecommute. So let them filter themselves out by saying so.
    12. No location. People want to know where they'll be working.

    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.

      ++ 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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://461258]
Approved by kvale
Front-paged by ChemBoy
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (7)
As of 2014-07-28 10:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (195 votes), past polls