Explain StatelessWidget vs StatefulWidget and when to choose each

WHAT THIS TESTS: This question probes whether you understand the core architecture of Flutter's widget tree, specifically the difference between a widget as an immutable configuration description and state as mutable data that persists across frames. Interviewers want to see that you grasp why StatefulWidget exists as a two-class system and when extra lifecycle overhead is justified.

A GOOD ANSWER COVERS: First, define StatelessWidget as an immutable class whose properties are final and whose build method depends solely on the configuration passed by its parent; it is cheap to instantiate but is destroyed and recreated whenever the parent rebuilds. Second, define StatefulWidget as a widget that creates a separate State object via createState; the widget itself is immutable and lightweight, but the State object persists across rebuilds and can call setState to trigger localized repaints. Third, explain the decision rule: use StatelessWidget for static content like text, icons, or layouts that only change when parent data changes, and use StatefulWidget when the UI must change in response to user interactions, animations, or streams that the widget itself owns. Fourth, mention that State objects have a lifecycle including initState, didUpdateWidget, and dispose, which is why unnecessary StatefulWidgets add overhead.

COMMON WRONG ANSWERS: A red flag is saying that StatefulWidget is faster or more capable than StatelessWidget; in reality, StatelessWidget is lighter because it avoids lifecycle management. Another mistake is claiming that the StatefulWidget class itself holds mutable fields; the mutable data lives in the State object, not the widget. A third error is recommending StatefulWidget for every screen out of habit, which shows poor judgment about separation of concerns and leads to heavier widget trees.

LIKELY FOLLOW-UPS: The interviewer may ask how you manage state without StatefulWidget, leading to InheritedWidget, ValueNotifier, or state management packages like Bloc or Riverpod. They might also ask what happens to State when a StatefulWidget is moved in the tree, which tests your understanding of the GlobalKey versus key-based reconciliation rules. Another follow-up is asking when to use initState versus didChangeDependencies.

ONE CONCRETE EXAMPLE: Imagine a static welcome screen with a logo and title: this should be a StatelessWidget because nothing changes after initial build. Now imagine a favorite button that toggles a heart icon and increments a counter when pressed: this needs a StatefulWidget because the widget owns data that changes over time and must call setState to rebuild the icon and counter text. If the favorite status were instead managed by a parent or a global store, the button itself could remain StatelessWidget and simply receive the current state and a callback.