Flutter Interview Questions

Dart is an object-oriented, statically typed programming language created by Google. Flutter uses it because Dart compiles ahead-of-time to fast native machine code for release builds, while also supporting just-in-time compilation during development, which powers Flutter's hot reload feature.

A widget is the basic building block of a Flutter UI. Everything visible on screen, from a button to a padding wrapper to the entire app, is a widget. Widgets describe what their part of the interface should look like given their current configuration and state.

A StatelessWidget has no mutable state, it's built once from its configuration and never changes unless the parent rebuilds it with new data. A StatefulWidget holds a State object that can change over time, and calling setState() on that state triggers the widget to rebuild and reflect the update.

The widget tree is the hierarchy of nested widgets that describes the structure of a Flutter app's UI at any given moment. Flutter builds this tree from the root widget down, with each widget potentially containing child widgets, forming the full visual layout.

setState() is a method available inside a State object that tells Flutter the internal state has changed and the widget needs to rebuild. You call it after updating any variable that affects what the widget displays, so the framework knows to re-run the build method. ```dart setState(() { counter++; }); ```

Hot reload injects updated source code into a running Dart VM without losing the app's current state, so you see UI changes almost instantly while staying on the same screen. Hot restart fully restarts the app, resetting all state, which is needed for changes that hot reload can't apply, like modifying a global variable's initial value.

main() is the entry point of every Dart application. In a Flutter app, it typically calls runApp() and passes it the root widget, which kicks off building and rendering the entire widget tree to the screen.

MaterialApp wraps an app with Material Design styling and behaviors, following Google's design language used across Android and the web. CupertinoApp does the same but for iOS-style Cupertino design, giving widgets that look and feel native to iOS. Many apps use MaterialApp even for iOS since Material widgets are broadly accepted cross-platform.

Row and Column arrange children horizontally and vertically. Container adds padding, margin, decoration, and sizing around a child. Stack layers widgets on top of each other. Expanded and Flexible control how much space a child takes within a Row or Column. These are the widgets most layouts are built from.

The Padding widget wraps a child and adds space around it based on an EdgeInsets value. ```dart Padding( padding: EdgeInsets.all(16), child: Text('Hello'), ) ``` EdgeInsets.symmetric and EdgeInsets.only give finer control when padding differs per side.

ListView displays a scrollable list of widgets, either laid out all at once or built lazily as the user scrolls. It's the standard widget for showing any list of content, from a chat history to a settings menu, and handles scroll physics automatically.

ListView builds all its children up front, which is fine for short, fixed lists. ListView.builder builds children lazily, only constructing the ones currently visible or near the viewport, which is essential for long or infinite lists to avoid wasting memory and startup time on off-screen items.

The Navigator widget manages a stack of routes (screens). Navigator.push() adds a new screen on top of the stack, and Navigator.pop() removes the current one, returning to the previous screen. ```dart Navigator.push( context, MaterialPageRoute(builder: (context) => SecondScreen()), ); ```

BuildContext is a handle to the location of a widget within the widget tree. It's passed into build methods and is used to look up inherited data, theme values, and to perform actions like navigation, since many Flutter APIs need to know where in the tree a widget sits.

Scaffold implements the basic visual structure of a Material Design screen, providing slots for an app bar, a body, a floating action button, a bottom navigation bar, and drawers. Most screens in a Flutter app start by wrapping their content in a Scaffold.

After installing the Flutter SDK and adding it to your PATH, running `flutter create my_app` scaffolds a new project with the standard folder structure. `flutter run` then builds and launches the app on a connected device or simulator, and `flutter doctor` checks that the development environment is set up correctly.

pubspec.yaml is the configuration file at the root of every Flutter project. It declares the app's name, version, SDK constraints, package dependencies, and any assets or custom fonts the app bundles, such as images or icon files referenced elsewhere in the code.

Hot reload can apply changes to widget build methods, styling, and most code inside existing classes almost instantly. It can't apply changes to main(), initState(), global variables' initial values, or enum definitions, since those only run once at startup, so those changes require a hot restart instead.

Center is a layout widget that centers its single child within itself, both horizontally and vertically. It's a common shorthand instead of manually configuring alignment properties on a parent widget just to center one piece of content.

