I think Andreas's answer is on point, but you need to know the inner workings of a binary tree and linked list to appreciate it. Seems this is what the interviewer is quizzing you on: do you know what he's talking about when he brings up the structure, and can you comfortably walk through it to derive a reasonable answer?
Another way to think about the question is to shift the focus on the balanced tree. What makes it balanced? For each level, the height of the left subtree is the same as the right one, so every root at that level has either two nodes or one node. An unbalanced one is the opposite.
Now that you understand what an unbalanced vs balanced tree looks like, you can start comparing their implementations. What is the implementation for binary search? You keep halving the tree until the target is located. As a pattern, every time you deal with a problem that involves halving the amount of inputs, that's log(N), since we're working with base of x,
log(aN) = x => a^x = N
So the worst case runtime of a balanced search tree is O(log(N)), where the target is either not found or at the very last position, you're halving N inputs (log(N)).
For the unbalanced search tree, the worst case scenario is the same where the target is not found or at the very last position, but because the tree is unbalanced, instead of halving, you're going through every item in a linear way. Therefore, the runtime is O(N).
What does the runtime of the unbalanced tree mean in relation to the balanced tree? If you consider the runtime order, O(N) is slower than O(logN), which is why a balanced tree is usually the better structure.