Android Interview Questions: Kotlin, Lifecycle and Project Scenarios

1. How do you handle a nullable Kotlin value?

Explain what may be absent and what the user should see in that case. Discuss checking the value or choosing an appropriate fallback instead of forcing a value with a non-null assertion without justification. Use a small example from an optional profile field or an API response and describe the invalid-data case.

2. What happens when an activity is recreated?

Explain that the activity instance can be destroyed and created again, including during configuration changes. Describe where your app keeps temporary screen state and persistent records. A ViewModel is useful for configuration-related state retention but is not a replacement for persistent storage or a complete process-death recovery plan.

3. How would you investigate a blank list screen?

First reproduce the input and environment. Determine whether the list is legitimately empty, data loading failed, parsing produced unexpected values or the UI missed an update. Inspect each boundary before changing code. Show the difference between an empty state and an error state in the interface.

4. What should an API-connected screen show when a request fails?

Describe the failed operation, preserve useful existing data where appropriate and offer a clear recovery action. Do not leave loading active forever or show a false success message. Discuss how you would test a slow response, invalid payload and repeated retry rather than demonstrating only a successful call.

5. How do you decide where app logic belongs?

Keep screen rendering, user events and data access understandable as separate responsibilities. Explain a feature from event to saved record and visible result. A simple project does not need every architecture pattern. Use the Android architecture guide to revise state ownership and data boundaries.

6. How would you explain a portfolio bug you fixed?

State the reproduction steps, expected behaviour, observed failure and the evidence that narrowed the cause. Explain the smallest correction and the check used to verify it. Mention a remaining limitation where relevant. If a library or tutorial supplied part of the solution, be clear about what you implemented and what you learned.

7. What should be checked before sharing a practice build?

Review permissions, sample data, visible errors, setup instructions and testing on the intended device or emulator. Keep secrets out of the repository and explain whether any feature is a local simulation. App-store distribution has additional requirements; use current official Android and distribution guidance rather than assuming a portfolio build is release-ready.

Prepare a short project walkthrough

Show the user problem, screen flow, one Kotlin decision, one data boundary and one verified failure case. Use the Android project briefs for a focused exercise and the official lifecycle guide for platform behaviour. Keep answers tied to work you understand.