Icon displays a glyph from an icon font, most commonly Flutter's built-in Material Icons set. ```dart Icon(Icons.favorite, color: Colors.red, size: 30) ``` Custom icon packs or SVG assets can also be used when the built-in Material icon set doesn't cover what a design calls for.

Text displays a string of styled text on screen. It commonly takes a TextStyle property controlling font size, weight, and color, along with alignment, overflow behavior (such as truncating with ellipsis), and a maxLines limit for constraining how many lines of text are shown.

GestureDetector wraps a widget and listens for touch interactions like taps, double taps, long presses, and drags, running a callback when the gesture is detected. It's commonly used to make a non-interactive widget like a Container or an Image respond to user touch.

Image.asset() loads an image bundled directly inside the app package, declared in pubspec.yaml, which loads instantly since no network request is involved. Image.network() fetches an image from a URL at runtime, which requires handling loading and error states since the network call can be slow or fail.

mainAxisAlignment controls how children are spaced along a Column's main axis (vertical). Common values include start, center, end, spaceBetween, and spaceAround, which determine whether children cluster together or spread out to fill the available vertical space.

SafeArea automatically adds padding so that a widget's content avoids system intrusions like a phone's notch, status bar, or rounded corners. Wrapping a screen's body in SafeArea prevents important UI elements from being obscured or clipped on devices with irregular screen shapes.

The CircularProgressIndicator widget shows Flutter's standard spinner. ```dart isLoading ? CircularProgressIndicator() : Text('Loaded') ``` It's commonly shown conditionally based on a loading flag, or automatically through a FutureBuilder's loading (waiting) connection state.

TextField renders an editable text input box. Attaching a TextEditingController to it lets you read or programmatically set its current value. ```dart final controller = TextEditingController(); TextField(controller: controller); print(controller.text); ```

A SnackBar is a brief, non-blocking message that appears temporarily at the bottom of the screen, typically confirming an action like a successful save. A Dialog is a modal overlay that blocks interaction with the rest of the screen until dismissed, used for something requiring the user's explicit attention or decision, like a confirmation prompt.

The ThemeData object, passed to MaterialApp's theme property, defines colors, typography, and component styling applied consistently across the app. ```dart MaterialApp( theme: ThemeData(primarySwatch: Colors.blue), home: HomeScreen(), ) ``` Widgets that don't specify explicit styling inherit these theme defaults automatically.

An overflow error happens when children of a Row or Column need more space than is available, shown as yellow-and-black striped warning markers. Common fixes include wrapping children in Expanded or Flexible so they share space proportionally, or wrapping the whole Row or Column in a scrollable widget like SingleChildScrollView if the content genuinely needs more room than the screen provides.

AppBar is the top navigation bar typically shown by a Scaffold, commonly holding a title, a leading icon (like a back button), and a list of action icons on the trailing side. It's one of the most consistently used widgets across nearly every Flutter screen with a Material design.

`flutter devices` lists available connected devices and simulators. `flutter run -d chrome` targets the web, `flutter run -d <device_id>` targets a specific mobile device or emulator, letting a developer verify behavior across platforms without leaving the command line.

Debug mode includes assertions, hot reload support, and debugging information, but runs noticeably slower. Profile mode strips out most debug overhead while keeping enough instrumentation for performance profiling tools to work. Release mode is fully optimized and compiled ahead-of-time for the smallest, fastest build meant for distribution.

MaterialPageRoute gives the platform-appropriate default transition, a slide-up on Android and a slide-in-from-the-right on iOS, with no extra setup needed. A custom PageRouteBuilder lets you define your own transition animation, such as a fade or a scale effect, when the default doesn't match the app's design intent.

Provider exposes a piece of state higher up the widget tree and lets descendant widgets read or listen to it without passing it down manually through every constructor. Widgets that call context.watch() rebuild when the value changes, while context.read() grabs the value once without subscribing to updates.

BLoC (Business Logic Component) separates UI from business logic using streams. The UI dispatches events into the BLoC, the BLoC processes them and emits new states, and the UI rebuilds in response to those states. Teams choose it for testability and a clear separation of concerns, especially on larger apps with complex business rules.

