A dozen? Perhaps a dozen of the easiest ones that one can do in a few minutes, but even so it seems like a lot of work for a pre-interview screening. But many Project Euler problems require a great deal of thought and are mostly testing mathematical prowess.
How much work are you comfortable making your candidates do before they even know whether they're getting an interview?
Yep sure, I'd expect any competent programmer to be able to bash out the first dozen without it being too onerous. Think of it as FizzBuzz-on-steroids. Remember this is only a screen, and it's something many programmers would find to be fun anyway!
Our time is still finite, especially when we are in job hunt mode. One party should not expect the other party to invest a lot of time in the process without doing so themselves.
I'm particularly sore because I spent a bunch of time working on learning something domain-specific for a potential employer who verbally indicated the interview process would be proceeding, but then forgot to tell me for a week they had decided to end the process.
Well, I just did it. It took me about 35 minutes. I am terribly, terribly old (43 years) but I'm pretty sure I am a more than competent programmer and I have a very strong mathematical background. I was working on a laptop but a reasonably decent one, in an environment less distraction-free than an interview room but still not bad. I didn't particularly go all-out for maximum speed but wasn't gratuitously slothful.
I (deliberately) didn't use a programming language with, e.g., facilities for prime factorization built in; that would have made it much quicker but would also have made the whole thing useless as a programming test. So I had to implement the sieve of Eratosthenes, the number-of-divisors function (via prime factorization), etc.
I estimate that about 8 minutes of that time was the result of a couple of silly bugs. (It's surprising how many seconds one can lose to forgetting that 16 is less than 20.) That figure could easily have been zero or twice as much. I lost perhaps two minutes to spousal distraction.
These are all straightforward problems; in no case did I have to spend more than a few seconds thinking how to proceed, though in a couple of cases my response to having written buggy code was to replace it with something more simple-minded.
recursive, I invite you to actually sit down and implement solutions to the first 12 PE problems in, say, Python or Ruby or some similar language and tell us how comfortably under 30 minutes you come in. For the avoidance of doubt, I'm not at all saying you won't manage it -- I wasn't far off and you may very well be quicker than me. But I'll be surprised if you're so far ahead that after the exercise you still think every competent programmer should finish in at most 30 minutes.
(My rough timings for the 12 problems, in order, in minutes: 1, 1.5, 1.5, 1, 3, 1, 3, 2, 1, 4, 5, 10. These figures include bugfixing and checking against the PE site. Total lines of code: about 115.)
Right, sure. So pick n of them, say any n, or a list of problems you think are suitable (enough to act as a filter, not so much that they'd take too much time). I interviewed with a company last year that wanted any 10, and resolved to steal their technique for my own use. Did well enough to get to the next stage, tho' ultimately didn't end up working there.
How much work are you comfortable making your candidates do before they even know whether they're getting an interview?