App crash: debug with Logcat and breakpoints in Android Studio

WHAT THIS TESTS: This question evaluates your disciplined approach to root cause analysis under time pressure. Interviewers want to see that you move from observation to hypothesis to verification without random guessing. At the senior level, they care about tool fluency in Android Studio, specifically Logcat filtering, breakpoint strategy, and thread or variable inspection, as well as your ability to communicate a reproducible debugging workflow to junior teammates.

A GOOD ANSWER COVERS: A strong response follows a clear sequence. First, reproduce the crash consistently and capture the process ID so you can correlate Logcat output. Second, filter Logcat by your app package or by the Fatal and Exception keywords to isolate the exact stack trace and exception class. Third, scan the stack trace for the deepest frame that belongs to your source code, then set a breakpoint at that method or earlier in the call chain if the crash is a symptom rather than the cause. Fourth, launch the app in debug mode, trigger the crash, and use the Variables and Watches panes to inspect object state at the moment of failure. Fifth, use Evaluate Expression to test null checks, fallback values, or method outcomes without rebuilding. Sixth, if the issue is intermittent, mention setting conditional breakpoints or inspecting the Threads pane to detect race conditions. Finally, after applying a fix, rerun the exact reproduction steps and confirm Logcat shows no recurrence.

COMMON WRONG ANSWERS: Weak answers jump immediately to adding log statements and redeploying instead of using the debugger. Another red flag is ignoring the stack trace and guessing based on recent commits. Some candidates say they would set breakpoints but cannot explain where or how they would inspect variables. Stopping at the top line of a stack trace without navigating through frames signals shallow experience. Failing to mention thread context, or confusing debug builds with release obfuscation, also reveals gaps.

LIKELY FOLLOW-UPS: Expect the interviewer to probe deeper. They might ask how you handle a crash that only reproduces in release builds where ProGuard or R8 has obfuscated the stack trace. They could ask how you distinguish an ANR from a crash using Logcat and the CPU profiler. Another angle is debugging coroutines or background threads where the stack trace is fragmented. You might also be asked how you use the Memory Profiler when the crash is an OutOfMemoryError, or how you leverage Drop Frame and Force Return during a debug session.

ONE CONCRETE EXAMPLE: Imagine a NullPointerException when tapping a notification to open a chat thread. The candidate filters Logcat by package:mine and Fatal, sees the NPE at line 38 of ChatActivity. They set a breakpoint at line 38 and another in the Intent parsing logic above it. In debug mode, the Variables pane shows extras.getString returns null because the key changed in the push payload. Using Evaluate Expression, the candidate confirms a safe default prevents the crash. They apply the fix, rerun the notification tap flow, and verify Logcat is clean.