And part of a real job involves solving real problems. In an interview, you have a very limited time, so you have to come up with questions that test the candidate's ability to solve problems within a certain timeframe.
Except the problem is (which I didn't state but pointed out) is that this isn't really a "problem." It's just math. That's it. If you want to know if I know how to multiply two numbers together, you might as well just ask me if I know what 2*2 is and move on to the next question.
IIRC, their first reply was what they would type into a calculator, not “I don’t know”. Only when confronted of what the result would be did they say “I don’t know”, because any human with a life wouldn’t know off the top of their head.
Another example is from my own "worst interview ever" where the guy asked me to implement a BFS and a DFS on a tree. I mentioned that I'd literally been debugging an issue with a DFS algorithm all day at $dayjob, so should be a piece of cake. I wrote out the DFS example in 10s, but then when I got to the BFS, I spaced out on how to write a for-loop. The interview literally just laughed at me, saying, "that sucks for you" so instead I simply showed him how a BFS works and his answer was, "I don't care, I want to see code."
As an interviewer, I get it. I expect you to know concepts, not be able to perform rote actions and put on a show.
It is a gotcha question. In fact, "log2 of 56 million" should probably be the best answer. It means you don't waste time brute forcing the problem and instead know exactly how to get the solution, but they wanted a specific answer that you compute by some heuristic. Why?
Either way, if a candidate misses such a question it shouldn't be a negative. Using such a question as a filter is a bit ridiculous.
And part of a real job involves solving real problems. In an interview, you have a very limited time, so you have to come up with questions that test the candidate's ability to solve problems within a certain timeframe.