Why aren't you replicating this in your interviews? Why do you insist on code tests? Why aren't you insisting on the result? That's what your boss wants. I'm pretty sure he doesn't care about your ability to solve stupid trivia and academic tests.
This is why I'm saying you're a bureaucrat. You read somewhere about fizzbuzz and code tests and you stopped there. Didn't think for yourself. Just gobbled up what some other guys decided was good.
Want great conversations and to be amazed by experts? Give them real life problems to solve. You will look incompetent too if I start interviewing you with stupid "How do you do X?" questions.
But I'm going to level with you: if my expert can't handle a simple problem with training wheels, like FizzBuzz, it is a very strong indicator that attempting to give him a bigger problem to solve (but not code) is a waste of time.
2. I don't believe in memorizing stuff, I believe in understanding stuff... which is why I'm an engineer.
You say: "his answer will always be "Why? What problem are you trying to solve?"
Indeed, I WANT people to ask this question. Then I'd like them to suggest why a linked list is or isn't a good candidate for that problem. I will ask them to suggest an alternative method of solving my problem. A good interview is a conversation, but if the candidate has literally no questions to ask, and nothing to provide, and can't even solve the most basic problems that could be memorized, then why would I want him? If a candidate can't come up with a half-decent approach to a problem as simple as FizzBuzz or making a simple data structure container like a linked list; a problem which dwarfs in comparison with what I do on a daily basis at my job, he has no business sitting next to me.
You also say: "Asking an engineer to solve an imaginary problem on the spot is idiotic. "
Well, that just happens to be my job! My boss comes down, asks me "could you solve this problem for me?" and my answer is "I don't know, but I'll try!" and off you go. so my entire job is about solving unknown problems. Isn't yours? I'm not setting up WordPress sites or chaining together SAP modules (not that there's anything wrong with that, I used to do something like that for several years...), we actually solve problems that don't have known solutions, and the amount of data we work with also poses some unique problems. So our interview process is a miniature, and yes, imaginary, version of what you might be tasked with on any given day.
Finally, to clarify, this it the stance I take with people who claim to be "experienced experts". If I'm interviewing an intern or a junior developer, my approach will obviously be very different.