The day before yesterday, I held an interview much like this one. I presented a candidate with a problem of easy-to-intermediate difficulty (Fibonacci) and asked him to explain his thought process while coding. I did interrupt his thought process two times to ask what he was thinking, both times when it felt obvious that he was stuck (extended staring followed by a couple of heavy sighs). But my principle was to only provide him with advise when he asked for it. I told him beforehand that his performance was not evaluated or affected by getting stuck or asking for guidance, but that we would not leave the room until we had come up with at least one solution together. I stayed in the room but was drinking coffee and reading e-mails. I told him that the excercise is expected to take up to an hour, and that he didn't need to hurry. When I tested this problem on two of my colleagues it never took more than 15-20 minutes.

This excercise in particular took a little more than an hour, because even though I explained a few solutions in various ways he had a hard time actually completing any code. I wrote a whiteboard solution and explained it using arrows and walk-through examples, but he couldn't translate the solution into actual code (using a language of his choice). In order not to break the hour limit we ended up with me writing and explaining code one line at a time for him. I reassured him that it's okay that he can't come up with the code right now, we're not evaluating the result etc.

I turned this candidate down. I feel that while my methodology (close to OP's) has flaws, it does help me with filtering out the worst candidates. I simply can't hire someone that doesn't manage to, with an unlimited amount of help and a generous timeframe, code a Fibonacci sequence in his/her favourite language.