2

I am having a debugging test, as part of an interview.. I thought if any one can help with the approach, when I am faced with a large code base and have to find bugs inside that within an hour or two.This is going to be Core java based app (I guess) on Eclipse 3.2+

flash
  • 1,231
  • 4
  • 19
  • 23
  • do you know java? Can you debug code already? do you use an IDE? – Mitch Wheat May 05 '10 at 04:06
  • yes, I do know java, I do coding and debugging as part of my current job.. – flash May 05 '10 at 04:15
  • 1
    "When you have decided which answer is the most helpful to you, mark it as the accepted answer by clicking on the check box outline to the left of the answer. This lets other people know that you have received a good answer to your question. Doing this is helpful because it shows other people that you're getting value from the community. (If you don't do this, people will often politely ask you to go back and accept answers for more of your questions!)" let me fix that!! – flash May 05 '10 at 04:19

4 Answers4

2

Not a complete answer, but you can brush up techniques for remote debugging as well

alt text

It can help for finding bugs when you don't have a full Eclipse project, but ony an external application (with its sources) that crashes.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
2

I hate to say this, but if you don't know how to approach this problem already, there is a good chance that you do not have the level of experience / expertise that they need. Trying to learn between now and the interview is probably not going to help a great deal.

On the positive side, you've already reached the detailed interviewing stage, and that is a good sign. And despite your concerns, you may well already meet their minimum level of experience / skills in debugging ... or your other attributes may sufficient to get you the job.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
2

The answer the interviewer is likely watching for is "what is your overall strategy?" You better have an approach that makes sense to him or her. This is the overall approach I recommend for debugging (regardless of if it's for a test):

  1. Recreate the bug, documenting additional findings as you go along.
  2. Bonus points for writing a unit test to automatically recreate the bug.
  3. Categorize the bug - is it a crash, or incorrect behavior? Your analysis will likely be different.
  4. Crank up the debug/logging level as detailed as it will go.
  5. Look for log files/artifacts that the app may have generated to help pinpoint the fault.
  6. Do an initial skim through the likely code, looking for anything suspicious.
  7. Take a divide and conquer approach. Use a rough binary search to identify where the code works, and where it fails. Maybe use breakpoints or print statements.
  8. After you find it, add unit test cases to narrow it down explicitly.
  9. Add documentation to explain what you found, comments in the unit test code would be great.
  10. Fix the bug. Comments regarding the fix would also be good.
  11. TEST YOUR FIX. Test it in a logical, methodical manner (boundary conditions, etc.)
  12. When done, ask the interviewer to do a code review of your bug fix solution.
John Deters
  • 4,295
  • 25
  • 41
  • Great !!! Now this added many points to what I do in my day's job, if not for the interview it will add up to my process of debugging. – flash May 05 '10 at 10:08
0

Let me know how it goes. Sounds difficult. I guess I would say make sure you know how to get a stacktrace off the top of your head.

patrick
  • 16,091
  • 29
  • 100
  • 164
  • It went fine,there were four functionalities , fixed handful of issues.. idea of documenting what I did, Why and commenting the code at appropriate places helped! thanks Jadeters – flash May 06 '10 at 18:31
  • Woo hoo! Glad to be of assistance. – John Deters May 18 '10 at 04:43