The senior Android system design round tests whether you can reason about trade-offs, not whether you know APIs. Junior rounds ask you to define a ViewModel or explain the Activity lifecycle. The senior round hands you a scenario and asks how you’d structure it. Most prepared candidates reach the correct answer. What separates a strong answer is the next step. Name what your solution costs, when that cost matters and why you’d accept it for this screen. So practice every solution with one extra question. What am I giving up? Would I make the same call with different constraints? Then say that reasoning out loud in the round. A trade-off you can defend under follow-up questions beats a rehearsed list. Below is one common prompt with the correct answer and the strong answer side by side. Then the same move is applied to two other prompts.<\/p>\n
Here’s a typical senior prompt. A screen collects a StateFlow from a ViewModel. The underlying data changes often. Some of the transformations are expensive. The user moves between screens repeatedly. Structure it so the app doesn’t do unnecessary work.<\/p>\n
The correct answer is to expose the state with The strong answer keeps going. Here’s how it might sound in the round.<\/p>\n I’d use stateIn with WhileSubscribed and a five-second timeout. That keeps the upstream alive through configuration changes and quick navigation. But the timeout is a trade-off. If the user comes back within five seconds, nothing reruns. That’s what we want. If they come back after it expires, the expensive work restarts. For this screen I’d want to know how expensive that is. If it’s a few milliseconds, five seconds is fine. If it’s a network call plus a heavy transform, I’d cache the result in the repository. Or I’d keep the flow warm longer. I wouldn’t reach for Eagerly by default. That keeps the work running even when nobody is watching.<\/p>\n<\/blockquote>\n The correct answer describes a solution. The strong answer describes the trade-off and the reasoning that picked one side of it. It also invites the follow-up the interviewer wants to ask. Our post on SharingStarted.Lazily vs Eagerly<\/a> covers the other strategies in more depth.<\/p>\n Another common prompt is about poor connectivity. The app is fast on good networks and slow on bad ones. Design the data layer so cached data shows immediately while the server syncs in the background.<\/p>\nstateIn<\/code> and SharingStarted.WhileSubscribed<\/code>, with a timeout. Android’s own guide to UI state production<\/a> shows this pattern with a 5-second timeout. The guide also recommends starting the pipeline lazily, only when there’s a consumer, to save resources. Most senior candidates who have read the docs get here.<\/p>\nThe strong answer names what the timeout costs<\/h2>\n
\n
The same move on an offline-first prompt<\/h2>\n