InheritedWidget is Flutter's low-level mechanism for efficiently passing data down the widget tree, letting descendants access it without a constructor chain while only rebuilding widgets that actually depend on the changed data. Provider is built directly on top of InheritedWidget, offering a friendlier API for the same underlying mechanism.

Mutable state is modified in place, while immutable state creates a brand-new object with updated values instead of changing the existing one. Flutter's widget rebuild model favors immutability because it makes it easy to detect what changed by comparing references, and it avoids subtle bugs from shared mutable objects being modified unexpectedly.

Data can be passed through constructor parameters for parent-to-child communication, which is simple but gets unwieldy across many layers. Callbacks pass data from child back to parent. For data needed across distant, unrelated widgets, a state management solution like Provider or Riverpod avoids threading data through every intermediate widget manually.

initState() runs once when the State object is created, useful for one-time setup like starting an animation or subscribing to a stream. build() runs whenever the widget needs to render, potentially many times. didUpdateWidget() runs when the parent rebuilds the widget with new configuration. dispose() runs when the widget is removed permanently, used for cleanup like canceling subscriptions.

Flutter builds a widget tree describing configuration, which is used to build an element tree that manages the widget's lifecycle, which in turn produces a render tree responsible for layout, painting, and compositing. Changes flow from the widget layer down, and Flutter is efficient about only rebuilding and repainting the parts of the tree that actually changed.

Keys help Flutter identify widgets across rebuilds, especially when a list of widgets changes order, is filtered, or has items inserted or removed. Without a key, Flutter can confuse which widget instance is which, causing incorrect state to carry over to the wrong item. ValueKey and UniqueKey are common choices depending on the situation.

final means a variable can only be assigned once, but its value can be determined at runtime. const means the value must be known at compile time and is deeply immutable. Using const constructors for widgets that never change lets Flutter skip rebuilding them entirely, which is a meaningful performance win.

The http package or Dio are the most common choices. A typical call uses async/await with a try-catch block to handle errors. ```dart final response = await http.get(Uri.parse('https://api.example.com/data')); if (response.statusCode == 200) { final data = jsonDecode(response.body); } ```

FutureBuilder rebuilds its child based on the state of an asynchronous computation, showing a loading indicator while the Future is pending, the actual data once it resolves, or an error widget if it fails. It's commonly used to display data fetched from an API without manually managing loading state.

StreamBuilder works like FutureBuilder but listens to a Stream instead of a single Future, rebuilding every time a new value is emitted. It fits ongoing data sources like a live database query, a WebSocket connection, or a timer, where FutureBuilder only handles a single, one-time asynchronous result.

The Form widget wraps a set of TextFormField widgets, each accepting a validator function that returns an error message or null. Calling formKey.currentState!.validate() checks every field's validator and returns whether the entire form is valid, which is the standard pattern before submitting form data.

A package from pub.dev is published and versioned externally, fetched over the network, and shared across the Dart/Flutter community. A local package lives within the project (or a workspace) and is referenced by file path in pubspec.yaml, which is common for splitting a large app into internal, reusable modules without publishing them publicly.

Platform channels let Dart code communicate with native Android (Kotlin/Java) or iOS (Swift/Objective-C) code, passing messages asynchronously across the bridge. This is how Flutter accesses native APIs that don't have a Dart plugin already, such as a custom native SDK a company needs to integrate.

Both control how a child fills available space in a Row or Column. Expanded forces the child to fill all remaining space, equivalent to Flexible with fit set to FlexFit.tight. Flexible by default lets the child be smaller than the available space if it doesn't need all of it, using FlexFit.loose.

Rebuilds cascade down from any ancestor calling setState() or from a listened-to value changing, and they can spread further than needed if state is held too high in the tree. Extracting widgets that don't depend on the changing state into their own const or separately-built widgets, and scoping state management providers narrowly, keeps rebuilds limited to what actually needs to change.

Deep linking requires configuring platform-specific manifests (AndroidManifest.xml intent filters, iOS Associated Domains) to register the app for specific URL schemes or universal links, then using a router package like go_router to parse the incoming link and navigate to the right screen with the right parameters.

Named routes register a map of string identifiers to screen-building functions up front on MaterialApp, and you navigate using Navigator.pushNamed('/details'). The imperative API builds the destination widget directly inline with MaterialPageRoute. Named routes centralize the route map and work better with deep linking, while imperative navigation is simpler for small apps with few screens.

