Actually, if they spend more than two hours, the question is why. We are happy to see them get interested in the task and dive deeper, but we just don't want to

Actually, if they spend more than two hours, the question is why. We are happy to see them get interested in the task and dive deeper, but we just don't want to ask for more, that would be unreasonable in our view. It's fine if the code is broken, or has a couple of bugs. (It's best if it compiles though!) The goal is as much to learn how they think, solve problems and communicate as it is whether they know how to write software. I'll give one example: One task is to figure out how long it takes to grab the current time from the operating system. We use a rather obscure OS. A candidate chose this and solved it simply (though it's got a couple of points to mind), but then he got curious and wanted to know whether a virtual machine had a different timing and then what the performance on a different operating system was. He told us that he spent about 8 hours altogether. I felt a bit bad on one hand, but on the other, it's exactly what we like to see: Solid programmers who love programming technology for its own sake.