This can be problematic, you waste a lot of time setting up the PC / explaining the problem. Last time I was involved with this interview style it always seeme

This can be problematic, you waste a lot of time setting up the PC / explaining the problem. Last time I was involved with this interview style it always seemed to take an hour to get setup which meant a long interview of 3-4 hours particularly if a candidate went down the wrong path. In the end we optimised for SOLID principles with a blackbox dll that had a function that slept for 2 seconds and a calling class that had mixed responsibilities (logging and calling the dll). We started folks off with a test or two and hoped they'd inject a mock to get rid of the delay and split logging off into a separate class. I'm not saying it was a great test but you could do something within an hour or so then maybe spend half an hour talking through what techniques they'd use for a more complicated scenarios. If you can afford the time then more realistic testing is great and I do think you should try.