AnimationController drives an animation over time, producing values that interpolate between a defined range across a set duration. An Animation object, often built with a Tween attached to that controller, describes what value to interpolate, like an opacity or position, letting a widget rebuild smoothly as the controller's value changes.

Implicit animations, like AnimatedContainer or AnimatedOpacity, automatically animate a property change between its old and new value without manually managing a controller. Explicit animations require creating and driving an AnimationController directly, giving finer control over duration, curves, and coordinating multiple animations together, at the cost of more boilerplate.

Flutter DevTools provides a widget inspector to examine the tree visually, a performance view for frame timing, and a memory view for leak detection. print() statements and the debugger built into IDEs like VS Code or Android Studio, with breakpoints, are also standard tools for tracing through logic step by step.

A package is pure Dart code with no platform-specific implementation needed, like a utility library for formatting dates. A plugin includes platform-specific code (Kotlin/Java for Android, Swift/Objective-C for iOS) alongside its Dart API, needed whenever the functionality requires calling into native platform capabilities like the camera or GPS.

Null safety makes a variable's type explicitly nullable or non-nullable at compile time, using a question mark for nullable types like `String?`. This catches a large class of null reference errors during development rather than at runtime, which used to be one of the most common sources of crashes in Dart and Flutter apps before null safety became the default.

The UI thread runs Dart code, including build methods and business logic, and produces a layer tree describing what to draw. The raster thread (GPU thread) takes that layer tree and actually rasterizes it into pixels using Skia or Impeller. Work on either thread taking too long causes dropped frames, so profiling needs to identify which thread is the bottleneck.

Impeller is Flutter's newer rendering engine, designed to precompile shaders ahead of time to eliminate the shader compilation jank that Skia's just-in-time shader compilation could cause on first use of a visual effect. Impeller became the default renderer on iOS and later Android, aiming for more predictable frame times.

Flutter supports three levels. Unit tests check pure Dart logic in isolation, widget tests render a widget in a test environment and verify its behavior and appearance without a real device, and integration tests run the full app on a real or simulated device to verify end-to-end flows. A healthy test suite leans heavily on the fast unit and widget tests, with integration tests reserved for critical user journeys.

A widget test pumps the widget into a test environment, interacts with it, and asserts on the result. ```dart testWidgets('counter increments', (WidgetTester tester) async { await tester.pumpWidget(MyApp()); expect(find.text('0'), findsOneWidget); await tester.tap(find.byIcon(Icons.add)); await tester.pump(); expect(find.text('1'), findsOneWidget); }); ```

A common approach organizes code by feature rather than by type, so each feature folder holds its own widgets, state, and logic rather than scattering related code across global 'widgets', 'models', and 'screens' folders. Layering within each feature, separating presentation, business logic, and data access, keeps the codebase testable as it grows and makes it easier for multiple engineers to work in parallel without stepping on each other.

Dependency injection provides a class's dependencies from outside rather than having it construct them internally, which makes testing easier since dependencies can be swapped for mocks. In Flutter, this is commonly done with Provider or Riverpod acting as the injection mechanism, or with a dedicated package like get_it for a simple service locator pattern.

Options depend on the data's shape and complexity. Shared preferences work for small key-value settings. Sqflite or Drift fit structured relational data needing queries. Hive is a fast, lightweight option for storing Dart objects directly without a full SQL layer. I'd also design the sync logic carefully, deciding how conflicts between local and remote data get resolved when connectivity returns.

MediaQuery gives access to screen dimensions and other device metrics at runtime, which can drive conditional layout decisions. LayoutBuilder lets a widget adapt based on the constraints passed down from its parent rather than the whole screen. For broader responsiveness, packages or custom breakpoint systems switch between distinct layouts for mobile, tablet, and desktop-sized viewports.

Isolates are Dart's mechanism for concurrent execution, each with its own memory and event loop, communicating through message passing rather than shared memory. They're used to move CPU-intensive work, like parsing a large JSON payload or running image processing, off the main isolate so it doesn't block the UI thread and cause jank.

