http://www.perlmonks.org?node_id=339562


in reply to Re: How to measure Perl skills?
in thread How to measure Perl skills?

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.

Replies are listed 'Best First'.
Re: Re^2: How to measure Perl skills?
by Juerd (Abbot) on Mar 24, 2004 at 22:50 UTC

    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

        This is a really nice idea. Because actually, I think the skill you actually want to test for with this is not so much working with incomplete specifications, as much as recognizing them. I've known programmers who would get a project, think they understood what was required, and only after coding for a month realize there was some unspecified but very crucial detail, and how it actually needed to be worked out ended up invalidating a large chunk of what they'd already done.

        I guess the best way to get real world ambiguity would be to ask marketing to write up the test problems :-)

      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.