Piers Cawley writes: > Tower of Hanoi is always a better example for solving with recursion > than the fibobloodynacci sequence. If nothing else, the recursive > solution isn't quite so immediately obvious from the problem, the > terminating condition is obvious and an iterative solution isn't quite > so hogwhimperingly more efficient.
Yes, that's much better. What makes a good question depends to some extent on what you want the person you hire to do. One way of considering this is to think about existing (or previous) team members, and what distinguishes the better ones. It may be computer sciencey algorithm stuff and implementing things efficiently. Or it may be being sufficiently comfortable with Cpan, and gluing together other people's modules to get stuff done. Or carefully dealing with edge cases in awkward-shaped real-world problems. Or looking at a business spec and divining what is actually required here. Or ... Often these don't all come together, so I think it's worth putting some effort into making interview exercises test the kind of thing which makes people useful in your particular team, rather than skills which mark out a good software engineer in the abstract. That of course means that what some people may consider to be a poor interview question is a most splendid question for a different vacancy. Cheers Smylers -- New series of TV puzzle show 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect