Flutter interview questions

What a strong answer covers

• A `StatelessWidget` is immutable; its properties cannot change after it's created, and it does not have any mutable state.
• A `StatefulWidget` is dynamic; it can maintain state that changes over its lifetime, allowing the UI to update in response to events.
• Use `StatelessWidget` for static UI elements like `Text`, `Icon`, or `Image` that don't need to react to user input or data changes.
• Use `StatefulWidget` for interactive UI elements like `Checkbox`, `Slider`, or a custom widget that needs to manage its own internal state (e.g., a counter).

Where people lose the point

• ×Confusing the widget itself with its state, especially for `StatefulWidget` (the widget is immutable, the `State` object is mutable).
• ×Attempting to modify properties of a `StatelessWidget` after its creation.
• ×Using `StatefulWidget` unnecessarily for purely static content, leading to slightly more overhead.

What a strong answer covers

• Hot Reload injects updated source code into the running Dart VM, preserving the app's current state and UI, allowing for rapid iteration.
• Hot Restart completely restarts the Dart VM, rebuilding the entire widget tree from scratch and resetting the app's state to its initial configuration.
• Use Hot Reload for quick UI changes, minor bug fixes, or adjusting widget properties without losing the current application state.
• Use Hot Restart when you need to reset the entire application state, modify `initState` logic, change global variables, or update native code.

Where people lose the point

• ×Expecting Hot Reload to reset the application state or re-run `initState` methods.
• ×Not understanding that Hot Reload only works for Dart code changes, not native code changes.
• ×Using Hot Restart for every code change, which slows down the development cycle unnecessarily.

What a strong answer covers

• Keys are identifiers for Widgets, Elements, and SemanticsNodes, used by Flutter to efficiently identify and preserve the state of widgets during rebuilds.
• They are crucial when you have multiple widgets of the same type in a list or when reordering widgets, helping Flutter match the old widget with the new one.
• Without keys, Flutter might incorrectly reuse state or elements for widgets that have changed position or content, leading to unexpected behavior or visual glitches.
• Types of keys include `ValueKey`, `ObjectKey`, `UniqueKey`, and `GlobalKey`, each serving specific use cases for identifying widgets.

Where people lose the point

• ×Not using keys when dynamically adding, removing, or reordering widgets of the same type in a list, leading to state loss or incorrect updates.
• ×Misunderstanding that keys are primarily for Flutter's internal reconciliation process, not for general widget identification in your code.
• ×Overusing `GlobalKey` when a simpler `ValueKey` or `UniqueKey` would suffice, potentially causing performance issues or memory leaks.

What a strong answer covers

• `mainAxisAlignment` controls how children are positioned along the main axis of a `Row` or `Column`.
• For a `Row`, the main axis is horizontal; for a `Column`, it's vertical. Examples include `start`, `center`, `end`, `spaceBetween`, `spaceAround`, `spaceEvenly`.
• `crossAxisAlignment` controls how children are positioned along the cross axis of a `Row` or `Column`.
• For a `Row`, the cross axis is vertical; for a `Column`, it's horizontal. Examples include `start`, `center`, `end`, `stretch`, `baseline`.

Where people lose the point

• ×Confusing which axis is main and which is cross for `Row` vs. `Column`.
• ×Applying `crossAxisAlignment.stretch` without ensuring the parent has defined constraints in the cross axis.
• ×Not understanding that `mainAxisAlignment` distributes space *between* children, while `crossAxisAlignment` aligns children *within* the available cross-axis space.

What a strong answer covers

• `SizedBox` is a simple widget used to give a child a specific fixed size or to create empty space of a fixed size.
• `Container` is a more powerful widget that can combine common painting, positioning, and sizing widgets, offering properties for `padding`, `margin`, `decoration`, `alignment`, `constraints`, and `transform`.
• Use `SizedBox` when you only need to control the width and/or height of a widget or create empty space, as it's more lightweight.
• Use `Container` when you need to apply styling (like background color, borders, shadows), padding, margin, or more complex layout constraints to its child.

Where people lose the point

