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

Re^2: How to measure Perl skills?

by Callum (Chaplain)
on Mar 23, 2004 at 12:22 UTC ( #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?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://338965]
[marto]: yes
[Discipulus]: thanks i definetively must learn such stuff.. i must come out with a killing product and after i'll just do Perl elctronic and music.. ;=)
marto has a similar idea on the 'to do' list
[Discipulus]: 65-35 joint venture marto? ;=)
[choroba]: Fibonacci at 34!

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2017-10-17 10:01 GMT
Find Nodes?
    Voting Booth?
    My fridge is mostly full of:

    Results (225 votes). Check out past polls.