You're all wrong. Firstly, for the crowd arguing about whether this is a good/bad/ugly question, your initial premise is wrong, because you pre-suppose that th

You're all wrong. Firstly, for the crowd arguing about whether this is a good/bad/ugly question, your initial premise is wrong, because you pre-suppose that there are any good programming questions to ask in an interview. Since waffling about this sort of crap is entirely orthogonal to actual coding skill, there are no good questions, they are all bad. It's like trying to find the fastest marathon runner before the race by interviewing everyone and deciding who will win based on who gives the 'best' answer. Secondly, for the crowd debating the algorithms and offering better programming methods, or smug in your assurance of quadratic/linear/O(n) time or whatever, you're all wrong because your initial premise is wrong. You assume this is a programming problem, but programming is the wrong tool for the job. A much better general purpose tool for 'solving' this problem (but not even necessarily the 'best' tool) would be a spreadsheet for instance. Using a spreadsheet you could have finished (including testing - e.g. eyeballing the result for correctness) before the 'optimisers' have even finished typing in their code. In terms of effectiveness, you silly coders might as well be using pea-shooters in an ICBM competition.