Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: How to measure Perl skills?

by Juerd (Abbot)
on Mar 24, 2004 at 10:13 UTC ( #339344=note: print w/ replies, xml ) Need Help??


in reply to How to measure Perl skills?

I'd include in my test at least one trick assignment. Ask them to write a bubble sort. If they do so without suggesting using sort, they fail. Unless of course you're looking for a monkey who will do exactly as you tell.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }


Comment on Re: How to measure Perl skills?
Re^2: How to measure Perl skills?
by Aristotle (Chancellor) on Mar 24, 2004 at 21:55 UTC
    This might seem like a good idea in principle, but you would have to be really careful about the wording of the assignment. If it just says "write a bubblesort", chances are I would, without asking any questions. That doesn't mean the idea would ever cross my mind in real code.

    Makeshifts last the longest.

      If it just says "write a bubblesort", chances are I would, without asking any questions.

      If you write the bubble sort without asking questions and without suggesting a better way of sorting, you would not be the ideal employee I'm looking for. There are employers who want their people to do whatever they say, without asking questions. I think a question like this is a good way to find out if employer and possible employee match.

      The wording would be "Write a bubble sort". Of course, somewhere much earlier in the interview, you'd have to mention that you're not looking for typing monkeys :)

      It's a trick question for a reason. It's a test. If you explicitly state you want suggestions, it is no longer a test.

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

        You've reminded me of another useful skill:

        Working with incomplete specifications.
        I found that most requests were not meant literally, were ambiguous at the outset, or were given in some technical jargon [other than programming]. The ability to refine and negotiate the problem statement will finish projects (sooner), and be more satisfying for everyone.

        So consider writing up your toy interview problems incompletely, with some inconsistencies and red herrings, just like in real life.

        -QM
        --
        Quantum Mechanics: The dreams stuff is made of

        It will only work if you want to hire know-it-alls.

        If someone tells me "write a bubblesort" in a test, I assume they know what a bubblesort is and have reason to ask for it. I (correctly, you will have to admit, since that was the whole point of your "excercise") assume that they know its drawbacks. It is not unreasonable to conclude that bubblesort is being used as an example for a simple but non-trivial algorithm. There are a several minor design choices to make when implementing it, some (slightly) consequential, some not. The interviewer might be planning to inquire about my particular judgement calls.

        If I were an interviewer who had this kind of thing in mind and you revolted at hearing "bubblesort", I'd likely deduct points for missing the big picture and/or dismissing the idea that you might not have all the facts to know the reason for my request.

        That's what I meant when I said that you have to be very careful with the wording: you must avoid giving the impression that you had other things on your mind than just getting a bunch of scalars sorted as easily as possible.

        Makeshifts last the longest.

        I understand what you're saying, but I think this particular trick question is probably too much of a trick. "Write a bubble sort" really comes across as a test of familiarity with algorithms, not a test of lateral thinking skills. I guess if you're looking for a person who will respond to the seemingly straightforward "implement algorithm X" with "why don't I do Y instead?", then you'll probably find someone who responds that way. But ultimately I think you're probably tricking yourself, as you will miss out on talented folks who just happened to take your challenge at face value.

        -- Mike

        --
        XML::Simpler does not require XML::Parser or a SAX parser. It does require File::Slurp.
        -- grantm, perldoc XML::Simpler

        Horrible. If you asked for a sort and they used bubblesort there would be an issue.. if you asked explicitly for a bubblesort then there could be a good reason. Just like doing a generic class for a test that you would never use in real code.. I generally assume an interviewer ISN'T out to trick me, but to actually test what I know. You sound like the PhD interviewer someone else mentioned who was too caught up in how clever they are to make relevant tests.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (12)
As of 2014-07-30 14:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (234 votes), past polls