> From: Greg London > Sent: Monday, March 07, 2005 9:50 AM > > And if the applicant seems to take joy in simply pointing out > the problem as a way of demonstrating how smart they are but > consistently needs prodding to answer the meat of the question, > I wouldn't let them work for me if you paid me. I've got a > linux box with perl installed that will complain about compile > errors and just sit there until I fix them. I don't need to hire > someone to do that.
I absolutely agree with Greg's comment on noticing the approach to the problem/solution rather than the solution itself. I think the essential things to look for are: (a) understanding of programming (not just Perl) fundamental concepts, esp. if hiring for a beginner's position: - Why/When use OOP? - When would you use an array over a linked list or a hash & vice-versa? (if you don't hear things like "constant time lookup" or "addressing overhead" or "easier to sort & merge", then you should start wondering what they were doing in their data structures/algorithms class & maybe start thinking about the next candidate) - Basic questions on boolean expressions & operator precedence like, why does 'open(...) or die "..."' work? (and similar questions posed by Greg) - A rather nasty problem I sometimes pose is to print the answer to: $> perl -e '$x=1; $y=$x+++1; print "x=$x, y=$y\n"' While I would never write code like that (in case you were wondering) I like the question because most candidates can't give a canned answer & are forced to think about operator precedence (the answer to this is deterministic in both Perl & C across all compilers) [Correct answer: x=2, y=2] (b) nothing to do with Perl - just assess the person's attitude vs. your own team's dynamic. To me, this is much more important then the exact technical skill. -Nilanjan _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm