Approaching an Unfamiliar Bug
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
When I encounter a bug I've never seen before, I follow a systematic five-step process.
First, I reproduce the bug reliably. I'll create a test case or document the exact steps to trigger it consistently. If I can't reproduce it, I can't verify whether my fix works.
Second, I read the complete error message and stack trace carefully. Freshers often just look at the first line, but the full stack trace shows the call sequence and often reveals that the root cause is several methods upstream from where the exception was thrown. Third, I isolate the failing code.
I use binary search debugging—commenting out or disabling half the code to see if the bug disappears, then narrowing down further until I find the exact problematic section. Fourth, I check recent changes using version control. I'll run git log or git diff to see what code changed recently, because many bugs are introduced by recent commits.
Looking at what changed often points directly to the problem. Fifth, I trace execution flow using logging or the debugger. I'll add log statements at key points to see what code path actually executes and what variable values are at the point of failure.
Often the bug becomes obvious once I see the actual data versus what I expected. Throughout this process, I make one change at a time and retest, so I know exactly what effect each change has. This systematic approach prevents me from randomly modifying code hoping something works, which is the fastest way to make bugs worse.
Approaching an Unfamiliar Bug
Direct Answer
Start by reproducing the bug with consistent steps or inputs. Read the full error message and stack trace carefully to understand what failed and where. Isolate the failing code by narrowing down which module or method is responsible. Check recent code changes using version control. Use logging or a debugger to trace execution and inspect variable values at the point of failure.
Code Example
// Bug report: GET /orders/{id} returns 500 Internal Server Error
@RestController
class OrderController {
private static final Logger log = LoggerFactory.getLogger(OrderController.class);
private final OrderService orderService;
@GetMapping("/orders/{id}")
public ResponseEntity<Order> getOrder(@PathVariable Long id) {
// Step 1: Add logging to reproduce and trace execution
log.info("Received request for order ID: {}", id);
try {
// Step 2: Isolate - check if service call is the problem
var order = orderService.findById(id);
log.debug("Service returned order: {}", order);
// Step 3: Check assumptions - is order ever null?
if (order == null) {
log.warn("Service returned null for order ID: {}", id);
return ResponseEntity.notFound().build();
}
return ResponseEntity.ok(order);
} catch (Exception e) {
// Step 4: Log full exception details to understand the failure
log.error("Failed to retrieve order: {}", id, e);
throw e;
}
}
}
Common Mistakes & Pitfalls
- Changing code before reproducing: Freshers read a bug report and immediately start modifying code without first creating reliable steps to trigger the bug, making it impossible to verify whether changes fix anything.
- Only reading the first stack trace line: Developers glance at the exception message and line number without reading the full stack trace, missing that the root cause is several method calls upstream.
- Making multiple changes simultaneously: Freshers modify three things at once then can't determine which change fixed the bug or whether the combination introduced new problems.
- Ignoring version control: Junior developers don't check git log to see what changed recently, missing that a commit from yesterday introduced the bug—the diff reveals exactly what went wrong.
Check your understanding
Answer these without looking back at the article.
- How would you debug a bug that only appears in production and not locally?
- What tools would you use to debug a memory leak in a Java application?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.