Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: How to measure Perl skills?

by jacques (Priest)
on Mar 22, 2004 at 23:24 UTC ( #338827=note: print w/ replies, xml ) Need Help??


in reply to How to measure Perl skills?

Don't rely on the test too much. That would be a mistake. In the rush to hire, most employers never take the time to figure out if a candidate would be a good team player.


Comment on Re: How to measure Perl skills?
Re^2: How to measure Perl skills?
by Callum (Chaplain) on Mar 23, 2004 at 12:22 UTC
    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.

      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
Node Status?
node history
Node Type: note [id://338827]
help
Chatterbox?
and the web crawler heard nothing...

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

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (213 votes), past polls