HR & Behavioural Android App Development Interview Questions

Situation: my team switched a feature to Kotlin when I only knew Java. Task: deliver a profile screen in two weeks. Action: I spent the first evenings on the official Kotlin koans, converted small utility classes first, and asked a senior to review my early pull requests for idiomatic usage. Result: the screen shipped on time, and my later code needed far fewer review comments. I now learn by building something small immediately.

Give evidence, not adjectives. For example: I have built and published two apps using Kotlin and Jetpack Compose, one with Room and Retrofit and an MVVM structure, and both are on my GitHub with a README and tests. I debug by reading logs and stack traces before asking for help, and I am comfortable learning from code reviews. I can contribute to bug fixes and small features from the first month.

Situation: our cart total sometimes showed wrong values after quick taps. Task: find the race. Action: I added logs with thread names and found two coroutines updating the same mutable list. I changed state updates to MutableStateFlow.update {}, which is atomic, and added a test with many concurrent updates. Result: the bug disappeared, and I shared a short note with the team on safe state updates so it would not repeat.

I follow the Android Developers blog and release notes for Jetpack libraries, read the Kotlin release notes for each version, and watch sessions from the main yearly Android conferences. I try new APIs in a small side project before proposing them at work, and I read pull requests from experienced colleagues. Once a month I review deprecation warnings in our project so upgrades stay small and planned.

Situation: after a release, crash-free users dropped from 99.6 to 97 percent. Task: stop the impact fast. Action: I checked Crashlytics, found a crash on Android 14 caused by a missing foreground service type, paused the staged rollout in Play Console, shipped a hotfix with a test on an emulator for that API level, and wrote a short postmortem. Result: crash rate recovered within a day and we added API-level checks to our release checklist.

I focus on user impact and options rather than jargon. For example, when asked for background tracking every second, I explained that Android limits background work to save battery, so the app would need a visible notification and stricter Play review. I offered two options with trade-offs and a recommendation. Using a simple diagram helped, and the PM chose the option that met the business need with fewer risks.

Situation: a designer wanted a custom tiny close icon on a full-screen dialog. Task: keep the app accessible without blocking the design. Action: I showed that the touch target was below the 48dp guideline and that TalkBack had no label, and prototyped the same look with a larger invisible touch area. Result: we kept the visual style, passed accessibility checks, and agreed to review touch targets in future design handoffs.

I would write a short decision document stating the problem, two or three options with trade-offs, and constraints such as team skill and timeline, then build a small spike of the top options on a real screen. We review with measurable criteria like test effort and build time, decide, and record it as an architecture decision record. Once decided, everyone commits, and we revisit only if new facts appear.

Situation: our app had no shared conventions and reviews took days. Task: speed up reviews and reduce bugs. Action: I proposed ktlint and detekt in CI, created a module template with a convention plugin, and wrote a one-page guide on ViewModel and repository patterns with examples. Result: review time dropped by about half over two months, and new joiners shipped their first feature faster.

I pair on their first tasks, explain the why behind patterns rather than only giving fixes, and review pull requests with specific, kind comments plus links to docs. I give them small features end to end so they see the full flow from API to UI, and I ask them to present one learning in our weekly tech sync. I check in regularly so they feel safe asking questions early.

Situation: a migration I wrote missed a default value, and some users lost their saved addresses. Task: fix it and regain trust. Action: I told my lead immediately, we paused the rollout, I wrote a correct migration with a test covering upgrades from the last three versions, and we restored data from the server for affected users. Result: impact stayed small, and migration tests became mandatory in our CI.

I rank by user impact and risk: crashes and data loss first, then bugs affecting payments or login, then the feature, then minor UI issues. I share the plan with my lead and product manager so trade-offs are visible, and I ask for help or a scope cut early instead of quietly missing the deadline. Small, safe fixes I batch together to save release overhead.

Situation: our feed took four seconds to load because the app made six API calls. Task: reduce load time. Action: I measured each call with network profiling, shared a timeline with the backend team, and we agreed on one aggregated endpoint with only the fields the screen used, plus pagination. I updated the client and added caching. Result: load time dropped to under one second and both teams reused the approach.

I agree on the API contract early, with sample JSON, and build against a fake or mock server so my UI and logic are ready. I keep the repository interface stable, so switching to the real API is a small change. I communicate status in standups and raise risks to my lead early if the dependency threatens the deadline, suggesting options like releasing behind a feature flag.

Situation: product wanted offline mode in one week. Task: give a realistic plan. Action: I broke the work into tasks with estimates, showed that sync conflicts and migrations alone needed two weeks, and proposed a smaller first release with read-only offline caching in one week. Result: we shipped the smaller version on time and the full offline sync three weeks later without quality issues.

Choose something with clear impact. For example: I built the offline cart for our grocery app. Users in low network areas could add items without connection, and the cart synced later with conflict handling. I used Room, WorkManager and a sync status field, and wrote migration and sync tests. After release, cart abandonment from network errors dropped noticeably, and the pattern was reused for the wishlist feature.

Keep it genuine and tied to growth. For example: in five years I want to be a senior or lead Android engineer who owns the architecture of a large app, mentors juniors and works closely with product on decisions. I plan to deepen my skills in performance, Compose and Kotlin Multiplatform, and contribute to the team's engineering practices. I hope to grow that path in a company like this one.

I first assume the reviewer has a reason and ask questions to understand it. If I still disagree, I explain my reasoning with evidence, such as documentation, a benchmark or a test, and suggest a short call if comments go back and forth. If it is a matter of preference, I follow the team convention. The goal is the best code for the team, not winning the argument.

Situation: our home screen had many frozen frames on budget phones. Task: improve scroll smoothness. Action: I captured a system trace, found image decoding on the main thread and unstable list parameters causing recomposition, fixed image sizing with Coil, added keys and immutable models, and created a Baseline Profile. Result: frozen frames dropped by about 60 percent and startup improved by 25 percent in Macrobenchmark.

Kotlin and Java interoperate, so migrate gradually rather than all at once. Start with new features in Kotlin, then convert leaf classes like models and utilities, writing tests before converting. Add nullability annotations to Java code so Kotlin sees correct types. Review auto-converted code because it often overuses !!. Track progress per module and agree on style rules with ktlint or detekt so the codebase stays consistent.