Jetpack Compose changes how Android UI is expressed, but the important shift is not Kotlin instead of XML. It is learning to describe the screen from state and letting Compose keep the rendered UI synchronized as that state changes.

The goal is not to memorise Compose APIs or chase recomposition rules. It is to understand how declarative UI changes responsibility, what Compose remembers between executions, how state drives UI updates, and how state lifetime affects the way a screen is designed.

What this section builds

The questions are arranged so later concepts build on earlier ones. Together they develop a mental model of declarative UI, Composition, recomposition, state, and UI-state lifetime before moving into ownership, hoisting, state holders, side effects, navigation, and performance.

Start with the interview-ready answer, then go deeper only where you need more context. By the end of this section, you should be able to explain not only how Compose updates a screen, but also the engineering reasoning behind where state lives, how long it should survive, and how those decisions affect production UI code.

Questions

• What is the difference between the View system and Jetpack Compose?
• What is composition?
• What is recomposition and what triggers it?
• How does state work in Jetpack Compose?
• What is the difference between remember and rememberSaveable?
• What is state hoisting and why is it useful?
• What is the difference between a stateless and stateful composable?
• How should you observe ViewModel state in Compose?
• What are side effects in Compose and how should they be handled?
• When should data loading happen in LaunchedEffect versus ViewModel.init?
• What is derivedStateOf and when is it useful?
• What is snapshotFlow?
• What is the Compose snapshot system?
• What are CompositionLocals and when should you avoid them?
• What are mutableStateListOf and mutableStateMapOf?
• What is SaveableStateHolder?
• What is the composition lifecycle?
• How do NavHost and NavController work?