Re: How to measure Perl skills?

[jonadab]

There are three things you really want to check for. You want to check that they understand context, references, and the CPAN. A good Perl coder really needs to understand these three things. There are other things that are useful (objects, closures, map and grep, certain specific modules, and so on), but these three things are really key, IMO. (Plus, you can only test so much in a screening, and if they've already learned this stuff they'll be able to pick up whatever other stuff you require.)

References are easy to test for. Hand them something like a sub that returns a hash reference wherein each value is an arrayref, and ask them to write code that calls the sub, takes what it returns, and does something with the value for a certain key. A simple example will do ...

sub newpoint {
  return [rand($maxx), rand($maxy)]
}
sub newcircle {
  return {
      center => newpoint(),
      radius => rand($maxradius),
  }
}

You might ask them to call newcircle twice and compare the results to determine which circle is centered closer to [0,0] or somesuch. If they have trouble with the dereferencing syntax, you know you have a problem. If they breeze through the thing, or even if they only breeze through the dereferencing and spend most of the time remembering from high school geometry class how to calculate the distance between two points, then they understand Perl's references well enough to pass.

Testing their knowledge of context is at least as important, if a bit trickier. You'll probably want a series of three or four questions. Don't warn them that the questions are about context, just ask, "What does this code do?", but construct the examples so that if they don't understand context they'll get it wrong. Approach it several different ways, evaluationg different things in different contexts. For example, maybe print <FILEHANDLE>, "\n"; for one question, for another something like print "Some stuff " . @foo . " more stuff.\n" and so on.

For CPAN, give them a web browser and say something along the lines of, "Find me a Perl module for working with MARC records", or something equally obscure that you've checked in advance does exist on the CPAN but is not a module they're likely to have used in the past. If they go straight to search.cpan.org, find it in notime flat, and start reading the documentation on how to use it, you have a winner. If they do a Google search and end up on marcpm.sourceforge.net (or wherever), give them a shell prompt and say, "okay, install it", and you can probably pass them if they fire up CPAN at that point.

And yes, the ability to read your site's existing bad Perl code is at least as important as being able to develop new code well, so don't do away with that part of your test.

Alternately, if you can detain them for several hours, you could combine the two parts of the test by handing them a few hundred lines of bad code and saying, "refactor this". But I prefer the other approach.