Interview question about debugging, multithreading

Question

Hi I had telephone interview question yesterday. The interviewer asked me if I had faced any challenging debugging issue? I told him I once faced a problem debugging someone else's code and it took me 3-4 days to solve that. I used Windbg, symbols and a crash dump to solve the problem.

Now is this enough to tell? What is interviewer expecting?

I don't know what else to tell, I faced that problem quite some time back and can't explain all details...

This question is very very common and I am not sure what the right answer to it?

One more question that is very common:

Have you worked on multi-threaded applications? How can you find out deadlock? Answer: Well to find deadlock we can look at snapshot of process in memory and can look at threads that are waiting.

Then next question: What can you do to avoid deadlock?

1. Use waitformultipleobjects
2. Maintain sequence of critical sections

What do you guys say?

Answer 1

The general rule for interviews is to use the STAR model (my co-op coordinator is going to be proud here...):

S - Describe the situation you were in
T - Explain the task, providing enough info so that the interviewer understands the problem.
A - Describe the action you took to solve the problem.
R - What were the results of your actions

If you provide a concise answer, not too short or too long, 99.9%* of interviewers will be satisfied.

*The other .01% are hummer owners and are never satisfied. :D

Answer 2

Interview questions (well, the good ones at least) are not concerned about you telling the knowledge you have, its explaining to the interviewer's satisfaction that you actually do know it.

So, whilst you could explain the full intricacies of windbg, he won't care. He will care that you know what to do and believes you. You only have to supply enough information to satisfy that. The alternative is to actually debug something in front of him to prove it and interviews never last that long :)

So I think (from what you've said) that you know what you're talking about, that you do have that experience, that you could do it again. So lets move on to the next question to find out a little more about what else you know.

Sometimes you many answer in a way that's a bit ambiguous, no problem - we'll just ask another one and another until we find out whether we think you're good enough for the role, or not.

Interviews are only like exams in that its your working the interviewer is interested in, not the result.