Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re: A Perl aptitude test

by jonadab (Parson)
on May 03, 2003 at 04:54 UTC ( [id://255249]=note: print w/replies, xml ) Need Help??


in reply to A Perl aptitude test

Well, question 1 will help you weed out the C programmers who still think of expressions as statements. I don't think I'd hire anyone who says it prints "9". Question 2 is worthless; they're all going to regurgitate the stock answer whether they believe a word of it or not. And they're going to waste three minutes writing that answer. Question 3 is preposterously easy, but I suppose it's okay to have one of those. 4 is the best question you asked. There are enough differences that if they can't list at least three you know they don't understand scoping. (Though personally I'd turn it around and talk about the important similarity between them (that they both define scope statically at compile time).) 5 and 6 are just syntax (though 5 is pretty obscure syntax; if you use it in an actual program, you're very likely doing something in a highly non-Perlish way). OTOH, 5 and 6 take virtually no time to answer, so they don't lengthen your test that much. 7 could maybe be reworded and/or restructured, but it's fundamentally a pretty good question.

If I were (re)writing the thing, I'd pull question 2 and replace it with something with no stock "right answer" so you can get a better feel for their actual views. Maybe something about what their favoured debugging techniques are or what kinds of jobs they find Perl best suited for. I'd add one more question about something moderately advanced, like a question about map or closures. And I'd probably reword the text of 7 a bit, though the code part is probably fine as it stands.

But I've seen fairly decent Perl people getting 3,4,5,6 and 7 wrong.

You define "fairly decent" differently than I. This is an *easy* test. *None* of the questions are hard. 1 could be considered tricky, and 5 could be considered unnecessary (not something you often need to do, so maybe not something they've looked at recently), and 4 is something a lot of people never bother to understand (though they should). So missing one of those three, or *maybe* two of them, is understandable. And you figure anyone can pull a braindead moment on one question for no reason. But that would still be at *least* 4/7 correct. 2/7 on this test is positively abysmal.

Oh, and you ought to give full credit to anyone who answers 5 by saying "it sets off a red flag that tells me this section needs to be rewritten". I think maybe half of all uses of $#array occur in a construct like for ($i=0;$i<=$#array;$i++) and are usually implementing something there's a Perl builtin for (such as a sort).

If you want a question to quickly identify people who have used Perl for a decent assortment of tasks, ask them to list some modules that they have used that can be found on CPAN. Don't tell them how many to list, but give them room to list a couple of dozen if they can.


{my$c;$ x=sub{++$c}}map{$ \.=$_->()}map{my$a=$_->[1]; sub{$a++ }}sort{_($a->[0 ])<=>_( $b->[0])}map{my@x=(& $x( ),$ _) ;\ @x} split //, "rPcr t lhuJnhea eretk.as o";print;sub _{ord(shift)*($=-++$^H)%(42-ord("\r"))};

Replies are listed 'Best First'.
Re: Re: A Perl aptitude test
by Your Mother (Archbishop) on May 03, 2003 at 08:16 UTC
    Question 2 is worthless... considering how many Perl scripts that are out in the wild that use neither 'strict' nor 'warnings,' I think this is a fair question.

    Naming modules is a good idea, though. The rest of it I agree is not hard but pretty good. The print() tricked me because I'm so used to using parens with almost every other other function besides print that I forget it's a list operator. It's also tricky b/c coming first one psychologically expects it to be the easiest question.

      considering how many Perl scripts that are out in the wild that use neither 'strict' nor 'warnings,' I think this is a fair question.

      Oh, it's fair, I just question whether you're going to get honest answers.

      It's also tricky b/c coming first one psychologically expects it to be the easiest question.

      Hmmm... then maybe what it's testing is test-taking skills. (Mine are pretty good, but that's not what you probably want to test in most cases.) Would it be less "tricky" if it were pushed back to question 3 or 4? I still think it's an easy question. All you have to know is that "If it looks like a function call, Perl treats it like a function call" (i.e., when you call a function, parentheses after the name of the function define the extent of the arglist). That's pretty fundamental. I'd think you'd have a fairly hard time trying to actually program in Perl without understanding that. All sorts of things would get messed up if you thought foo(blah)+6 would pass (blah)+6 as an argument to foo. Ack. The confusion that would result from such a misunderstanding could be profound.


      {my$c;$ x=sub{++$c}}map{$ \.=$_->()}map{my$a=$_->[1]; sub{$a++ }}sort{_($a->[0 ])<=>_( $b->[0])}map{my@x=(& $x( ),$ _) ;\ @x} split //, "rPcr t lhuJnhea eretk.as o";print;sub _{ord(shift)*($=-++$^H)%(42-ord("\r"))};
Re: Re: A Perl aptitude test
by crenz (Priest) on May 03, 2003 at 08:37 UTC

    Question 2 is worthless; they're all going to regurgitate the stock answer whether they believe a word of it or not.

    Don't know. He's asking "why", not "would you use strict?". So it is not a yes/no question. A good candidate could elaborate on it quite nicely, as I mentioned in my previous post.

      An interesting variation on the theme might be to ask when they would consider not using strict.


      Examine what is said, not who speaks.
      1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
      2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
      3) Any sufficiently advanced technology is indistinguishable from magic.
      Arthur C. Clarke.

        Hmm... that's an interesting question. So when would you?

        In my extremely limited experience with Perl, I've only run into one place where I couldn't use strict; I had a module that was tracking multiple file locks using flock() and I was storing the various file handles in a hash. When I tried to close the files (and thus release flock()'s lock) I got an error about "using string substitution for symbolic table entries under strict" or some such thing. So I commented out the use strict; line and documented why, and forced that set of functions into its own module, never to be mingled with others.

        So, I suppose, implicit in this story is that, for now, I wouldn't not use strict; unless it was required.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2024-03-28 11:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found