Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
Pathologically Eclectic Rubbish Lister

A Perl aptitude test

by Jonathan (Curate)
on May 02, 2003 at 15:19 UTC ( #255028=perlmeditation: print w/ replies, xml ) Need Help??

Two years ago I wrote a short Perl test for perspective employees of the company I work for...
1. What does following statement do? print (2 * 3) + 3; 2. Why is the ‘use strict;’ statement useful? 3. Write a regular expression that removes trailing white space fro +m a string 4. What is the difference between a lexical variable and a package +variable? 5. What does the following statement do? $var = $#array; 6. What does the ‘<=>’ operator do? 7. Given the following data structure. How would you access the value ‘c’ in the scalar $a? $a = [ ‘a’, ‘b’, [ ‘c’, ‘d’ ], ‘e’ ];
The test is part of a larger exam that also covers 'C', Unix, Java and SQL. Candidates are asked to rate their knowledge of the technoglogies from none, fair, good or expert. Therefore, I want the Perl section just to give me an indication that they are telling the truth. If we wanted a Perl specialist I'd do a technical interview with them later. The problem is I don't think the test I wrote does this. While some questions seem reasonable to me, I get complaints about others. OK Question 1 is a bit of a trick question - I think I originally saw it suggested on a Perl site and thought it fair enough. But I've seen fairly decent Perl people getting 3,4,5,6 and 7 wrong.

Does any one have any better suggestions?

Needless to say that I consider most people who read this site as more than acceptable for our needs!

edited: Fri May 2 16:19:40 2003 by jeffa - title change (was: A Perl test)

Comment on A Perl aptitude test
Download Code
Re: A Perl aptitude test
by hardburn (Abbot) on May 02, 2003 at 15:33 UTC

    People tend to learn the portions of Perl that are most applicable to their section of the problem set. I'm sure there are very experianced Perl programmers who never used the formating feature, but there are also people who learned Perl a month ago who use it every day.

    Your test seems to start with some easy questions and then gets a little more indepth later on. I would suggest throwing a few harder questions in there (perhaps a multiple-map statement similar to the Schwartzian Transform). Don't count it against them if they get it wrong, but use it as a flag to find people who really know what they're doing.

    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

      Thanks for your reply.
      I can't really add more questions - the total test, including the other sections, already takes over an hour. I think I just need to focus my questions better.
      When I first wrote the test I thought about a Schwartzian transform question but considered it too demanding for that stage and decided it was something I would ask about in a full technical interview.
Re: A Perl aptitude test
by gri6507 (Deacon) on May 02, 2003 at 15:42 UTC
    Excellent Question! If I may suggest a somewhat unorthodox approach to coming up with these questions ...

    There are plenty perl classes offered in both Universities and on the Web. It should be a moderately easy job to flip through a few "sample tests" and extract a few questions that you would feel comfortable with asking. If all you are looking for is general familiarity with the language, I think anyone who claims to know Perl on this level should be able to answer test questions from "Perl 101" and "Perl 102".

Re: A Perl aptitude test
by halley (Prior) on May 02, 2003 at 15:51 UTC

    Just a nit, but regular expressions don't change strings, they match portions of strings. The s/// operator employs a regular expression in the left portion to match, and then modifies the matched substring according to the right portion.

    [ e d @ h a l l e y . c c ]

      Of course and apologies, I transcribed the question incorrectly.
      regular expressions don't change strings
      Hmmmmmmmm. Regular expressions change no string? So sure you are. But for a Japhi, always more to learn there is. Use the Perl!
      $_ = "the end is nigh!\t\n \n"; m/(\s+)$(?{substr($_,-length$^N)=""})/; print "[$_]";
        I contend that (?{ }) is not a regular expression, but a hook (a place for a Perl expression) to be evaluated by the regex engine during its matching work.

        The phrase "Regular Expression" is a mathematical concept predating perl and emacs and sed. Quoting from Freidl's Mastering Regular Expressions:

          The Origins of Regular Expressions

          The seeds of regular expressions were planted in the early 1940s... Through the 1950s and 1960s, regular expressions enjoyed a rich study in theoretical mathematical circles... Ken Thompson's 1968 article Regular Expression Search Algorithm... led to his work on qed, an editor that formed the basis for the Unix editor, ed.

        Regular expressions are expressions that regulate a sequence as belonging to a set, or not belonging to a set. (What, you thought 'regular' as in 'everyday' or 'fixed interval'?)

        Since (?{}) doesn't fail and cause the engine to backtrack or bail, it's not regulating anything. The regex syntax handles the wrapping stuff but the contents are what's doing the string-modifying, and the results have no direct bearing on the regulation. That's what I mean when I say that (?{}) is not a regular expression.

        (I know, I'm forever editing and extending my comments with afterthoughts rather than creating new followups.)
        [ e d @ h a l l e y . c c ]

Re: A Perl aptitude test
by artist (Parson) on May 02, 2003 at 15:58 UTC
    If you want, you can make it trickier.
    Example: Question 1:
    print (print (2 * 3) + 3);


      hmmmm, I think they'd get it right by accident :-). As it stands no one has yet got the original correct so I don't think trying to make it harder is quite what I'm looking for!
      Question 1 is (IMO) a waste of time. I'm embarassed about it.
      Cheers anyway.

      I get 64. Why?

        You actually get a "6" followed by a "4".

        print (print (2 * 3) + 3);
        The inner print(2 * 3) is evaluated first: it prints 6, and returns the value "1" because the print succeeded. 1 + 3 is 4, so the outer print prints 4. There were no delimiters between the two digits, so they look like one number instead of two sequential digits.

        This brings up the original trick question quite nicely: the parentheses on print (2 * 3) + 3 make print() look like a function call, they aren't simply an arithmetic grouping operator in this case.


Re: A Perl aptitude test
by halley (Prior) on May 02, 2003 at 16:08 UTC

    I've made similar tests for new employees, not for Perl but for other technical competency measurements. I don't use them in interviews, though.

    I prefer to have a less formal interview. It should be a personal interaction so I can watch them think and react and formulate, and they can do the same of me. I may ask some technical issues and some political exercises (generic company politics, not world events).

    However, I like to give this kind of test to a new hire. The test is a bit tougher and in-depth than the one you suggest above. I stress that they aren't expected to get everything right the first time, but they have a fixed period such as one month to become well-versed on the range of subjects presented. Some breeze through on the first day-- we usually knew they would. Some take the opportunity and time to learn what matters to the company-- we usually knew they would. Some demonstrate their deficiencies, not only in a lack of prior basics, but also in their inability to self-research and overcome gaps in their skillset.

    [ e d @ h a l l e y . c c ]

Re: A Perl aptitude test
by crenz (Priest) on May 02, 2003 at 16:17 UTC

    I guess with such questionnaires, the whole discussion is more relevant than the answers to the questions. Do you let them take the test in written or in an interview? If it's an interview, I find your questions quite nice (except #1).

    Question 2 could lead to discussion about personal coding standards, question 4 could lead on to discussion about which modules you use, whether you've written any yourself etc. Likewise, an answer to question 6 that only explains the return values of <=> would be quite disappointing. A good answer would involve a few applications, like e.g. sort {$b <=> $a} and maybe even some personal experience where you got bitten by using it wrongly. A discussion like this can tell you a lot about a developer.

Re: A Perl aptitude test
by perlguy (Deacon) on May 02, 2003 at 16:20 UTC

    How about:

    1. Do you know who Larry Wall is?

    If not, thanks for trying. :)

The three great virtues
by danb (Friar) on May 02, 2003 at 16:46 UTC
    How about this question:

    8. What are the three great virtues of a programmer?

    (Laziness, Impatience, and Hubris). :-)

      Coding quality, understanding the bigger picture and knowing where to ask help.

      Asking anyone an aptitude question will tell you one of two things. They got it right or wrong. However, just because you don't have the same answer as they do, doesn't mean either of you are wrong.

      We have an aptitude test, and one of the questions is 'Where would look to find help?'. The hoped answer from the originator of the question was 'perldoc'. However, I tend to use CPAN PODs and O'Reilly books much more.

      Another thing to think about is that you shouldn't be trying to trip people up, but get them to tell you their limits. When you know someone has a limit, you then know what areas of knowledge you can impart to them.

      Another question was to write a closure. I personally hadn't written a closure until I read Damian's OO book and discovered how cool they were. I wonder how many experienced non-OO programmers there are who haven't a clue what a closure is?

      Birmingham Perl Mongers
      Web Site:

        Actually, it's more of "how many non-functional programmers who don't know what a closure is". Or, as a friend of mine put it, "Perl lets you do everything you'd want to do that LISP does, but without making it look like the language is hacked."

        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Re: A Perl aptitude test
