How a mobile interview is actually scored

Before any Kotlin, understand what is being measured. Almost every mobile interview scores four things, and only one of them is knowledge.

The four things

• Correctness — does your answer hold up to one follow-up question? A memorised definition collapses on the first "why".
• Judgement — can you say what you would not do, and why? "I would not rewrite the app in Compose; I would migrate screens as we touch them" scores higher than enthusiasm.
• Communication — can a tired interviewer follow you? Short sentences, one idea at a time, a concrete number when you have one.
• Ownership — did you measure something, fix it, and know the result? This is the difference between three years of experience and the same year three times.

The structure that works for any answer

Use three beats, in this order:

1. The one-line answer. "A ViewModel survives configuration change; saved state survives process death."
2. The why. One sentence of mechanism.
3. The real example. Where you hit it in your own app and what you did.

Beat three is what people skip, and it is the one that gets remembered.

What to prepare before the call

• Two numbers from your current project: a performance figure and a quality figure. Cold start, crash-free rate, ANR rate, bundle size — anything you actually moved.
• One decision you got wrong and what you changed afterwards.
• One screen you can draw the architecture of from memory.

If you can only prepare one thing, prepare the numbers. "I cut cold start from 4.2s to 2.1s" ends a round of doubt in a single sentence.