The problem is very few things are short term tasks in isolation. So, someone that takes a while to solve 6h problems can be really efficient in the long term. Worse, short term problems need to fit the same type as what your actually doing.
PS: As soon as someone says "i don't know" you need to stop and realize they would spend a few minutes on google. Spending more time on the topic at this point is pointless.
Or, give them the answer and see what they can do with the information. IE, pretend that they DID lookup the answer and go from there. Did they grasp the concept? Could they make logical inferences from that new concept? If they can't do it when you tell them the answer, why would you think they could if Google told them it instead?
Remember the context is the Job not the interview. On the job, having not done something for 3 years is a minimal setback for most people as the retraining time is almost meaningless. In an interview that 'highly' skilled person is going to take a long time to get back up to speed.
b) Find a bug in a source code. Describe the end-user captured bug, and measure the time and the quality of the solution.
c) Simulate a distributed code review and measure the found problems. This can be extended to UX as well.
(These are just quick examples.)