Interview question about debugging, multithreading

Question

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.

Answer 2

One of the main reason deadlock can occur in a multi-threaded application is circular wait where two different threads holding two resources and each of them wait for the other resource. The other conditions deadlock to occur is no preemption, hold-and-wait and mutual-exclusion.

The best way to avoid deadlock is to maintain lock order. In other words let the threads able to get the lock in a particular order. This will restrict the threads to come into deadlock.