by marinersk (Chaplain) on May 02, 2003 at 17:07 UTC
    My stabs as a new Perl programmer.

    1. Either a tab or a 9 gets displayed. Alternatively, maybe a 6 (or a an ASCII 6, whatever that is) followed by an ASCII 3? This seems unlikely. Or get a syntax error, I suppose, but something tells me that's not right either. I'm going to guess a tab gets displayed.
    2. Probably many reasons, but catching typos is good.
    3. Grr. I always have to look these things up. Guessing something in the s/\s+$// or s/\s*$// area would do it.
    4. Not sure. Guessing one has the scope of both the package and the main script whereas the other is scoped just to the package?
    5. Umm...sets $var to the value in the ...uhmm...last element (?) from the @array? Or does it give us the element count? I think it's the value of the last item. Have to look it up.
    6. Dunno. Read from STDIN?
    7. $a[2][0] (?)

    So...given how poorly I did on this test, we move on to your request for suggestions.

    Frankly, that depends on your goals. Sure, you're trying to assess peoples' skills. But interviews are also partially about assessing them as people. Do you want to make them feel disqualified and test their defensiveness? Or does this part of the interview come at the point where you want them to feel welcome and loosen up a bit? Or do you not play those kinds of games during an interview process?

    From a technical test perspective, I don't know that you need to worry about changing it. Just based on how close they come, or if they're willing to indicate where they think they'd go looking first is probably enough to determine if you've got a problem-child or a problem-solver sitting in the hot seat. In my opinion, that's worth more than education when it comes to software development and maintenance. Especially at entry level positions.

    Now to go look up the answers to see how badly I did.


