Why the Android Pairing Round Interviewer Keeps Changing the Requirements

In an Android pairing round, the interviewer may change the requirements halfway through on purpose. The round isn’t grading your first design. It’s grading what happens to that design when the target moves. Candidates who prepare for it like an algorithm round get caught out. They build the fastest thing that works, then have to rewrite it when a new requirement lands. The stronger approach has three parts. Ask a few more questions before you start. Build with one seam where change is likely. An interface in front of the data source is a common choice. Then narrate how you absorb the change when it comes. Some versions of this round skip new code entirely. They hand you logs or a stack trace to debug cold. Below is one requirement change, handled live, with what to say. After it comes how to practice the log-reading version.

Candidate accounts show requirements changing mid-build

Companies rarely publish how this round works, so candidate accounts are the best evidence. Ahmad Kaddour described a Google Android L4 loop in an April 2025 post. He calls it the mobile domain round. The interviewer gave him a feature set and asked him to design the front end. He analyzed requirements, proposed a design and explained his thinking as he coded. Later the interviewer added new requirements. He handled them easily, he wrote, because his first design was flexible. The one critique was that he hadn’t asked many out-of-the-box questions.

That’s one person’s loop, not a published rubric. But the shape is clear. The change was part of the round. The design choice made before it decided how the change went.

The example: a requirement change in an Android pairing round

Say the brief is a screen that shows a list of saved articles from a local database. You build a ViewModel that reads directly from a Room DAO. Twenty minutes in, the interviewer adds a requirement. Articles should also sync from a server. The list should work offline.

If the ViewModel talks straight to the DAO, the change means rewiring the ViewModel and its tests. Suppose you put a repository interface in front of the data source at the start. Then you add a network source behind it. The ViewModel barely changes. Here’s how the strong version sounds when the change lands.

Okay, so now we have a remote source too. The ViewModel only knows about ArticleRepository, so I don’t need to touch it. I’ll add a remote data source and have the repository read from Room as the source of truth. It’ll refresh from the network in the background. Offline, the list still shows what’s in the database. One question first. When the server and local copy disagree, which one wins? I’ll assume the server does, unless the user has edited an article locally.

That answer shows the seam paying off. It shows the plan for the new source and a clarifying question about the one decision that matters. The code details are illustrative.

A seam, not a framework

The seam is small. It’s one interface and a class behind it. It isn’t a module for every layer or a DI graph for a two-screen app. Our post on the Android take-home assignment covers the same balance. Build what the problem needs. Then explain why. The difference in a pairing round is timing. You make the call before you’ve seen the full brief. Then you defend it live when the brief changes.

A good rule is to put the seam where change is most likely. In mobile apps that’s often the data source. Screens that start local often gain a network later. Screens that start online often need offline support.

Some versions hand you someone else’s logs

Another version tests reading instead of writing. Sharib Khan described a Google Android L4 loop in a February 2025 post. His Android domain round covered architecture, coroutines and memory management. Then the interviewer gave him a log file and asked debugging questions about it.

Reading someone else’s evidence cold is a different skill from writing code on a blank file. It rewards a narrated hypothesis. Say what the log rules out before you guess what it confirms. Pattern-matching silently against a bug you’ve memorized gives the interviewer nothing to score.

How to practice for the Android pairing round

• Run a mock with a real second person. Have them hand you a small feature brief. Ten or fifteen minutes in, they change one requirement on purpose. Solo practice never rehearses that moment.
• Before you code, ask two or three questions about where the feature might grow. Then put your seam there.
• Practice cold reads. Take a stack trace or logcat dump from an open-source issue you haven’t seen. Narrate your hypotheses out loud before you look at the fix.
• Ask your recruiter whether the loop has a live-build or domain round. Ask how long it runs. Then prepare for it separately from the algorithm round.