• ×Using `Container` for simple spacing or sizing when `SizedBox` would be more efficient and semantically appropriate.
• ×Trying to apply `decoration` or `padding` directly to a `SizedBox` (it doesn't have these properties).
• ×Not understanding that `Container` will try to be as large as possible if it has no child and no explicit width/height, unless constrained by its parent.

What a strong answer covers

• `createState()`: Called immediately after the `StatefulWidget` is inserted into the widget tree, responsible for creating the mutable `State` object.
• `initState()`: Called once when the `State` object is first created, used for one-time initialization, subscribing to streams, or fetching initial data.
• `didChangeDependencies()`: Called immediately after `initState` and whenever the widget's dependencies (e.g., `InheritedWidget`) change, useful for reacting to changes in inherited data.
• `build()`: Called frequently to describe the part of the user interface represented by this widget, triggered by `setState()`, `didChangeDependencies()`, or parent rebuilds.
• `dispose()`: Called when the `State` object is removed from the tree permanently, used to clean up resources like controllers, animations, or stream subscriptions.

Where people lose the point

• ×Performing heavy operations or network requests directly in `build()` without proper caching or state management, leading to performance issues.
• ×Forgetting to call `super.initState()` or `super.dispose()` in overridden methods.
• ×Not disposing of controllers, listeners, or subscriptions in `dispose()`, leading to memory leaks.

What a strong answer covers

• When `setState()` is called, it marks the `State` object as 'dirty', indicating that its internal state has changed and the widget needs to be rebuilt.
• Flutter's framework schedules a rebuild for that specific `State` object and its associated `Element` in the next frame.
• During the rebuild, Flutter calls the `build()` method of the marked `State` object.
• The `build()` method returns a new widget tree, which Flutter then compares with the previous widget tree (via the Element Tree) to identify minimal changes needed to update the Render Object Tree, optimizing performance.

Where people lose the point

• ×Calling `setState()` outside of a `StatefulWidget`'s `State` object.
• ×Assuming `setState()` immediately rebuilds the UI; it schedules a rebuild for the next frame.
• ×Modifying state variables directly without calling `setState()`, which will not trigger a UI update.

What a strong answer covers

• `FutureBuilder` is used to build UI based on the result of a `Future`, which represents a single asynchronous operation that will complete with a single value or an error.
• `StreamBuilder` is used to build UI based on a `Stream`, which represents a sequence of asynchronous events (multiple values or errors over time).
• Use `FutureBuilder` for one-time asynchronous operations like fetching data from an API, loading a file, or performing a database query.
• Use `StreamBuilder` for continuous data updates, such as real-time chat messages, sensor data, countdown timers, or listening to changes in a database.

Where people lose the point

• ×Using `FutureBuilder` for continuous data streams, which would only process the first event.
• ×Using `StreamBuilder` for a one-time operation, which is less efficient and semantically incorrect.
• ×Not handling the `ConnectionState.waiting` and `ConnectionState.done` states in `FutureBuilder` or `StreamBuilder` snapshots, leading to incomplete UI.

What a strong answer covers

• `InheritedWidget` is a special type of widget that efficiently propagates data down the widget tree.
• It allows descendant widgets to access data provided by an ancestor widget without passing it explicitly through every constructor.
• When an `InheritedWidget` rebuilds and its data changes, any descendant widget that registered to 'depend' on it (using `BuildContext.dependOnInheritedWidgetOfExactType`) will automatically rebuild.
• It's a fundamental building block for many state management solutions (like Provider) and is used internally by Flutter for things like `Theme` and `MediaQuery`.

Where people lose the point

• ×Using `InheritedWidget` for mutable state without understanding that it's typically used for immutable data that triggers rebuilds when replaced.
• ×Forgetting to call `dependOnInheritedWidgetOfExactType` (or `of(context)`) in descendant widgets, leading to no data access or no rebuilds.
• ×Overusing `InheritedWidget` for very granular state, which can lead to unnecessary rebuilds if not managed carefully.

What a strong answer covers

• The `provider` package is a wrapper around `InheritedWidget` that simplifies state management and dependency injection in Flutter.
• It solves the problem of 'prop drilling' (passing data down multiple levels of the widget tree) and makes state accessible to any descendant widget.
• Basic usage involves wrapping a part of the widget tree with a `Provider` (e.g., `ChangeNotifierProvider`) to make a model available.
• Descendant widgets can then 'consume' the data using `Provider.of<T>(context)` (to read and listen) or `context.watch<T>()` (to listen) or `context.read<T>()` (to read without listening).

Where people lose the point

• ×Forgetting to wrap the widget tree with the appropriate `Provider` type, leading to `ProviderNotFoundException`.
• ×Using `Provider.of(context, listen: true)` (or `context.watch()`) in a `build` method when only reading data is needed, causing unnecessary rebuilds.
• ×Not calling `notifyListeners()` in a `ChangeNotifier` when its state changes, preventing UI updates.

What a strong answer covers

• `MediaQuery` provides information about the entire screen or window (e.g., total width, height, orientation, pixel density).
• `LayoutBuilder` provides the constraints (min/max width/height) of its parent widget, allowing a widget to adapt its layout based on the space it's given by its immediate parent.
• Use `MediaQuery` when you need global screen information, such as adjusting layouts based on the device's overall orientation or displaying different UIs for phone vs. tablet.
• Use `LayoutBuilder` when a widget needs to adapt its size or content based on the specific space available to it within its parent, without knowing the global screen size.

Where people lose the point

• ×Using `MediaQuery` to get the size of a specific widget, which is incorrect as `MediaQuery` reflects the entire screen.
• ×Trying to use `LayoutBuilder` to get global device information (like device pixel ratio), which is not its purpose.
• ×Not understanding that `LayoutBuilder`'s constraints are passed down from its parent, not necessarily the full screen.

What a strong answer covers

• The Widget Tree is a declarative description of the UI, a blueprint. Widgets are immutable and lightweight, describing configuration.
• The Element Tree is the concrete, mutable representation of the widget tree. Elements are the actual instances of widgets in the UI, holding references to both the widget and the render object.
• The Render Object Tree is responsible for the actual layout, painting, and hit-testing of the UI. Render objects are mutable and handle the low-level rendering details.
• During a rebuild, Flutter compares the new Widget Tree with the existing Element Tree. If a widget's type and key match, the existing Element is updated with the new widget's configuration. If not, the Element and its corresponding Render Object are replaced. This reconciliation process optimizes UI updates.

Where people lose the point

• ×Confusing widgets with elements or render objects, treating them as the same entity.
• ×Believing that every widget rebuild leads to a complete re-rendering of the entire UI.
• ×Not understanding that the Element Tree acts as the stable intermediary, allowing Flutter to efficiently update the Render Object Tree without recreating everything.

What a strong answer covers

• BLoC is a state management pattern that separates business logic from the UI, making applications more scalable, testable, and maintainable.
• It uses `Streams` to manage state changes: UI sends 'events' to the BLoC, the BLoC processes these events and emits new 'states' back to the UI.
• Core principles include: everything is a stream, inputs are events, outputs are states, and the BLoC itself is a pure function that transforms events into states.
• Benefits include clear separation of concerns, easy testability of business logic, reusability of BLoCs, and predictable state changes.

Where people lose the point

• ×Putting UI logic or widget-specific state directly into the BLoC.
• ×Not properly handling `Stream` subscriptions and disposals, leading to memory leaks.
• ×Overcomplicating simple state management needs with BLoC when a simpler solution (like `Provider` with `ChangeNotifier`) would suffice.

What a strong answer covers

• `Navigator 1.0` uses an imperative API (`push`, `pop`, `pushNamed`) to manage a stack of `Route` objects. It's simpler for basic navigation flows.
• `Navigator 2.0` (Router API) uses a declarative approach, where the navigation stack is represented by a list of `Page` objects. It's designed for complex routing, deep linking, and web integration.
• Use `Navigator 1.0` for apps with straightforward navigation, where you primarily push and pop screens sequentially.
• Use `Navigator 2.0` for apps requiring deep linking, web support, dynamic routing based on application state, or complex nested navigation, offering greater control but with a steeper learning curve.

Where people lose the point

• ×Trying to force `Navigator 1.0` to handle complex deep linking or web routing scenarios, leading to brittle code.
• ×Overcomplicating simple navigation with `Navigator 2.0` when `Navigator 1.0` would be more efficient and easier to maintain.
• ×Not understanding the core concept of `Page` objects and `RouterDelegate`/`RouteInformationParser` in `Navigator 2.0`.

What a strong answer covers

• **Minimize Widget Rebuilds:** Use `const` widgets where possible, extract frequently changing parts into separate `StatefulWidget`s, and use `Consumer` or `Selector` with `Provider` to rebuild only necessary parts of the UI.
• **Use `RepaintBoundary`:** Wrap complex, static parts of the UI that don't change often in a `RepaintBoundary` to prevent their children from being repainted when other parts of the screen change.
• **Optimize List Views:** Use `ListView.builder` or `CustomScrollView` with `SliverList`/`SliverGrid` for long lists to only build widgets that are currently visible on screen, improving memory and rendering performance.
• **Avoid Expensive Operations in `build()`:** Move heavy computations, network calls, or complex logic out of the `build` method into `initState`, `didChangeDependencies`, or separate business logic components.
• **Profile and Debug:** Regularly use Flutter DevTools to identify performance bottlenecks, excessive rebuilds, and memory leaks.

Where people lose the point

• ×Putting complex calculations or network requests directly into the `build` method, causing UI jank.
• ×Not using `const` constructors for widgets that don't change, leading to unnecessary rebuilds.
• ×Failing to dispose of controllers, animations, or stream subscriptions, resulting in memory leaks.