There are definately "Google" problems that are hard to solve if a mental meltdown is ongoing. There are problems that, even if you get the solution explained to, you might not "get" initially.
Fibonacci is not such a problem. It includes declaring one argument, a handful of variables, one for loop, a couple of assignments and a return statement. And he could not do this with open and explicit guidance.
As he was applying for a senior backend developer position, I can only conclude that morphing complex data structures and calculating shopping carts with taxes, rounding and campaign deductions will be a problem. Maybe I'm wrong, and I should mention that there were additional interview steps and questions where my interview partner didn't have confidence in the candidate, but I really feel that this excercise tells me something. And that's the problem with these kinds of interview techniques I guess. That they do feel very relevant.
Yep, when I got hired, 4 years ago. And I liked the experience so I keep using it today. When completing an imperative solution (with a little guidance, due to nervousness) I went on and made a recursive one, just to try to show off. And it got me the job.
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.
Fibonacci is not such a problem. It includes declaring one argument, a handful of variables, one for loop, a couple of assignments and a return statement. And he could not do this with open and explicit guidance.
As he was applying for a senior backend developer position, I can only conclude that morphing complex data structures and calculating shopping carts with taxes, rounding and campaign deductions will be a problem. Maybe I'm wrong, and I should mention that there were additional interview steps and questions where my interview partner didn't have confidence in the candidate, but I really feel that this excercise tells me something. And that's the problem with these kinds of interview techniques I guess. That they do feel very relevant.