Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Are you sure you're testing programming skill and not just test taking ability? I ask because I'm a really good test taker and I know how much that slants the odds. If you sat me down with a programming manual for a language I'd never touched I bet I could beat an average test taker with one year of experience in the language. Would that mean I'd be the better guy for the job? Probably not!

    Also, did you make them write it down on paper? I absolutely hate trying to program in pen. I've been tempted t

    • Actually, I think you probably would be better for the job. I'm a good test taker as well, but this is limited to the classic multiple choice tests where the elimination strategy works 80% of the time. The sort of test discussed here is a little different: if you can sit down with a manual of a language never seen and whip out a working and correct program then you can probably pick up everything you need about the language to get your job done. Yeah, you're missing idioms and other features you can reall

      • Well if that's the kind of programmer you want then you might as well test for it explicitely. You could create a manual for a fake computer language, give the applicant an hour or so to read it and then have them do a few test programs. This was actually done in my CS 202 class at college and it was the most fun I've ever had in a test.

        But I'm still really concerned that you'd be missing out on some fantastic programmers that have a different psychology.


        • I can almost see your point, but the nature of the questions that we pose to candidates are so basic (e.g.: what's the potential performance impact of nested loops?) that I am very concerned about someone's inability to respond to them. In contrast, in the Perlmonks thread I started on this topic, someone mentioned writing a routine to go through a binary tree without recursion. While this was described as simple, I find that I encounter nested loops far more frequently than binary trees. I could easily write the binary tree program -- with a copy of Mastering Algorithms by my side. I find I usually don't need them in Perl. When I recently needed a graphing solution with adjacency lists, I pulled out Mastering Algorithms again. I want to memorize the simple stuff and look up the complicated stuff.

          As another example, if we were hiring a DBA, I'd ask them to describe the first three rules of normalization, but I'm going to be less concerned if they can't describe the fourth and fifth normal forms well as these are rarely seen in production (plus, I've seen database books that argue about what these forms really are).

          Admittedly, there may be some great programmers out there that we miss, but I tend to follow the Pareto rule which states that 80 percent of your results stem from 20 percent of your actions. I might miss a great programmer here or there, but so far, those programmers who I respect have had no problems with those questions and those who I've seen struggle seem to less skilled.

          Of course, to totally destroy my argument, one of the programmers who totally fumbled the nested loops question actually wrote a rather nice test program :) It had some issues, but given his time constraints, I think we definitely would have hired him were we to have a position for him.