The algorithm round in an Android loop tests one thing. Can you turn a plain problem into working code fast, with no Android in it? Experienced Android engineers often do worst here. The reason is fluency, not knowledge. They haven’t solved this kind of problem in years. They also practiced it in a different language from the one they’ll use. Rereading theory doesn’t fix that. Solving problems in Kotlin, out loud and against a clock, does. Focus on a small set of patterns first. Arrays, strings, hash maps, two pointers and basic trees cover a lot. Learn the Kotlin standard library calls that make each one short. In the round, say your approach before you type. Start with a working brute force, then improve it. Below is one common problem worked through in Kotlin, with what to say at each step.<\/p>\n
Day-to-day Android work rarely involves heaps or sliding windows. So the skill that fades isn’t understanding. It’s speed at turning a known pattern into code under pressure. That only comes back through practice. Treat this round as maintenance. A few problems every couple of weeks keeps the reflex alive. A cram before every interview cycle has to rebuild it from scratch.<\/p>\n
Yangshun Tay is an ex-Meta staff engineer. He covers this in the Tech Interview Handbook’s guide to choosing a language for coding interviews<\/a>. He lists Kotlin as acceptable, behind Python, Java, C++ and JavaScript. He also says familiarity matters more than the language itself. He recommends sticking with the language you use daily rather than learning a new one for interviews. And he notes that mobile roles may require the platform language.<\/p>\n For Android engineers, that points to Kotlin. The catch is that many learned algorithms in Python or Java years ago. Solving in Kotlin for the first time in the round splits your attention between syntax and logic. So practice the core patterns in Kotlin until the syntax is automatic.<\/p>\n Say the prompt is “given a list of integers, return the k most frequent values.” Here’s how it can go in the round.<\/p>\n First, restate the problem and ask one clarifying question.<\/p>\n So I count how often each number appears and return the k numbers with the highest counts. If two numbers tie, does the order matter?<\/p>\n<\/blockquote>\n Then say the brute force before any code.<\/p>\n The simple version is to count with a map. Then I sort the entries by count and take the first k. That’s n log n for the sort. I’ll write that first, then see if I can do better.<\/p>\n<\/blockquote>\n Now write it. Kotlin’s standard library keeps it short.<\/p>\n Then offer the improvement and its trade-off.<\/p>\n This works and it’s readable. If n is large and k is small, I could use a min-heap of size k instead. That’s n log k. In Kotlin that’s a PriorityQueue ordered by count, popping whenever it grows past k. I’d only switch if the interviewer cares about that difference.<\/p>\n<\/blockquote>\nThe example: top K frequent elements in Kotlin<\/h2>\n
\n
\n
fun topKFrequent(nums: List<Int>, k: Int): List<Int> =\n nums.groupingBy { it }.eachCount()\n .entries\n .sortedByDescending { it.value }\n .take(k)\n .map { it.key }<\/pre>\n\n