Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re^2: Developer::Perl::Find

by gryphon (Abbot)
on May 28, 2005 at 21:06 UTC ( #461403=note: print w/replies, xml ) Need Help??

in reply to Re: Developer::Perl::Find
in thread Developer::Perl::Find

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.

code('Perl') || die;

Replies are listed 'Best First'.
Re^3: Developer::Perl::Find
by perrin (Chancellor) on May 28, 2005 at 22:27 UTC
    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.).

      I agree with perrin on this one. I had to take a Perl coding test once and I was completely comfortable with all of the tasks. However, as I started working it seemed the test database wasn't working. So I started debugging the problem by writing some test scripts. They came back to check on me and I hadn't really progressed on the task at hand.

      Turns out the database was broken and they wanted to see if I would ask for help. Well, in my office I'm usually they guy to figure out these types of problems so I don't usually have someone else to ask.

      I guess my point is it's really hard to have a test that accurately measures everyone on all criteria.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://461403]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2020-12-01 15:40 GMT
Find Nodes?
    Voting Booth?
    How often do you use taint mode?

    Results (11 votes). Check out past polls.