25 Flutter interview questions

Listen for: A strong answer mentions reproducing with slow network or artificial delay, reading the exception, checking widget lifecycle, and guarding updates with mounted or cancellation. They should distinguish quick fixes from better structure, such as moving async loading into a controller, FutureProvider, Bloc, or Riverpod AsyncValue with clear loading, error, and success states.

Red flag: They only say to ignore the error or wrap everything in try/catch without addressing lifecycle.

Listen for: Look for use of constraints rather than device names: LayoutBuilder, MediaQuery, Flexible, Expanded, Wrap, SliverGrid, and adaptive breakpoints owned by the app. They should mention testing with text scaling, landscape, browser resizing, and avoiding fixed pixel sizes except where intentional. Good candidates discuss overflow debugging and design negotiation.

Red flag: They propose separate screens for every device size as the default approach.

Listen for: They should separate ephemeral widget state, feature state, and persisted state. Good signals include TextEditingController disposal, debouncing input, representing loading and error states, and avoiding global state for purely local UI. They may use ChangeNotifier, ValueNotifier, Riverpod, Bloc, or Cubit, but should justify the scope and lifecycle.

Red flag: They say all state should go into one global provider because it is simpler.

Listen for: A strong junior answer uses Flutter DevTools, performance overlay, and profile mode instead of guessing. They should mention image sizes, caching, list item rebuilds, const widgets where useful, ListView.builder, repaint boundaries, and avoiding expensive work in build. Bonus for checking shader compilation, Impeller behavior, and using cached_network_image carefully.

Red flag: They assume Flutter is slow and suggest rewriting the screen natively before profiling.

Listen for: They should describe a mix of unit tests for validators or controller logic, widget tests for form behavior and error messages, and integration tests for happy-path flow with mocked or test backend services. Good answers mention dependency injection, pumping frames correctly, avoiding real network calls, and testing accessibility labels or focus behavior where relevant.

Red flag: They only test manually because UI tests are too hard.

Listen for: Listen for a methodical path: inspect pubspec.lock, package changelog, Android Gradle Plugin and Kotlin compatibility, minSdk requirements, ProGuard/R8 rules, permissions, and native plugin setup. They should compare debug versus release behavior, run flutter build apk/appbundle with verbose logs, and consider pinning or replacing the package.

Red flag: They immediately delete the package without trying to understand the native build error.

Listen for: A strong answer models pagination explicitly: initial load, next page, refreshing, error, and empty states. They should avoid duplicate requests, handle cancellation or stale responses, and keep scroll controllers or PageStorageKey where appropriate. Good candidates discuss repository boundaries, cached data, stable item keys, and test cases for edge conditions.

Red flag: They put all pagination logic directly in the widget build method.

Listen for: Look for separation between UI, state/controller layer, domain rules, and data sources. They should use interfaces or fakes for tests, avoid leaking BuildContext into business logic, and keep providers/blocs scoped to feature lifecycles. Strong answers acknowledge trade-offs and do not treat the chosen package as a complete architecture.

Red flag: They argue one state management library solves most design problems by itself.

Listen for: They should ask for logs, HTTP status codes, timeouts, DNS/TLS errors, device OS versions, app version, backend correlation IDs, and network quality. Good answers mention instrumenting Dio or http interceptors, redacting sensitive data, retry policy with backoff only for safe operations, and distinguishing client bugs from backend or connectivity issues.

Red flag: They add aggressive retries to every request without understanding idempotency or user impact.

Listen for: Strong candidates discuss declarative routing, often with go_router or auto_route, redirect rules based on auth state, nested navigators for tabs, deep link parsing, and back button behavior on Android and web. They should cover testability, route names versus typed routes, and avoiding business logic spread through onPressed handlers.

Red flag: They rely on pushing anonymous routes everywhere and handle auth with ad hoc checks per screen.

Listen for: Listen for controlling dependencies: fake repositories, fake clocks where useful, shorter or disabled animations, pump and pumpAndSettle used carefully, and asserting states step by step. Good answers avoid overusing arbitrary delays. They should know when to move logic into unit tests and keep widget tests focused on rendering and interaction.

Red flag: They solve it by increasing sleeps until the test usually passes.

Listen for: A good answer covers Dart defines, separate bundle IDs/application IDs, icons/names, Firebase or analytics config, API base URLs, signing, CI variables, and preventing production secrets from landing in source. They should mention validating the visible environment in-app and guarding release pipelines against accidentally shipping staging builds.

Red flag: They hardcode environment URLs and switch them manually before release.

