Absolutely agree with the sentiment here. I have used this technique for a couple of years now, except that I kept the task to 20 minutes (and didn't pay people, since it's a short amount of time).
To save dragging people into an office for that time period, I set up a custom git server that marks the timestamps of their pulls and pushes. The instructions for the task are contained in the README of the repo, so as soon as they pull it they've started.
20 minutes is way too little for a meaningful programming task that's worth presenting to the other devs (and that's the really vital part of this method in my opinion).
I prefer to see what people write in their normal way of working when they're not under extreme time pressure.
To save dragging people into an office for that time period, I set up a custom git server that marks the timestamps of their pulls and pushes. The instructions for the task are contained in the README of the repo, so as soon as they pull it they've started.
https://github.com/Prismatik/codescreen
It's critical to me that the limit is adhered to so that over time I can compare candidate responses on a level playing field.