If I were asking this question, I'd be looking for a higher level answer. A "bug" is a gap between what you think the program is doing and what it is actually doing. A primary tool to finding a bug is the scientific method. Perform experiments using debuggers, logs, code modifications, whatever until you can make a theory about what is going on. Then test that theory using as many cases as you can, again using whatever tools make sense. Repeat until you can't disprove a theory. Once you know what is going on, make the relavent changes and then test your fix.
What tools are involved varies depending on the bug and the environment. Getting an answer of "a debugger" when asking "how do you find debug a program?" puts me off big time. It's like answering "by using an editor" when asked how you write software. A debugger is a tool, and like all tools in the industry, it will vary in quality, and might not even exist. "Visual Studio" only works if you're looking at a Microsoft shop. Will you be paralyzed if the problem only manifests itself in release mode, on a physical device that doesn't allow debugger attachments?
The other thing I would be looking for as an interviewer is questions about the issue that show you have knowledge about what to look for given certain conditions. What is your approach if the system freezes in an app with multiple threads? What is your approach when you have different behavior in release and debug mode? What is your approach when you have a random crash that can't be tied to a particular line of code? What is your approach to trace a memory leak?
Answers should mention tools in all of these cases of course, but the tools are secondary to the process.
I don't think this question is too vague at all. When I interview, I love questions like this, because they can often result into deep conversations about software engineering process. When that happens, you know you've got the right person. There's no such thing as a "complete" answer or a "right" answer. The point is not to get the question right but to use the question as a springboard to show your abilities. As an interviewer, am more interested in giving you these opportunities than I am knowing that you can parrot back a "correct" answer.