Listen for: They should mention platform channel or federated plugin choices, Android/iOS permission flows, lifecycle callbacks, Gradle/CocoaPods or Swift Package Manager issues, ProGuard/R8, background modes, privacy manifests, and testing on real devices. Strong candidates isolate native SDK code behind a Dart interface and define fallback behavior for unsupported platforms.

Red flag: They assume adding a plugin is always just a pubspec change.

Listen for: Strong answers define boundaries by product capability, not technical layers alone. They discuss packages, Melos or workspaces, dependency rules, shared design system ownership, code generation boundaries, build_runner costs, and migration strategy. They should balance strictness with developer experience and explain how to measure whether modularization is helping.

Red flag: They propose a large rewrite into many packages before understanding team pain points.

Listen for: Look for profiling in profile mode, performance budgets for key flows, DevTools traces, frame timing capture, image and list guidelines, shader/Impeller awareness, and CI checks where practical. Senior candidates connect performance to code review, design review, low-end devices, startup time, binary size, and regression investigation.

Red flag: They treat performance as something only one specialist checks at the end.

Listen for: They should discuss data ownership, conflict resolution, sync queues, idempotency, local persistence choices such as Drift, Isar, Hive, or SQLite, encryption needs, failure UX, and backend API support. Strong answers define which operations must work offline, which can be read-only, and how to test recovery after app termination.

Red flag: They say to cache everything locally without addressing conflicts or data freshness.

Listen for: A good answer starts with inventory: SDK constraints, package compatibility, native build tooling, null safety gaps if any, deprecated APIs, lints, and CI. They propose incremental upgrades, automated fixes, strong test coverage, release risk management, and taking advantage of Dart 3 features like sealed classes or records where they improve clarity.

Red flag: They want to upgrade every dependency and refactor architecture in one release.

Listen for: Listen for calm incident handling: crash analytics triage, affected versions/devices, symbolication, logs, rollback or phased rollout pause, hotfix branch, reproduction, and communication. They should mention feature flags or remote config if present, writing a regression test afterward, and improving release gates without blaming QA.

Red flag: They focus on finding who caused the bug before containing the issue.

Listen for: Strong signals include checking state ownership, rebuild scope, accessibility, error and empty states, lifecycle disposal, route behavior, platform differences, tests, analytics privacy, and performance implications. They should tailor review depth to risk and leave actionable feedback. Seniors should also mentor through review without turning every PR into a redesign.

Red flag: They mostly review formatting and rely on QA to catch behavior problems.

Listen for: They should evaluate platform maturity, required native APIs, performance needs, team skill, plugin availability, accessibility, release constraints, and long-term maintenance. Good answers consider hybrid approaches and prototypes with clear acceptance criteria. They avoid both framework loyalty and premature native rewrites.

Red flag: They say Flutter is always the best choice because one codebase is enough.

Listen for: Look for clear layering: UI, state/controllers, domain, repositories, secure storage, and local cache. Strong answers cover biometric unlock limitations, token refresh, encrypted persistence, redaction in logs, pull-to-refresh, stale data indicators, and disabling risky actions offline. They should address accessibility, test strategy, and failure states for each data source.

Red flag: They cache sensitive financial data casually and focus only on screen layout.

Listen for: A strong design uses flavors or build variants, configuration objects, theming with Material 3 tokens where applicable, feature flags, brand assets, and CI lanes per brand. They should avoid copy-paste apps, define boundaries for brand-specific behavior, and plan automated visual checks or golden tests for regressions.

Red flag: They create separate branches or duplicated projects for each brand by default.

Listen for: Listen for transport trade-offs such as WebSocket, SSE, or push, message ordering, optimistic sends, retries, read receipts, pagination, local storage, and attachment upload states. They should discuss background notification handling, permissions, deep links to conversations, web constraints, and virtualization for long lists with stable keys.

Red flag: They assume real-time chat is just a ListView plus a WebSocket.

Listen for: Good answers cover pinned Flutter/Dart versions, dependency caching, formatting, analyzer, unit/widget/integration tests, code generation, flavor builds, signing, store artifacts, release notes, symbol files, and environment protection. They should mention running integration tests on emulators or device farms where useful and keeping secrets out of logs.

Red flag: They rely on one developer’s laptop for signed release builds.

Listen for: Strong candidates define tokens, typography, spacing, color roles, components, accessibility rules, examples, and versioning. They discuss Material 3 customization, golden tests, documentation with Storybook-like tools such as Widgetbook, migration paths, and governance for changes. They should avoid making teams fork components for minor differences.

Red flag: They create a folder of reusable widgets without ownership, documentation, or compatibility rules.