Walk me through the lifecycle of an Android Activity and why you need to care about it as a developer.
technical-conceptual · Junior level · software-engineering
What the interviewer is really asking
Tests whether the candidate understands Android's lifecycle callbacks and connects them to real concerns like state preservation and resource cleanup, rather than just listing method names.
What to say
- Walk the main callbacks in order — onCreate, onStart, onResume, onPause, onStop, onDestroy — and note that the system, not your code, drives them.
- Tie each phase to a job: set up UI and state in onCreate, start/stop work that's only needed while visible around onStart/onStop, and release resources in onPause/onStop so you don't leak.
- Explain why it matters: configuration changes like rotation destroy and recreate the Activity, so unsaved state is lost unless you hold it somewhere lifecycle-aware such as a ViewModel.
What to avoid
- Don't just recite the method names with no sense of what work belongs in each.
- Don't say you keep all state in the Activity itself — that's exactly what breaks on rotation or process death.
- Don't ignore cleanup; failing to release things like location listeners or coroutines in onStop is a classic memory-leak and battery-drain source.
Example answers
Strong: The system calls onCreate when the Activity is first created — that's where I inflate the UI and read saved state. onStart/onResume mean it's visible and interactive, onPause/onStop mean it's going to the background, and onDestroy is teardown. I start camera or location work in onStart and stop it in onStop so I'm not draining battery off-screen. Because a rotation destroys and recreates the Activity, I keep UI state in a ViewModel so it survives instead of getting wiped.
Weak: There's onCreate, onResume, onPause, onDestroy and a few others. I mostly just put everything in onCreate and it works fine for the screens I've built.