Interview questions: Android and Compose

Q1. Explain the activity lifecycle.

Model answer: "onCreate sets up the UI, onStart makes it visible, onResume makes it interactive; leaving goes through onPause, onStop and possibly onDestroy. On a configuration change like rotation, the activity is destroyed and recreated by default, so I keep state in a ViewModel and small UI state in rememberSaveable. onDestroy is not guaranteed if the process is killed, so I save important data earlier."

Q2. Why use a ViewModel?

Model answer: "It holds screen state and logic, survives configuration changes, and provides viewModelScope so work is cancelled when the screen is gone. It exposes a read-only StateFlow of a UiState data class; the UI sends events as function calls. It must never hold an Activity or View reference."

Q3. What is recomposition?

Model answer: "When state read by a composable changes, Compose re-runs that composable to update the UI, skipping parts whose inputs did not change. Composables should be fast and side-effect free because they can run often. Side effects go in effect handlers like LaunchedEffect, or in the ViewModel."

Q4. remember versus rememberSaveable? What is state hoisting?

Model answer: "remember keeps a value across recompositions; rememberSaveable also survives configuration changes and process death for saveable types. State hoisting moves state up to the caller: the composable receives the value and an onValueChange lambda, which makes it stateless, reusable and testable."

Q5. Why keys in LazyColumn?

Model answer: "Lazy lists compose only visible items. Stable unique keys let Compose keep each item's state and scroll position correct when items are inserted, removed or reordered, and enable item animations."

Q6. How would you build an offline-capable list?

Model answer: "A repository with Room as the single source of truth exposes a Flow to the ViewModel; a refresh function fetches from Retrofit and upserts into Room; failures keep showing cached data with an offline message. WorkManager can sync in the background."

Q7. How do runtime permissions work?

Model answer: "Dangerous permissions are declared in the manifest and requested at the moment of use with the Activity Result API; I check first, explain if denied, and offer a fallback or link to settings. On Android 13+ notifications need POST_NOTIFICATIONS."

Q8. What is an AAB, and what is Play App Signing?

Model answer: "An Android App Bundle is the publishing format from which Play generates optimised APKs per device. I sign uploads with my upload key; with Play App Signing, Google holds the app signing key. versionCode must increase with every upload."

Take-home assignments

Many companies ask you to build a small app in 2 to 4 days, for example "a list from this API with a details screen". Reviewers look for:

• Clean architecture: UI, ViewModel, repository; dependency injection.
• Loading, error and empty states handled.
• Configuration changes handled (rotate the phone!).
• Some unit tests for ViewModel or repository logic.
• A clear README: how to run, decisions made, what you would improve with more time.
• Readable, consistent code; no leftover debug code or commented-out blocks.

Common interview mistakes

• Not rotating the phone in a take-home app: state lost on rotation is the most common failure.
• Over-engineering a 2-day assignment with five modules. Clean and simple wins.
• Saying "I would use the latest library" without explaining why.
• Not asking clarifying questions about requirements.