Found the Bug in Your Android Debugging Interview and Still Didn’t Pass?

The Android debugging interview looks simple on paper. You get a codebase you’ve never seen. There’s a failing test or a bug report. You have about an hour. Stripe calls its version Bug Squash. Other companies fold it into a machine coding or pairing slot. Most candidates prepare by hoping they’ll spot the bug fast. Some of them do spot it. They fix it, watch the test go green and relax. That moment is often where the round starts separating a pass from a strong pass. A well-built debugging round usually hides more than one bug. It also scores how you found the first one. So a candidate can fix the reported bug and still leave a weak signal. The traps below are specific to this round. None of them is about knowing more Kotlin.

The debugging round scores how you searched for the bug

Stripe describes the format in its Atlas guide on scaling engineering teams. It was written by Raylene Yung, who led Stripe’s global expansion. Candidate and interviewer sit side by side. They work on a real historical bug in an open-source project. The candidate picks the language and can use their own laptop. The guide carries no date. Read it as Stripe’s description at the time of writing. It isn’t a current spec.

Jake Zimmerman gives the interviewer’s side in an August 2024 post on the bug squash format. He calls it “the highest signal-to-noise software engineering interview” he has seen. His bar for passing is a repeatable, somewhat scientific method. He lists three things the interviewer watches. Is the candidate forming hypotheses about the code and testing them? Do they have good tools for finding and navigating code? Are they building a model of the whole codebase, or tracing line by line and hoping? He also notes that jumping straight to the buggy file fails. It fails even if you already knew where the bug was.

That last point changes how you should spend the first ten minutes. Run the failing test first. Read its assertion before you read any production code. Then say out loud what you think the code is supposed to do. The interviewer can’t score a hypothesis you never said.

A green test halfway through usually means a second bug

Zimmerman’s post explains why one bug is rarely the whole exercise. Some candidates find the first bug in 10 to 15 minutes. He writes that you probably need more than one bug per project. The remaining time is what tells a strong pass from an average one. So the interviewer expects your first green test around the midpoint.

A small Kotlin example shows how the second bug hides. This parser should turn a config string into a map.

fun parse(raw: String): Map<String, String> =
    raw.split(";")
        .map { it.split("=") }
        .associate { it[0] to it[1] }

A trailing semicolon crashes it with an IndexOutOfBoundsException. That failure is loud, so candidates find it first. Filtering out blank segments makes that test pass. The second bug is quieter. The input query=name=stripe splits into three parts. The parser returns name instead of name=stripe. Nothing crashes. The value is wrong. A candidate who stops at the first green test never sees it. Splitting on the first = only fixes it.

The habit to build is simple. After each fix, run the whole suite, not just the test you were chasing. Then ask what other input shapes the code can’t handle. Zero parts, one part and more parts than expected are the usual suspects.

Here’s what that sounds like on the call, using the parser.

The failing test passes a string with a trailing semicolon. It expects two entries. My guess is that the empty segment after the last semicolon breaks the split. I’ll filter out blank segments and rerun. That test is green now. Before I move on, I’ll run the whole suite. Next I’ll try a value that contains an equals sign, because splitting on every equals sign looks fragile. Yes, query=name=stripe comes back as name. I’ll split on the first equals sign only and rerun everything.

Every sentence in that script is either a hypothesis or a check. That’s the method Zimmerman describes the interviewer watching for.

Android project setup can burn the clock before you read a line

Android adds a trap most other debugging rounds don’t have. The environment can fail before the bug does. Gradle sync alone can take minutes on an unfamiliar project. Zimmerman flags this problem from the interviewer’s side. On a candidate’s older laptop, the dev loop can run 10 to 20 times slower. His fix is a sandbox repo sent before the interview. It mirrors the real build setup.

If a company sends one, build it and run its tests the day before. Don’t open it for the first time on the call. Will the round run on your own laptop? Then check Android Studio, the JDK and your emulator that morning.

The trickier version is setup that looks like the bug. The Android coroutine testing guide explains that the Main dispatcher is unavailable in local unit tests. These tests run on a local JVM, not a device. Code that touches the main thread throws an exception there. The guide also notes that viewModelScope uses a hardcoded Main dispatcher. So a ViewModel test can crash before your hypothesis about the logic even runs. Sometimes the harness is simply missing Dispatchers.setMain. Sometimes the hardcoded dispatcher is the planted bug. Say which one you think it is before you change anything. That’s a hypothesis the interviewer can score.

Your debugger is part of what’s being graded

Zimmerman writes that the format lets experienced candidates show command of their tools. His examples are strace on a Ruby program and mitmproxy on a Python server. Android has its own equivalents. Under pressure, it’s easy to fall back to print statements instead.

Concurrency bugs are where this matters most. Take a search-as-you-type ViewModel that launches a new coroutine per keystroke. Nothing cancels the old one. A slow response for “str” can land after a fast one for “stripe” and overwrite it. Log lines will show both responses arriving. They won’t show you which coroutines were alive at the time. The debugger in Android Studio and IntelliJ can. Kotlin’s coroutine debugging tutorial describes a Coroutines tab. It lists each running or suspended coroutine with its status. Seeing two search coroutines alive at once turns a guess into evidence.

The same tutorial covers a detail that trips people mid-round. With suspend functions, the debugger can mark a variable as “was optimized out.” The variable’s lifetime was shortened. Your code isn’t broken. The -Xdebug compiler option disables this. The docs warn never to use it in production. Knowing that in advance saves you a confused five minutes.

Patching until the test passes reads as guessing

The debounced-search bug has a tempting shortcut. You can tune the delays or the test timing until the stale response loses the race. The test goes green. The race is still there.

Fardeen Khimani names this failure mode in a May 2026 Built In piece on LeetCode replacements. His company sells a debugging-based assessment to employers, so he has a stake in the format. His rubric still asks the right question. It checks whether a candidate finds the root cause or keeps patching until the tests pass.

Here the root cause fits in one sentence. Completion order, not trigger order, decides which result wins. The fix is to cancel the previous Job before launching a new one. You can also mention flatMapLatest as the idiomatic Flow version. Say the one-sentence root cause out loud before you type the fix. It shows the interviewer that the fix came from a cause you found.

How to practice for the Android debugging interview

Stripe’s choice of a real historical bug points to the best practice material. Pick a merged bug-fix pull request in an open-source Android project. Google’s Now in Android sample is one option. Check out the commit before the fix. Read the issue, reproduce it and find the cause yourself. Then compare your fix with the real one. Narrate as you go, the way you would on the call.

Three habits carry over directly. Run the failing test before reading production code. Keep a short note of what you’ve ruled out, so the interviewer can follow your search. Rerun the full suite after every fix. Assume a second bug until you’ve looked for one.

If you don’t know whether your loop includes this round, ask the recruiter. Our breakdown of the three formats of the Android machine coding round covers it as one of them. It also overlaps with the log-reading drill in our Android pairing round breakdown. Prep for it with code you didn’t write. Blank-file drills don’t train any of the habits above.