> 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