Re: A Perl aptitude test
by hv (Parson) on May 02, 2003 at 18:30 UTC

    I'm not sure how to answer this, because I find it difficult to imagine describing someone who got 3, 5, 6 or 7 wrong as a "fairly decent" perl programmer. 2 and 4 are more difficult, particularly since the candidate needs to guess how much they should say - I'm sure you could write for an hour on either one without exhausting the subject.

    But they all seem reasonable questions; the only one I think is a bit unreasonable is #1, because it is code you wouldn't normally ever expect to write except in error. Perhaps more reasonable would be to say something like:

    1. This code prints "5". Why is the "+" sign necessary? print +(2 * 3) - 1;

    Because of their open-ended nature, I'd also be inclined to put 2 and 4 last, and perhaps keep just one of them: they feel more like "extra credit" questions.

      the only one I think is a bit unreasonable is #1, because it is code you wouldn't normally ever expect to write except in error.

      I think the problem with the question is that the parens are there only to be "tricky". The error would be more understandable if the parenthesized operation was of lower precedence.

      So I'd have posed the question like this:

      1. The following line of code is an example of a common coding error in Perl:
        print (2 + 3) * 4;
        1. What does the statement print?
        2. Why?
        3. How could you fix it?
Re: A Perl aptitude test
by vek (Prior) on May 02, 2003 at 19:09 UTC
    The output you receive when running the code in question 1 depends on whether you have warnings turned on. Did any candidate mention that, was that part of the answer you were looking for? I'm just curious :-)
    #!/usr/bin/perl -w print (2 * 3) + 3;
    Results in:
    print (...) interpreted as function at line 3 Usless use of integer addition (+) in void context at line3. 6
    Remove warnings and you just get 6

    -- vek --
Re: A Perl aptitude test
by logan (Curate) on May 02, 2003 at 20:58 UTC
    I think that problem solving skills are more important than syntactical knowledge. A better question would be to ask them how they'd measure network traffic on a unix server. That way, you can drill down on specifics without getting hung up on syntax issues that would be found and corrected during the development process.


    "If it's going to run as a one-shot, I'd run netstat using flags to isolate only the information I need and discarding the rest. I'd put a system call in a loop, use split to assign the different name-value pairs to a hash, and print them to STDOUT or to a file as CSV so we can import the data into an Excel spreadsheet or a graphing utility. If it's going to be running as a part of a standard test suite, I'd use a Unix::netstat instead of a system call to save CPU cycles. I could be wrong about the specific module name, but I'm sure that there's a module on CPAN to drive netstat. BTW, if you want to measure CPU and memory and disk i/o as well, sar is probably a better choice than netstat."

    At this point, the examiner can determine that the interviewee knows something about unix and its internal monitoring tools, CPAN, hashes, the expense involved in doing repeated system calls, and how to present data. Plus, they have a bead on how to develop a quick-and-dirty tool vs. a productized tool suite. The specific syntax of netstat and split are things that can be checked once coding has begun. It's far more important to see the thought process and system experience than to nitpick over syntax. If you hire them, they'll have the Camel book on their desk anyway, so why freak out over comma placement?

    "What do I want? I'm an American. I want more."

      netstat? Unix::netstat? sar? If this aint domain specific syntactic fluff than what is?

      I thought we are talking about a Perl test here, not a Unix admin one. If you asked me the only reply you could get is "I'd search CPAN and PerlMonks to find something I can use/tweak to our needs".

      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
         -- Rick Osborne

      Edit by castaway: Closed small tag in signature

        Ah, but if you didn't know something about netstat or sar, you wouldn't be applying for a tool development job in a unix shop, would you? My point is that it's better to ask about the application of the skill than the syntactic details of the tool itself. If you were hiring a carpenter, you'd ask about how they would build different things, not the design of different types of hammers. Obviously, if you're applying for a postition in a Windows-based company or a development position where networking isn't an issue, the question would be different. The concept, however, remains valid.

        "What do I want? I'm an American. I want more."

Re: A Perl aptitude test
by gmpassos (Priest) on May 02, 2003 at 22:00 UTC
    Well, the user can test the code before answer it?

    The first question is trick. First doesn't make sence write it, since why add 3 to the 1 returned of the print if you aren't catching the print return?

    And you should write:

    print ((2*3)+3) ; # if you want to print 9 # or... $ret = (print(2*3)) + 3 ;
    I think that you can skeep this question, since you are testing a code that doesn't make sence! There's much better things that you can test. Like ask to make a simple OO module, make a tie object, and use DBI.

    The other questions are fine.

    Graciliano M. P.
    "The creativity is the expression of the liberty".

      Actually, I quite like Q1 and find it appropriate. I ran across this behaviour multiple times as a beginner and it was not until I had a firmer grasp of the language that I understood exactly where and why I need to disambiguate things. TheDamian has the better suggestion on what to do about that question.

      Makeshifts last the longest.

Re: A Perl aptitude test
by Aristotle (Chancellor) on May 03, 2003 at 01:32 UTC

    To be honest, I find it hard to think of anyone who gets any of the questions other than #1 wrong as as fairly decent. At best, they know how to use Perl for a quick one off task (which is a pretty useful skill, no doubt), but I wouldn't rely on them for writing anything that has to be reliable.

    #1 is not a waste of time at all, though I'd rather make it a bonus question. This specific parsing rule has certainly tripped up every Perl beginner at least twice, and probably plays a trick even on more advanced programmers once in a while. I know it took me quite a while to understand the semantics exactly. I'd consider someone who answers that question fairly capable at understanding Perl code (which includes their own) although it doesn't necessarily mean they are used to good coding practices (like strict).

    Regarding strict, I would extend the question to also ask when it is not useful. Truly insightful coders know when to break the rules.

    Similarly, in #5, I'd also ask for an explanation of $var = @array;, and for a comparison between the two.

    Overall, I think the questions are decently chosen. I would consider someone who answers them all well unlikely to make a big mess with Perl.

    Makeshifts last the longest.

      Similarly, in #5, I'd also ask for an explanation of $var = @array;, and for a comparison between the two.

      Thanks Aristotle; you induced self doubt there given that i was also thinking of the value of a list being evaluted in scalar context.

      So i suppose, OP could add/replace a question something like..

      What are the values of $x and $y below? @odd = (1,3); $x = @odd; $y = (1,3);

      ...I feel much better now after consulting w/ perl.

      I keep on seeing people saying this, and here I am thinking to myself, "Gee, and here I would only give myself even odds of getting #6 right." I know what the operator is for, I know how to use it perfectly well as a sort function, I know how to use complex combinations to do sorts on complex data.

      But do I know whether the comparison function is supposed to return a 1 or -1 to sort to say that the left side is smaller than the right this time...? I could guess but I never remember that. If I really need to know it, I can look it up any time. All that I need to know the vast majority of the time is that whatever way it goes, sort and the comparison functions agree on how it is done. (And this tidbit is of a kind I find hard - for instance I still have to think about whether in a LEFT JOIN the table you want to fill in blanks for should be on the left or the right.)

      EDIT AUG 2009 Somehow this node got badly messed up. I've filled in the end with what I think is my original thought, but it is unlikely to be right. :-(

        (Indeed anyone who develops an understanding of obscure constructs by constantly experimenting with how many language constructs they can use is a hazard to your code base...)

        Interesting viewpoint.

        Do you have a feel for which (perl) language constructs you would deprecate from your codebase?

        Would this be a single, hard & fast list or would it vary by codebase or project?

        Is it just knowing the obscure constructs that constitutes the hazard? Or does the person have to use them before they are guilty?

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
Re: A Perl aptitude test
by jonadab (Parson) on May 03, 2003 at 04:54 UTC

    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 o";print;sub _{ord(shift)*($=-++$^H)%(42-ord("\r"))};
      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 o";print;sub _{ord(shift)*($=-++$^H)%(42-ord("\r"))};

      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.
Re: A Perl aptitude test
by mod_alex (Beadle) on May 03, 2003 at 10:39 UTC
    I'd like to offer you not to ask particular questions about some tricks in Perl or any particular programming language. As someone told usualy programmers concentrate on special tasks and don't remember exact syntax's tricks of such huge language like Perl.

    As I know and I eagerly welcome that lot of companies test IQ of potential employees by providing them test with some abstract language, also a person is tested should be provided with documentation of syntax of that abstract language.

    In addition you may provide to develop some application using perl or whatever else with computer and documentation.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://255028]
Approved by sschneid
Front-paged by tye
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (5)
As of 2014-04-17 01:12 GMT
Find Nodes?
    Voting Booth?

    April first is:

    Results (437 votes), past polls