I'd rather take my time asking you your knowledge of key libraries and interfaces

What use is that? That *is* asking for rote memorization.

If you really wanted to test someone's rote memorization of the Big O notation values of various algorithms

Why would you want to test that? That's pointless. At the very least if you ask about complexity of common algorithms, you should also ask them to explain how they determined it, or could determine it. Even better, ask them to create an algorithm to solve a problem, then ask them about the complexity of *that*. Then they have to actually work out the complexity, demonstrating that they understand asymptotic complexity as a concept, rather than just regurgitating. Then take it one step further and see if they understand the difference between asymptotic and real-world complexity, and why the ideal algorithm for massive data sets may not be at all appropriate for small ones.

My goal in an interview is to make the candidate *think*, and to watch how they do it. How do they explore the solution space? Do they tend to get stuck on one unproductive line of inquiry, or can they step back and try another angle? Can they see ways to reformulate the problem to simplify it? Generalize it? Specialize it? Do they understand the tradeoffs of various design decisions? How effectively do they collaborate with me on the solution? Good engineers know when to ask for help.

Oh, and... can they write code? Because it's amazing how many people walk in fully able to talk the talk but when asked to produce some functional, reasonably-clean code fall flat on their faces.

Those are useful things to ask about. Memories of libraries and interfaces? Useless. Actually, probably counterproductive unless what you really want is someone who is deeply specialized, then you can ask about the relevant components in that specialty. But in the common case it's far more important to find out if they can reason, problem-solve, code and interact with you. They can google the specifics.