I'd check what's contributing most using tools like the app size analysis in DevTools or `flutter build apk --analyze-size`, common offenders being unused assets, unnecessarily bundling all font weights, or large third-party dependencies. Enabling split-per-ABI builds, tree-shaking icons, and compressing images before bundling are typical levers to reduce final app size.

pubspec.yaml declares a project's dependencies, assets, fonts, and metadata, including version constraints for each package. pubspec.lock records the exact resolved versions actually installed, ensuring every developer and CI run gets identical dependency versions rather than whatever satisfies the loose constraints at that moment.

Beyond just the technical characteristics of BLoC versus Riverpod versus Provider, I weigh the team's existing familiarity, how steep the learning curve is for new hires, how well the approach scales as the app and team grow, and how much boilerplate it demands for simple cases. A technically elegant solution the team fights against daily is often a worse choice than a simpler one the team already understands well.

I'd separate platform-agnostic business logic from platform-specific presentation early, using conditional imports or a platform abstraction layer for anything that genuinely differs, like file handling or navigation patterns. Layout would use responsive, constraint-based widgets rather than hardcoded mobile assumptions, and I'd budget explicit testing time on web specifically, since certain widgets and packages behave differently or aren't fully supported there.

I look at maintenance activity (recent commits, how quickly issues get addressed), whether it's null-safety and current Dart/Flutter SDK compatible, how many other production apps depend on it, and whether the maintainer has a track record across major Flutter version bumps. For anything security-sensitive or foundational to the app, I'd also read through the source rather than trusting the package description alone.

I'd start with the automated migration tooling Flutter provides, then work through breaking changes package by package rather than attempting the whole migration in one large branch. Running the full test suite continuously during the migration and doing it on a dedicated branch with frequent rebases against main keeps the change reviewable instead of becoming an unmanageable diff.

I isolate platform differences behind a clean abstraction, an interface with separate Android and iOS implementations selected via conditional imports or dependency injection, so the rest of the app calls one consistent API regardless of platform. This keeps platform-specific logic contained to a small, well-tested layer instead of scattered Platform.isIOS checks throughout business logic.

Custom painting and animation give the most control over a distinctive brand experience but cost significantly more engineering time and carry more performance risk if done carelessly. I'd reserve heavy custom UI work for the moments that matter most to the product's identity, like a signature onboarding animation, and lean on the built-in widget set for the bulk of functional screens where a polished default experience is good enough.

I'd set up automated builds triggered on merge, running static analysis, unit and widget tests, and a subset of integration tests on every pull request. Release builds would run on a separate, gated pipeline handling code signing and store submission, using fastlane or a similar tool to automate the iOS and Android store upload processes and keep version bumping and changelog generation consistent.

I'd define a shared abstract interface each provider implementation must satisfy, register the active implementation through dependency injection rather than hardcoding it, and keep provider-specific code fully isolated behind that interface. This lets a new payment provider get added or an existing one swapped out without touching the app's core checkout logic at all.

I'd get the actual device or a comparable emulator profile into the testing rotation rather than trying to guess from timing on faster hardware, since GPU and CPU differences can hide real bottlenecks. I'd also check for assumptions the team may have baked in, like image resolution, shader complexity, or list rendering that don't scale down gracefully to weaker hardware.

I look at whether that logic is genuinely reusable across multiple apps or teams, or whether it's just organizational tidiness. Pulling logic into a shared package too early adds versioning and coordination overhead for code that may still be evolving rapidly. I'd wait until a clear second consumer exists before extracting a shared package, rather than speculatively designing for reuse that may never materialize.

I'd start with an audit using the accessibility scanner tools available for both platforms to find the highest-impact gaps, then prioritize the most-used screens first rather than trying to fix everything at once. Establishing semantic labeling and dynamic text scaling as a requirement in code review going forward prevents the backlog from growing while the existing gaps get addressed incrementally.

Flutter's hot reload and expressive widget composition make it very easy for individual engineers to move fast, which is a strength, but without codified conventions that speed can produce a codebase where every screen is built slightly differently. I'd invest in a strong linter configuration, a shared component library, and code review focused specifically on architectural consistency, beyond just correctness, to keep the speed without losing coherence.

