Describe the state hoisting pattern in Compose

WHAT THIS TESTS: Your understanding of unidirectional data flow (UDF) in Compose. It's not just about knowing the definition, but about articulating why it's the cornerstone of building reusable, testable, and maintainable UI components. The interviewer wants to see that you can reason about state management beyond just making something appear on screen.

A GOOD ANSWER COVERS: Four key points. First, define the pattern: State hoisting is the practice of moving a composable's state up the UI tree to a common ancestor, making the child composable stateless. Second, describe the implementation: The stateless composable now receives its state as a parameter and exposes events as lambda callbacks, often following the (value: T, onValueChange: (T) -> Unit) pattern. Third, explain the benefits: This decoupling leads to composables that are highly reusable (they don't manage their own state), easily testable (you can instantiate them with any state and verify their UI output), and it helps create a single source of truth for the state, preventing bugs from inconsistent UI. Fourth, connect it to UDF: State flows down from the state holder, and events flow up from the composable, which is the essence of unidirectional data flow.

COMMON WRONG ANSWERS: A frequent red flag is describing a composable that reads from a ViewModel as "state hoisting." While a ViewModel is often the destination for hoisted state, the pattern itself is about the relationship between parent and child composables. Another mistake is simply saying "it makes it testable" without explaining how—by turning the composable into a pure function of its inputs, making it easy to preview and write unit tests for. Finally, some candidates describe the mechanics (moving remember { mutableStateOf(...) } up) but can't articulate the "why" or the benefits, which is the main point of the question for a senior role.

LIKELY FOLLOW-UPS: "Where should you hoist state to? When is it appropriate to keep state within a composable?" The answer is to hoist to the lowest common ancestor that needs to read or write the state. Keep UI-specific, ephemeral state like scroll position or animation state local to the composable. Another follow-up: "How does CompositionLocal relate to state hoisting?" The answer is that CompositionLocal is for passing data implicitly down the tree, useful for things like themes, but it's not a replacement for explicit state hoisting for UI state as it makes data flow less clear.

ONE CONCRETE EXAMPLE: Imagine a simple SwitchWithLabel composable. A stateful version would contain var checked by remember { mutableStateOf(false) } internally. Hoisting this state means the composable's signature becomes SwitchWithLabel(label: String, checked: Boolean, onCheckedChange: (Boolean) -> Unit). The parent composable now owns the state (var isEnabled by remember { mutableStateOf(false) }) and passes it down: SwitchWithLabel(label = "Enable Feature", checked = isEnabled, onCheckedChange = { isEnabled = it }). The SwitchWithLabel is now stateless and can be reused anywhere.