On May 13, 3:57 pm, John Machin <[EMAIL PROTECTED]> wrote: > Matthew Woodcraft wrote: > > Gabriel Genellina <[EMAIL PROTECTED]> wrote: > >> I would like to write a similar problem without this non-programming > >> distracting issues (that is, a problem simple enough to be answered in a > >> few minutes, that requires only programming skills to be solved, and > >> leaving out any domain-specific knowledge). > > > Another reason not to like the FizzBuzz example is that it's quite > > closely balanced between two reasonable approaches (whether to just > > special-case multiples of 15 and say 'FizzBuzz', or whether to somehow > > add the Fizz and the Buzz together in that case). The interviewee might > > reasonably guess that this distinction is what's being tested, and get > > unnecessarily stressed about it. > > For such a trivial problem, fifteen minutes is more than enough to > present alternative answers. Perhaps the intention is to weed out those > who do become unnecessarily stressed in such circumstances. Employers > like to play tricks to see how interviewees respond e.g. hand over two > pages of a listing of code in language X, announce that there are 10 > syntax errors, and ask the interviewee to find and circle all the syntax > errors. Correct answer: 11 circles.
They get away with that? The one time I was asked to compose a (hardware) test was because some interviewee threated to sue claiming discrimination. So I was asked to make an absolutely trick-free test. Such as what's the voltage at point A? +5v | 220 ohm | +-- A | 330 ohm | ground Would you be surprised at how many applicants couldn't figure that out because they forgot to bring their calculator? Sure, I had a page from a schematic, but only to ask how one of the shown T-flip-flops worked. One female interviewee took one glance at the schematic and said, "Oh, it's a parity generator." She got hired. I'm surprised anyone has to resort to tricks. -- http://mail.python.org/mailman/listinfo/python-list