I'd weigh how far the requirement is from what composed widgets can reasonably achieve. If it needs pixel-level control, custom shapes, or an animation that doesn't map cleanly to existing widget behavior, CustomPainter is usually justified despite its added complexity. If the same visual result can be achieved by combining Stack, ClipPath, and standard widgets, I'd avoid the added maintenance burden CustomPainter code tends to carry.

I look at Google's continued investment signals, release cadence, community package ecosystem health, and how the framework has handled past architectural shifts like the move to Impeller. No framework choice is risk-free over a multi-year horizon, so I'd also make sure the app's core business logic stays reasonably decoupled from Flutter specifics, which limits the blast radius if a future migration ever became necessary.

I'd focus early on the mental model shift, Flutter's declarative, widget-rebuild-based approach differs meaningfully from imperative native UI updates, and engineers used to native patterns often fight the framework until that shift clicks. Pairing experienced Flutter engineers with the transitioning team on real feature work tends to build that intuition faster than training exercises alone.

Signals include rising bug rates in a specific area, engineers routinely avoiding touching certain files out of fear of breaking something, and feature velocity visibly slowing in a part of the codebase that used to move quickly. I prefer incremental refactors scoped to the worst offenders over a full rewrite, since rewrites carry high risk and rarely deliver on their promised timeline.

I'd push for a small, contained pilot rather than a binding upfront decision, letting the team gather real data on stability and performance before committing broadly. Framing the debate around what evidence would change each person's mind tends to move the conversation forward faster than a purely principled argument about risk tolerance.

It depends heavily on the product's actual usage patterns and business priorities rather than a general preference. If web is a minor, secondary surface, I'd rather ship a good mobile experience and a basic, functional web version than spread engineering effort thin trying to perfect both simultaneously. That calculus changes for a product where web genuinely drives a meaningful share of usage or revenue.

I'd point to the compounding cost of duplicated, slightly-inconsistent UI code across teams, the design review overhead it creates, and the onboarding friction for new engineers who have to relearn conventions team by team. A shared component library pays for itself once an organization crosses roughly a handful of product teams, and I'd frame the investment around velocity and consistency rather than aesthetics alone.

I weigh how someone reasons about state management tradeoffs and rendering performance over how many widget names they have memorized. Walking through a real bug they debugged, especially something subtle like an unexpected rebuild cascade, reveals far more about their depth than a quiz on Flutter trivia. I also pay attention to how they think about testing and long-term maintainability, beyond just whether the feature works.

I weigh the security and support cost of maintaining backward compatibility against the actual proportion of users still on old versions, usually visible through analytics. A soft in-app nudge for most cases, escalating to a hard update requirement only when a version has a serious security issue or when supporting it is genuinely blocking the team from shipping, tends to balance user disruption against engineering cost reasonably.

I frame it around the business risk of not doing it, slower feature delivery over time, harder-to-fix bugs, difficulty onboarding new engineers, rather than technical purity. I also propose a phased rollout timeline that doesn't fully block new feature work, so stakeholders see the migration as parallel progress rather than a pause on the roadmap they care about.

I focus reviewers on the things automation can't catch, architectural fit, edge cases, and readability, while linting and CI checks handle formatting and mechanical issues automatically so reviewers aren't spending time on things a machine should have caught. Setting an expectation of same-day review turnaround keeps review from becoming a bottleneck while still preserving its value.

I try to make technical debt visible in terms stakeholders care about, tickets taking longer than they should, bugs recurring in the same area, rather than treating it as an abstract concern only engineers understand. Framing a debt-reduction effort around a specific upcoming feature it will unblock or accelerate tends to get far more buy-in than asking for dedicated cleanup time in the abstract.

I'd start with something concrete and useful, like a shared component library or a set of documented architecture patterns, rather than leading with meetings or a charter document. Regular, lightweight knowledge-sharing sessions where teams present real problems they solved tend to build more genuine cross-team alignment than top-down mandates, and participation naturally grows once teams see tangible value coming out of it.

I weigh genuine excitement against actual business value carefully, since novelty alone isn't a good enough reason to divert roadmap time. I'll usually greenlight a small, timeboxed exploration so the team's curiosity gets an outlet without derailing committed work, and only expand that investment once the exploration surfaces a concrete benefit worth prioritizing over what's already planned.