The answer to such a vague question can never be complete.

This sounds like one of those questions that was designed to be vague on purpose: I think you should have avoided excessive waffle and asked them to narrow the focus of the question. As you mentioned, you first classify errors into syntax and semantics, then you branch your answer from there – but since you already assumed they wanted you to discuss both in depth, you simply carried on talking.

Yes, what you have said is fine, but no-one here will be able to tell you if you answered the interview question.

Personally, I would approached by returning a question “why kind of C++ issue am I debugging?” (Segmentation Fault is very different to Unexpected ... as you know, but you should always make clear your assumptions in an interview) and taken it from there, once the question is narrowed enough that I would be able to answer it precisely and largely in entirety. Think of it like this: imagine they’ve just said to you “my car doesn’t work, can you tell me why?”. Would you really start trying to answer with so little information?

As an interviewer who asks very similar question frequently, maybe I can shed some light.

First of all, in interviews, there are often two types of questions: (1) prove that you know something (practically speaking, these have fairly clear “right” and “wrong” answers), and (2) pop open your skull and show me how your mind works (these have many more shades of gray, and many very different answers can all be good). I try to make sure interviewees know when I’m not looking for the “right” answer and just want to know how they think. For me, this question is in the second category.

Think back, was the question “How do you debug a C++ program?” or “How can a C++ program be debugged?”, because the answer you provided was for the second question. In general, in interviews we want to hear the general (i.e., there are release and debug versions of the code) and then we want to hear about how you personally used that (i.e., “on project XYZ the Shroozlebob class wasn’t initializing properly, so I loaded the debug version of the code into the debugger and…”). Of course, if I got an answer like yours, I would’ve started asking for examples. I don’t expect interviewees to be knowledgeable at being interviewing; I expect them to be knowledgeable programmers.

For me, there is no one right answer to this question, although some answers are better than others. If you gave me your answer, and I asked for examples and you couldn’t provide any, I would have to assume that you don’t have very much real debugging experience. But if you gave me good examples of what you mentioned, then that would be a good answer.

I respectfully disagree with @mh. This is not a trick question. I am guessing this was an attempt to start a discussion about debugging and the development process in general.

Your answer is a good starting point, especially the part about assertions and exceptions. But you could have dug deeper. Do you write unit tests? If not, then you should. Was the bug caught by a unit test? If not, then you need to add a new test for it. Do you use a version control system? (Again, you should.) If so, then you should check the recent commit log to see which change could have caused the bug. You may want to try to reproduce the bug in previous versions to find the exact point in time when the bug was introduced.

Is your code clean? (See “Clean Code” by Robert C. Martin). If you have small classes and functions with descriptive names and obvious purpose, then you might be able to find the bug just by looking at the code. If not, then this might be a good time to refactor the part of the code in question to make it more clear and less error-prone.

By the way, you literally should ask the interviewer those questions about version control and unit tests. The interview is as much about you evaluating them as them evaluating you.

There is a case you missed. While the program may not give an error, there can be cases where a requirement was misinterpreted and thus the software has to be changed to reflect this. The compiler won’t throw any exception because as far as the program is concerned, nothing wrong is happening.

While I’d also start with various kinds of bugs, compile-time, run-time, and changing requirements, I’d then drill into the question of what kind of bug am I facing? Is this an issue in the code, data, or infrastructure? There are more than a few places that could be the source. I’d probably add that I’d look into the tests written for the program to see if this was covered somewhere or was missed.

I’d say it’s not complete, but certainly acceptable for a junior position. The most powerful debugging tool is to understand the code and to be able to reason correctly about what it is doing versus what it should be doing. This is aspirational though, and we all fall short. We always end up debugging code we’ve never seen before. A debugger is great for that. I’d also have talked about building a logging facility into your applications, and writing good documentation and clear code. It would also have been good to mention tools like Valgrind, systrace, and gprof or the Windows or Java equivalents.

That sounds an awful lot like a semi-trick question to me – designed to catch you out and trap you into giving an overly complex answer when a simpler one would do.

You find out what the problem is, get a repro case, use a debugger, regression test when done; simple as that.

Your own answer touches on much of this so it may be acceptable.

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.