We gave them as much of a headstart as we could too: a dedicated laptop with an IDE already running, a "skeleton" program for each of the five options already in place, etc. All they had to do was finish the program in order to produce the correct output. The only thing we didn't really allow was using the Internet to look up answers (the machine in question had its network connection intentionally disabled). I think we usually gave about 30 minutes for this, but even that wasn't a hard cutoff that was strictly enforced.
Despite that, it was sad how many people not only couldn't complete this test, but frankly didn't even come close.
Note that the "skeleton" code was in Java, but this was for positions that were specifically advertised as expecting Java experience. IIRC, we also later added a Python version. And frankly, if somebody had come in and said "I can do this, but can I use (R|C++|COBOL|Brainfuck|Whatever)?" I'm pretty sure we would have said "Yeah, sure, have at it. We just want to see if you can code."
My absolute favorite thing to do is go over the candidate's work history (or classes/personal projects if a recent grad):
* What project did they enjoy the most?
* What did they work on specifically?
* What trade-offs did they make?
* What were the major risks early on?
* How were those risks mitigated?
* Were there any unmet goals?
* What would they change in hindsight after seeing the project through to completion?
* What parts of the project were the most frustrating (non-technical answers here are great, like frustrations with deadlines, other team members, management, constantly changing goals)?
* What did they walk away having learned?
* How have they applied what they learned to future companies/projects?
It takes a bit longer, but it's so worth it. If you get a good programmer talking about a project they are proud of, you can end up talking for 30-60 minutes easy about every detail, have fun doing it, and learn a lot about them: how they think, how they work, how they work with others, how they work under pressure/deadlines, do they communicate well about problems, whether they'll be a good fit culturally, etc.
I don't get how it's a real interview question considering that it requires hardly any thinking at all. You're almost directly writing the description of the problem in code instead of having to think about algorithms, complexity, data structures or edge cases, like in most other problems. Is a test of if-statements and remainders that useful of a filter/signal?
I know that some companies give it because I've had to do it myself but I still find it bizzare to give such an easy test. Maybe it's fine as warm-up in a series of questions and it's used to make the candidate comfortable?
Throw some code up on a screen and ask a candidate to tell you what it does, what they think about it, what they might do different. We all have that piece of code that is the skeleton in the proverbial closet.