Well one of the points of an interview is to see how (or if) the person goes about understanding problems the context of a given problem. So presumably it's unclear to inverse a binary tree to you - that's why you ask clarifying questions. Perhaps you draw what you think it means and ask if that's correct. What will be considered the root if it's just a matter of reversing the direction of the pointers? Stuff like that. Google isn't dumb, and I'd be willing to bet that it's questions like those that are just as important than coding the solution (since it won't be that hard once you clarify the problem).

Here's an example to think about: You're asked to write a method that, given a word and a book, will return the number of times that word appears in the book. A logical way to continue would be to (after clarifying what a book is represented as and things like that) write a simple method that iterates over the book and counts how many occurrences of the words there are, and returns that. Is that a good answer? No, because you failed to ask questions like whether the method might be called many times for the same book (in which case it'd be better to build a map of words to occurrences). Or maybe the interviewer would say that it'd only be called once per book, in which your solution is perfect. The bottom line is that coding isn't as important as the way you approach the problem to the interviewer.

The best analogy I've heard for this: If you wanted to judge whether a person was a good chess or card player by seeing just a couple moves or hands - you wouldn't just look at the couple moves/hands played - it'd give you very little information. But if you asked the player to explain their whole thought process for the moves/hands, you'd get a much better indication of how good or mediocre that player was.