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?
- Use waitformultipleobjects
- Maintain sequence of critical sections
What do you guys say?
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.