Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^2: How to measure Perl skills?

by Callum (Chaplain)
on Mar 23, 2004 at 12:22 UTC ( [id://338965]=note: print w/replies, xml ) Need Help??


in reply to Re: How to measure Perl skills?
in thread How to measure Perl skills?

I'd certainly concur with Jacques -- you need to ensure that your employers are aware that theoretical perl skills may not map well onto practical perl usefullness.

You will only be able to get optimum benefit from a given person if you have optimum work processes; if your processes suck, and/or the person in question isn't able to work with them, then it dosn't matter how good they are -- you won't realise the full benefit of their skills.

Unless the role specifically needs a savant, you're probably better off with someone who is technically adequate (say, good C and shell, but no perl experience) and excellent on the process/interpersonal side (organised, thorough, quick learner, teamplayer, etc), than with someone who has the technical skills of Merlyn, but the personality of Norman Bates.

Take care not to focus solely on hiring the people who have the particular skills and knowledges that you currently need, be aware of the people who have the talents that you will always need -- the ability to learn quickly, work well with others, be thorough, disciplined and organised -- these are the people who will always have, or be able to quickly develop, the skills you currently need.

That said, there remains obvious and definate merit in technical testing, personally I favour the "what does this code do" problems to the "write code to do this" ones, likewise I would advocate generalised, pseudo-code ones to language specific tests. Any tests should be designed and evaluated by the people most familiar with the specific job that the candidate is being considered for.

Replies are listed 'Best First'.
Re: Re^2: How to measure Perl skills?
by optimist (Beadle) on Mar 23, 2004 at 17:56 UTC
    These are all good points, thanks. If it were up to me, I wouldn't bother with a written test, but instead would be comfortable with a whiteboard-based discussion, as various people have suggested. Unfortunately, I am but a grunt, and the CTO wants to give a test. Thus: we'll give a test.

    And yes, all the skills you mention (learning, working with others, thorough, disciplined, etc) are indeed very important. The test is by no means the only (or even the hightest weighted) part of our evaluation process. There are other parts of the interview and screening that try to focus on that.

    A couple weeks ago, we brought in a candidate who looked good on paper, sounded fine on the phone, and sent in a very impressive-looking code sample. But when he got here, he couldn't explain the code he'd sent very well, he was pretty bad at "what does this code do", and he made some of the people he met feel unconfortable. So no test was required, since we wouldn't have hired him regardless of how well he performed.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (6)
As of 2024-03-29 13:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found