Flutter Developer interview questions

They differ in when the type is chosen and how much static checking Dart performs.

• var infers one static type from the initializer, so var count = 1 cannot later hold a String.
• Object accepts any non-null Dart object, while Object? also accepts null, but both require type checks before member access.
• dynamic defers member and assignment checks until runtime, so I keep it at untyped boundaries and convert it quickly.

final is assigned once at runtime, while const represents a compile-time constant.

• A final value may come from DateTime.now() or an API response, but it cannot be reassigned afterward.
• A const value and everything inside its constant collection must be known at compile time.
• const widget instances can be canonicalized and reused, so I use const constructors where all arguments are constant.

Dart types are non-nullable by default, and a nullable type must be marked with ?.

• String name cannot hold null, while String? name can and must be checked or safely accessed before use.
• ?? supplies a fallback and ?. performs conditional access; ! asserts non-null and can throw if that assertion is wrong.
• late postpones initialization, but reading a late variable before assignment causes a runtime error, so I use it only when lifecycle order guarantees a value.

I choose List for ordered values, Set for unique values, and Map for key-value lookup.

• A List keeps order and permits duplicates, which suits a sequence of messages or products.
• A Set removes duplicates and provides efficient membership checks, such as selected category IDs.
• A Map retrieves a value by key, such as userById[id], and collection if and for can build any of these collections declaratively.

Dart supports optional positional or named parameters, and functions can be passed and stored like other values.

• Named parameters use braces and required marks mandatory ones, which makes calls such as createUser(name: 'Ana') readable.
• Optional parameters need a nullable type or a default value, while positional optional parameters use brackets.
• A callback such as VoidCallback can be passed to a button, and a short single-expression function can use => syntax.

A Dart class groups state and behavior, and its constructors create valid instances.

• this.name in a constructor parameter initializes a field directly, while required named parameters make required input explicit.
• A named constructor such as User.guest() provides another clear creation path, and a factory constructor may return a cached instance or subtype.
• extends reuses one superclass implementation, and overridden members should be marked with @override so the analyzer can verify them.

An interface defines a contract to implement, while a mixin supplies reusable behavior to classes.

• Every Dart class exposes an implicit interface, and implements requires the new class to provide all interface members.
• An interface class can be implemented but not extended outside its library, which makes the intended API boundary explicit.
• A mixin is applied with with and can share methods across unrelated classes without creating a deep inheritance chain.

Records return or group a few typed values without declaring a dedicated class, and patterns unpack or test their shape.

• A function can return (User, bool), keeping both field types in the static type system.
• A destructuring declaration such as final (user, cached) = result gives names to the record fields.
• List, map, object, and switch patterns can extract nested values, but I still use a named class when data needs identity, methods, or a stable public model.

A sealed class defines a closed family of subtypes that a switch can handle exhaustively.

• Subtypes must be declared in the same library, so the compiler knows the complete set.
• Loading, Success(data), and Failure(error) are a practical sealed result hierarchy for a screen.
• A switch expression over that hierarchy reports a compile-time error when a case is missing, including after a new subtype is added.

A Future completes once with a value or error, while a Stream can emit multiple values over time.

• I await a Future for one REST response or file read and catch its failure with try and catch.
• I listen to a Stream for repeated events such as authentication changes or live database updates.
• Stream subscriptions should be cancelled when their owner is disposed, while await for can consume events until the stream closes.

In Flutter, the build method describes the UI for the current state instead of issuing commands to mutate individual views.

• When state changes, Flutter calls build again and compares the new widget configuration with the existing tree.
• A loading flag can select a progress indicator or content directly in the widget tree.
• build should stay free of network calls and other side effects because the framework may invoke it many times.

I use StatelessWidget when the widget has no mutable local state and StatefulWidget when state must live across rebuilds.

• Both widget objects are immutable; a StatefulWidget creates a separate mutable State object.
• A title rendered only from constructor arguments fits StatelessWidget, while a local password-visibility toggle fits StatefulWidget.
• If state belongs to several screens or business logic, I move it above the widget or into a state-management layer instead of adding more local State.

A State object is initialized, may receive dependency or widget updates, rebuilds, and is eventually disposed.

• initState runs once for setup that does not depend on inherited widgets, such as creating an AnimationController.
• didChangeDependencies handles inherited dependencies, and didUpdateWidget reacts when the parent supplies a new widget configuration.
• dispose releases controllers, focus nodes, and subscriptions before calling super.dispose.

BuildContext identifies a widget's location in the element tree and is used to find ancestors such as Theme or Navigator.

• Theme.of(context) searches upward from that exact location, so the required provider must be an ancestor.
• A context above a newly created Scaffold cannot find that Scaffold; Builder can create a context below it.
• After an await, I check context.mounted before navigation or showing UI because the widget may have been removed.

Widgets are immutable configurations, elements manage their mounted identity, and render objects perform layout and painting.

• build creates lightweight widget descriptions that can be replaced on every rebuild.
• An element links a widget to its tree position and preserves associated State when type and key still match.
• RenderObject instances receive constraints, choose sizes, paint pixels, and perform hit testing for render-backed widgets.

Keys help Flutter match widget configurations to existing elements when sibling order or identity changes.

• ValueKey(item.id) keeps the correct State attached when a reorderable list moves items.
• Keys matter among siblings of the same widget type; adding random UniqueKeys forces state loss instead of fixing identity.
• GlobalKey can access state or move an element across the tree, but it is heavier and should be reserved for cases such as FormState.

A parent sends constraints down, each child chooses a permitted size, and the parent positions that child.

• Constraints specify minimum and maximum width and height rather than one exact size in every case.
• A child cannot choose a size outside those limits, so setting width to 500 does not override a parent's maximum of 300.
• Unbounded constraints commonly appear inside scrollables and can conflict with Expanded or a child that tries to take infinite space.

Row and Column use Flex layout, and Expanded or Flexible decides how children share remaining main-axis space.

• Row lays children horizontally and Column vertically, while mainAxisAlignment distributes free space on that axis.
• Expanded uses a tight fit and makes its child fill its flex share, which can prevent text from overflowing a Row.
• Flexible defaults to a loose fit, allowing its child to use less than its share, and flex values divide space proportionally.

For a long or dynamic list I use ListView.builder so only visible items and nearby cache items are built.

• A ListView with an explicit children list eagerly creates every child and suits only a small fixed list.
• SingleChildScrollView builds its entire child, so wrapping a large Column in it wastes memory and build work.
• For mixed scrolling sections such as an app bar, grid, and list, CustomScrollView with slivers composes them into one scroll view.

MaterialApp provides ThemeData for Material widgets, while CupertinoApp provides CupertinoThemeData for iOS-style widgets.

• Theme.of(context) and CupertinoTheme.of(context) read inherited colors and typography instead of duplicating constants per screen.
• A ColorScheme lets Material components use consistent roles such as primary, surface, and error in light and dark themes.
• I choose one coherent design system for the product and use platform-adaptive controls only where users expect native behavior.