{"id":718,"date":"2026-10-01T09:50:00","date_gmt":"2026-10-01T07:50:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=718"},"modified":"2026-09-30T23:09:54","modified_gmt":"2026-09-30T21:09:54","slug":"android-code-review-interview","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/android-code-review-interview\/","title":{"rendered":"How to Pass the Android Code Review Interview When the Bugs Are Planted"},"content":{"rendered":"

An Android code review interview gives you a pull request someone else wrote. You read it, comment on it and defend your comments. The interviewer already knows every issue in it, because the issues were planted. So the round mostly scores how you rank them and explain them. Can you tell a crash from a naming nit? Can you say why each problem matters to a user? A common way to fail is a long list of correct comments in file order. The lifecycle crash gets the same weight as a log tag. Nothing says which comment blocks the merge. The fix is to review the way a senior engineer does at work. Read the whole change first. Rank the issues by what breaks for the user. Label each comment’s severity. Then write a short summary that says what must change before merge. Below is one sample pull request, a ranked review of it and the summary to adapt.<\/p>\n

The Android code review interview hands you planted problems<\/h2>\n

Companies run this round in two main shapes. GitLab’s is asynchronous first. Its technical interview guide<\/a> sends candidates a merge request at least 72 hours before the call. It suggests spending up to an hour reviewing it, as you would any contribution. Then a 90-minute call follows. You walk the interviewers through your review and write code to improve the change. GitLab says the round looks at how you communicate asynchronously, what you know and how you collaborate.<\/p>\n

Ataccama, a data software company, runs the other shape. Two of its engineering leads described it in a May 2022 post on its hiring blog<\/a>. Candidates review prepared code that has both basic and harder issues. Every candidate gets the same code, so the interviewers know where the problems are. They steer the call to the areas with the most room for improvement.<\/p>\n

Because the interviewer knows the answers, they aren’t hoping you find something new. They’re watching how you treat problems they already ranked. Exponent sells interview prep. It interviewed an Airbnb engineer who helped build that company’s round. Its guide to the code review interview<\/a> reports what that engineer said. The score doesn’t come from how many issues you find. It comes from how clearly you raise each one and how deep you go. That’s one interviewer’s account of one company. The GitLab and Ataccama formats point the same way.<\/p>\n

One sample pull request with four planted issues<\/h2>\n

Here’s a change of the kind an Android round might use. It adds a profile screen that loads from the network. It compiles and the happy path works.<\/p>\n

class ProfileFragment : Fragment(R.layout.fragment_profile) {\n    private val viewModel: ProfileViewModel by viewModels()\n\n    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {\n        lifecycleScope.launch {\n            viewModel.profile.collect { profile ->\n                if (profile != null) render(profile)\n            }\n        }\n        viewModel.refresh()\n    }\n}\n\nclass ProfileViewModel(private val api: ProfileApi) : ViewModel() {\n    val profile = MutableStateFlow<Profile?>(null)\n\n    fun refresh() {\n        viewModelScope.launch {\n            try {\n                profile.value = api.fetchProfile()\n            } catch (e: Exception) {\n                Log.e("ProfileVM", "fetch failed", e)\n            }\n        }\n    }\n}<\/pre>\n
Four problems are planted here. The Fragment collects the flow with a plain launch<\/code>. The catch<\/code> block hides every failure from the user. The ViewModel exposes a mutable flow. And the log tag is a string literal. There’s also no test for the failure path. Listed in file order, they all look equally important. Nothing tells the author that one can crash the app and another is cosmetic.<\/p>\n
Rank each issue by what breaks for the user<\/h2>\n
Before you write a comment, sort the issues by harm. Ask one question of each. What does a user see if this ships? The answers give a clear order for this pull request.<\/p>\n
The collection bug comes first. Android’s StateFlow and SharedFlow guide<\/a> warns against collecting a flow from the UI with launch<\/code> alone. Such a collector keeps processing events when the view isn’t visible. The guide says this can crash the app. Its fix is repeatOnLifecycle<\/code>. There’s a second layer in a Fragment. The Fragment lifecycle guide<\/a> says the view has its own lifecycle, separate from the Fragment’s. Work that touches the view belongs to viewLifecycleOwner<\/code>. This code uses the Fragment’s scope. So render()<\/code> can run after the view is gone.<\/p>\n
The swallowed failure comes second. We ran a plain Kotlin version of this ViewModel with the fetch forced to throw IOException<\/code>. The error was logged and profile<\/code> stayed null<\/code>. The screen has no error state, so the user sees an empty screen with no retry. The same run showed a second effect. Canceling the scope mid-fetch logged JobCancellationException<\/code> as a failure. Android’s coroutines best practices<\/a> page says not to consume CancellationException<\/code>. It suggests catching specific types like IOException<\/code> instead of Exception<\/code>.<\/p>\n
The mutable flow comes third. Nothing breaks today. But any class can write to profile<\/code>. In our run, an outside write went straight through. The same best practices page recommends a private MutableStateFlow<\/code> behind a public StateFlow<\/code>. That keeps every state change in one class. The log tag comes last. It’s a style point.<\/p>\n
Google’s public, undated guide to writing review comments<\/a> gives you the labels. It suggests marking minor points “Nit:”, optional ideas “Optional:” and future notes “FYI:”. Without labels, it says, authors may treat every comment as mandatory. In an interview, labels show the interviewer your ranking without a speech.<\/p>\n
A sample review summary for this pull request<\/h2>\n
GitLab’s format asks for a written review before the call. Even in a live round, open with a summary like this before any line comment. Adapt it to the change you get.<\/p>\n
Summary: The loading path works. Two issues block the merge.\nOne should be fixed soon, and one is a nit.\n\nBlocking\n1. ProfileFragment collects the flow with lifecycleScope.launch.\n   It keeps collecting while the view is stopped, and it uses the\n   Fragment's lifecycle, not the view's. render() can run after the\n   view is destroyed. Suggest viewLifecycleOwner.lifecycleScope with\n   repeatOnLifecycle(STARTED).\n2. refresh() catches Exception and only logs it. On a network error\n   the user gets a blank screen with no retry. It also catches\n   cancellation. Suggest catching IOException and exposing an\n   Error state the screen can render.\n\nShould fix\n3. profile is a public MutableStateFlow, so any caller can change\n   screen state. Suggest a private _profile and a public StateFlow.\n\nNit\n4. Move the \"ProfileVM\" tag to a constant.\n\nTests: I'd add a ViewModel test with a fake ProfileApi that throws\nIOException, and assert the Error state.\n\nQuestion: is a null profile meant to show a loading state? If so,\na sealed UiState would make that explicit.<\/pre>\n
The first line gives a verdict and a count. The interviewer knows your ranking before reading any detail. Each blocking item says what goes wrong for the user, then suggests a fix. It doesn’t write the whole fix. Google’s guide says fixing the change is the author’s job. It asks reviewers to balance pointing out problems with direct guidance. The test line shows how you’d prove the fix. The closing question checks intent instead of assuming a bug. The fix for item 1 is short enough to show in the call:<\/p>\n
viewLifecycleOwner.lifecycleScope.launch {\n    viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {\n        viewModel.profile.collect { profile ->\n            if (profile != null) render(profile)\n        }\n    }\n}<\/pre>\n
When the interviewer points at a missed issue, your reply is scored<\/h2>\n
Suppose you missed the mutable flow. The interviewer points at it. What you do next is scored too. The Ataccama leads say they deliberately look for something the candidate missed and watch the reaction. A self-described expert who brushes off an obvious miss is a bad sign to them. Saying “I missed that” reads as honest.<\/p>\n
So say it plainly. Then rank the new issue against your list. “I missed that. It’s not blocking, because nothing writes to it yet. I’d put it under should-fix, after the catch block.” That answer admits the miss and still shows judgment.<\/p>\n
The same leads describe a second probe. When a candidate suggests a change, they ask why. They say “because I’m used to it” is a fine answer from a junior engineer. From someone with 12 or more years of experience, they expect an opinion with reasons. For this pull request, that means knowing why repeatOnLifecycle<\/code> matters. It stops collection when the screen stops and restarts it when the screen comes back.<\/p>\n
Practice on real pull requests, then rank before you type<\/h2>\n
Reading code you didn’t write is the skill here. Our post on the three formats of the Android machine coding round<\/a> covers reading a codebase cold. The code review round adds the ranking step. Try this drill once or twice a week.<\/p>\n