"Peter Morris [Droopy eyes software]" <pe**@droopyeyes.no.com.spam>
wrote:
2) Write some basic code that generates mazes ... make them write code to
solve a maze
3) Make them write code to find the optimum solution to a given maze
I'd walk out of the interview if I saw questions like that :-)
Those are not difficult questions - relatively easy with a little
recursion, and they're the typical questions you'd see in a programming
contest. However, these two together would take an hour or so to write
and debug (probably longer if one had to read and write the mazes /
solutions to a particular data format), preferably in private and on a
computer with one's preferred setup available.
Talking through them, I don't think that's unreasonable. But it's still
basically a test of knowing when and how to apply recursion, and not
really a test of code reasoning.
I would prefer a coding sample that was actually simpler, but admitted
several approaches, each with varying tradeoffs. One could then discuss
the tradeoffs, and the varying approaches, starting from a high level,
and working down to a lower level, and considering each possibility with
its tradeoffs. In these cases, the simpler the problem the better,
because it takes less time to explain, but that are open-ended,
admitting more creativity.
An odd thing about (and IMHO one of the bigger problems with) the maze
problems above is that correct solutions are almost guaranteed to have a
certain algorithmic complexity (linear in the maze area assuming a
classical "children's pen & paper maze" fitted on a grid inside a
rectangle, for both problems).
-- Barry
--
http://barrkel.blogspot.com/ 
