Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re: How to measure Perl skills?

by graff (Chancellor)
on Mar 23, 2004 at 05:01 UTC ( #338898=note: print w/replies, xml ) Need Help??

in reply to How to measure Perl skills?

Here's an idea I've thought about for awhile, but never tried -- in fact I never tried to set it up -- but from your description, you might have the raw materials for it (if it seems worthwhile):

Present a bit of the old goofy code that is (mostly) self-contained -- maybe add comments about global variables to explain what they contain, if necessary. Then also present the equivalent chunk of logic as written in your current "non-icky" style. It might be instructive if the old version contains a flaw of some sort that is fixed in the new version.

The task is to determine whether the two pieces of code really do the same thing, and in the process of discussing the snippets, get a feel for which of the styles seems more familiar to the applicant -- and which one is easier for him/her to understand (might not be the same as the more familiar one).

As others have said, the key is still in the discussion more than in the "factual" answers. If the newer, better style confuses an applicant, but they really do get the older style, this might not be a bad thing, especially if they show signs of catching on to the newer one. You just have to figure out how much training you're willing to invest in "re-education", given that they have a leg up on the older coding style.

On the other hand, if the newer code is a walk in the park for them, but they can't work out how the old code relates to it, they might not be as valuable when it comes to doing maintenance and retooling on the old code base, and now you have to figure out how much time you want to invest in just ditching the old code and re-creating an app from first principles (not quite "from scratch", but almost).

Replies are listed 'Best First'.
Re: Re: How to measure Perl skills?
by optimist (Beadle) on Mar 27, 2004 at 00:27 UTC
    This is an appealing idea, although I haven't done it, or seen it done anywhere either. The discussion would seem to lend itself nicely to finding out how the applicant thinks. Your analysis of the difference between understanding the two forms seems spot on. However....
    As others have said, the key is still in the discussion more than in the "factual" answers.

    I don't actually completely agree with this. The CTO's point in requiring the test in the first place is at least partly to find out whether the candidate can not only "solve the problem", but can also get their solution to work. By way of illustration, when I took the original test here, it took me 10-15 minutes to basically understand the code I was given, another 5 minutes or less to "get" what I needed to do, and then over an hour to actually get my changes to run! (A pathetic time, I admit, but in my defense I hadn't programmed in nearly a year at that point, and hadn't written any Perl in nearly 3. I'm much faster now.)

    So I'm thinking about a variation of this idea in which the "new style" is only partly written, and the test is simply to finish it. This could have the added benefit (I think its a benefit) of demonstrating how well the applicant can grok and match the style of existing code.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://338898]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2017-10-21 20:04 GMT
Find Nodes?
    Voting Booth?
    My fridge is mostly full of:

    Results (270 votes). Check out past polls.