A correct Android answer can still fail the interview

Take a question that appears in nearly every senior Android loop.

How would you handle a long-running operation that needs to survive configuration change?

Here is a correct answer.

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.

Everything in that is true. Nothing is missing. A junior engineer could not produce it.

Here is a different answer.

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.

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.

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.

Same knowledge. Same engineer, plausibly. The second answer will be recorded differently, and the reason is not that it is longer.

The interviewer is not checking whether you know what viewModelScope does. They found that out in the first sentence.

They are trying to establish something harder: whether you can be trusted with a decision when nobody has specified the requirements.

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.

The first response above says: I know the API.

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.

Only one of those can be written down as evidence of judgement.

Three things separate the two answers, and they generalise to every question in a senior loop.

A goal is not a trade-off.

The most common weakness in senior answers is naming a benefit and calling it a reason.

We used Room because it gives us type safety and compile-time verification of queries.

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.

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.

Same choice. The second version contains a cost, so it reads as something that was actually decided rather than something that was defaulted to.

If your answer contains no cost, you have not finished answering. Senior interviews are about risk, not vocabulary.

The question after the answer is the real question.

Correct answers are the entry fee. What happens when the interviewer pushes back is the score.

Interviewer: You said you would collect the flow in the composable. What happens to that collection when the app goes to the background?

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 nobody can see, is demonstrating that they know why the API exists rather than that they know it exists.

Most preparation stops at the first answer. Almost all of the differentiation happens after it.

Production leaves marks.

There is a texture to answers from people who have shipped and been paged, and interviewers recognise it without being able to name it.

It sounds like: we did that and it was fine until the fleet included some very old devices. Or: that worked, and then we found out the hard way that our assumption about ordering was wrong on one carrier's network.

You cannot fabricate that texture, and you do not need to fabricate it if you have shipped anything. What most candidates do is edit it out, because they think the interview wants clean answers. It does not. The scars are the evidence.

Why is it a mistake to hold a Context in a long-lived object?

The surface answer is memory leaks. What is being tested is whether you can distinguish an Activity Context from an application Context, say which one is safe to retain and why, and then name the case where using the application Context silently breaks things, which is anything that needs a themed or UI-bound Context. The mistake and the naive fix are both part of the answer.

What happens to a coroutine when its scope is cancelled?

The surface answer is that it stops. What is being tested is whether you know cancellation is cooperative, that a block doing tight non-suspending work will not stop on its own, and what you do about it. The follow-up will be about cleanup, and the good answer names the trap: your finally block cannot suspend in a cancelled scope unless you handle it deliberately. The same class of bug survives Swift code review.

How do you decide what belongs in the ViewModel?

There is no correct answer, which is the point. It is testing whether you have a rule or a habit. The strong version is a rule with a boundary and a case where you would break it. The weak version is a description of what you usually do.

If you have three days rather than three months, this is where the return is.

Take your three strongest pieces of work and write down what each one cost. Not what went well. What you gave up, and who was affected beyond your own team. If a story does not contain a cost, it is not ready to tell.

Practise the second answer, not the first. For every question you can answer, write the follow-up you would ask if you were the interviewer, then answer that too. The follow-up is where the round is decided and almost nobody rehearses it.

Learn to ask before you answer. Not performatively, and not for every question. But when a question contains a word doing a lot of work, survive, scale, handle, optimise, the clarification is part of the answer and it is being scored.

And stop editing out the mess. The time something did not work, and what you learned from it, is more convincing than a clean story, and it is the thing that cannot be memorised from a question bank.

Correct is the floor. The interview measures what you built on top of it.