A correct Android answer can still fail the interview | SalariSkip to contentStartStart hereWhy you didn't get the offerFree guide, 34 pages<br>Books1Writing2ToolsLineUp CVCV, job matching, cover letter and LinkedIn headline.ATS Resume ScannerEngineer Visibility ScoreView all tools<br>ServicesThe BriefAboutFind my path<br>The most frustrating rejection is the one where you answered everything correctly.<br>You knew the material. Nothing was wrong. The feedback, if it comes at all, is some version of we went with someone more senior, and you spend the next month wondering what more senior means when your answers were right.<br>Here is what it usually means, and it has almost nothing to do with knowledge.

Two answers to the same question<br>Take a question that appears in nearly every senior Android loop.<br>How would you handle a long-running operation that needs to survive configuration change?<br>Here is a correct answer.<br>I would put it in a ViewModel and launch it in viewModelScope. That way it survives rotation, because the ViewModel outlives the Activity, and it gets cancelled automatically when the ViewModel clears.<br>Everything in that is true. Nothing is missing. A junior engineer could not produce it.<br>Here is a different answer.<br>First I would want to know what survive means here, because there are two different requirements hiding in that word. If it needs to survive rotation, viewModelScope is right, and the automatic cancellation on clear is the reason to use it rather than a custom scope.<br>But if it needs to survive the user backgrounding the app or the process being killed, then the ViewModel is the wrong place entirely. A ViewModel survives configuration changes, but it is cleared when its owner is permanently finished, and process death removes the entire in-memory model regardless. If the work is deferrable and can run under scheduled background constraints, that points toward WorkManager, and the cost is that we give up immediacy and observability for durability. If it is immediate and user-visible, it points toward a foreground service or a server-side operation we can recover from.<br>Which one are we talking about? Most of the time when people say survive configuration change, they mean the first, and the second is the one that bites in production.<br>Same knowledge. Same engineer, plausibly. The second answer will be recorded differently, and the reason is not that it is longer.

What the interviewer is doing<br>The interviewer is not checking whether you know what viewModelScope does. They found that out in the first sentence.<br>They are trying to establish something harder: whether you can be trusted with a decision when nobody has specified the requirements.<br>That is the actual difference between the levels. Mid-level engineers are given problems that are already scoped. Senior engineers are given ambiguity and expected to resolve it before writing anything. The interview is a compressed simulation of that, and answering a slightly ambiguous question decisively without noticing the ambiguity is a signal, whether or not the answer was right.<br>The first response above says: I know the API.<br>The second says: I noticed the question was underspecified, I know which two things it could mean, I know the failure mode of getting it wrong, and I know what each option costs.<br>Only one of those can be written down as evidence of judgement.

The pattern underneath<br>Three things separate the two answers, and they generalise to every question in a senior loop.<br>A goal is not a trade-off.<br>The most common weakness in senior answers is naming a benefit and calling it a reason.<br>We used Room because it gives us type safety and compile-time verification of queries.<br>True, and it argues for nothing, because nobody is advocating for runtime SQL errors. A benefit is a wish. What makes it a decision is what you gave up.<br>We used Room, which cost us the flexibility of raw SQL for a couple of reporting queries where we ended up writing them by hand anyway. Worth it, because the schema was changing weekly and compile-time verification caught migration mistakes that would otherwise have shipped.<br>Same choice. The second version contains a cost, so it reads as something that was actually decided rather than something that was defaulted to.<br>If your answer contains no cost, you have not finished answering. Senior interviews are about risk, not vocabulary.<br>The question after the answer is the real question.<br>Correct answers are the entry fee. What happens when the interviewer pushes back is the score.<br>Interviewer: You said you would collect the flow in the composable. What happens to that collection when the app goes to the background?<br>The candidate who says they would use repeatOnLifecycle or collectAsStateWithLifecycle has answered. The candidate who says they would use it and explains what breaks without it, that collecting without lifecycle-aware suspension can keep upstream work active while the UI is not visible, holding resources and processing updates...