Flutter Developer interview questions

I would use a feature-first package graph with one app composition root and enforce its edges in CI.

• Each business feature exposes a small api package and keeps widgets, Riverpod providers or BLoCs, repositories, and DTOs in an implementation package owned by one team.
• Shared Dart domain types live in low-churn core packages, while Swift, Kotlin, and plugin code stays behind a platform package so features never import host details.
• CODEOWNERS plus a dependency-graph check reject implementation-to-implementation imports, and affected-package tests keep the p95 pull-request path below 12 minutes.
• I would accept extra boundary models only where they let the 5 teams release changes without editing another team's implementation.

I would remove cycles through narrow contracts, then optimize the measured high-fan-out packages rather than merging everything.

• I would map imports and change frequency, then extract route, result, and domain interfaces from the smallest stable seam that breaks each of the 11 cycles.
• Volatile shared UI and utility packages would be split by ownership or moved back into their consumers; only stable primitives may have more than 15 dependents.
• A CI graph task would reject cycles, forbidden feature edges, and public imports of another package's src directory.
• I would keep the new graph only if all cycles disappear and incremental analysis of an affected feature falls below 90 seconds.

I would give checkout one accountable owner and replace cross-team implementation edits with consumer-owned contracts.

• The checkout team owns its state, UI, analytics, and orchestration, while payments, identity, and catalog publish narrow capabilities with explicit maintainers and compatibility tests.
• CODEOWNERS requires the owning team on implementation changes, but contract changes require one consumer and one provider reviewer rather than all 5 teams.
• Quarterly ownership reports track unowned packages, approval latency, and cross-team edits, with a target of at most one external approval for a normal checkout change.
• Shared code moves to a platform owner only after at least 3 features need the same stable behavior, not merely similar syntax.

I would keep typed destinations in API packages and let the app shell resolve them to concrete builders.

• Each feature publishes Dart 3 sealed route inputs and typed results containing stable IDs, never Widget classes, GoRouter instances, or repository types.
• The app composition root registers all 24 handlers and maps the 8 validated deep links through the same route parser, including authentication and prerequisite checks.
• Contract tests verify route serialization, unknown versions, back behavior, and that every registration resolves exactly once.
• A package graph gate enforces zero implementation-to-implementation edges, accepting centralized assembly in exchange for auditable navigation.

I would start with a regular package and choose deferred delivery or a plugin only for a measured boundary, not for team independence alone.

• A plugin is justified when the feature owns Swift or Kotlin APIs; it does not make Dart code independently deployable and adds platform versioning work.
• Android deferred components may reduce the base download, but iOS still ships the code in the app, so I would measure platform-specific size and p95 first-open latency.
• A runtime micro-frontend adds routing, dependency, observability, and compatibility failure modes without App Store-independent iOS code delivery.
• I would defer the feature only if p95 first open stays below 4 seconds; otherwise I would reduce assets or bundle it for predictable entry.

I would expose one Dart capability contract and keep both native implementations behind a federated plugin boundary.

• The app-facing package defines typed camera commands, results, errors, and lifecycle states without AVFoundation or CameraX types.
• Swift and Kotlin packages implement the contract and own thread hops, permission mapping, resource cleanup, and native test fixtures.
• The Dart adapter normalizes only behavior that must match, while platform-specific capabilities remain explicit rather than forced into a false common denominator.
• Integration benchmarks measure p95 command round trips below 50 ms on both platforms, including serialization and main-thread dispatch.

I would use Pigeon because generated typed interfaces satisfy the compile-time contract better than handwritten MethodChannel maps.

• The Pigeon schema defines nullable fields, enums, structured errors, and async host methods, then generates matching Dart, Swift, and Kotlin code in CI.
• A thin adapter keeps generated types out of the domain layer so schema regeneration does not spread across 14 call sites.
• MethodChannel remains suitable for one small experimental call, but string method names and dynamic maps move failures to runtime.
• CI regenerates code and fails on a diff, while compatibility tests run the previous Dart client against the current native host.

I would separate native transfer state from UI sampling and make subscription lifetime explicit.

• Native code emits typed snapshots with file ID, monotonic sequence, bytes, and terminal state on one serialized queue, never one channel per progress tick.
• The Dart adapter coalesces each file to at most 10 updates per second but always delivers completion and failure without dropping them.
• onListen registers one observer and onCancel removes it, with resubscription returning the latest snapshot so a rebuilt view does not reset progress.
• A 60-second test verifies bounded memory, no missing terminal events, and UI data age below 150 ms for all 20 files.

I would use FFI for the hot synchronous buffer path and keep platform channels for operating-system services.

• FFI avoids repeated codec serialization, and NativeCallable or a narrow C ABI keeps the boundary stable across Swift, Kotlin, and Dart wrappers.
• Buffers use explicit ownership and reused native allocations; every allocation and release is covered by stress tests and AddressSanitizer on native builds.
• Calls run outside the UI isolate when they can exceed the frame budget, because FFI itself does not make CPU work asynchronous.
• I would require p95 end-to-end work below 16.7 ms and no memory growth after 100,000 calls before accepting the native complexity.

I would version the capability contract separately from the plugin package and model lifecycle transitions explicitly.

• The Dart interface negotiates a contract version and capabilities, rejecting an unsupported major version while allowing additive optional fields within a major line.
• Android attaches resources to ActivityAware callbacks and releases them on configuration detachment; iOS responds to scene activation and disconnection without assuming one global window.
• Pending calls receive a typed unavailable or cancelled result during host loss, and reattachment recreates observers without duplicating them.
• A matrix tests 3 Flutter release lines, Activity recreation, 2 iOS scenes, and old-Dart-to-new-host compatibility before publication.

I would treat 16.7 ms as the full frame interval and profile UI and raster work separately because either can miss vsync.

• DevTools frame charts and a release or profile build identify whether build, layout, paint, rasterization, or GPU submission owns the slow frames.
• I would keep p95 UI and raster durations each below about 8 ms to leave scheduling headroom, rather than allowing either side to consume the entire interval.
• Timeline events around the animation correlate a named interaction with shader, image decode, saveLayer, or layout cost on the target device.
• The change passes only when slow frames fall below 2 percent across 20 identical traces, not when the average improves.

I would narrow configuration updates at the element layer and painting invalidation at the render layer instead of optimizing the whole tree blindly.

• Immutable widgets describe configuration, elements retain identity and state, and render objects perform layout and paint, so stable keys and const subtrees reduce unnecessary element updates.
• The counter value is selected at the smallest consumer through Riverpod select or a focused ListenableBuilder, keeping the other 599 widget configurations unchanged.
• A RepaintBoundary isolates the animated region only if DevTools repaint visualization proves surrounding pixels repaint; too many boundaries waste layers and memory.
• I would compare build counts and raster time over 100 updates, requiring only the counter subtree to rebuild and p95 paint below 4 ms.

I would compose lazy slivers and preserve stable item identity so the viewport creates only nearby rows.

• A CustomScrollView combines SliverPersistentHeader for months with SliverList or SliverVariedExtentList when extents are known cheaply, avoiding shrinkWrap and nested scrolling lists.
• Rows use stable backend IDs, presentation-ready models, and bounded keep-alive only for the few controls that must retain local UI state.
• Pagination retains a window around the viewport and evicts decoded images through the image cache rather than holding models for all 50,000 rendered children.
• A scroll benchmark must keep peak RSS below 120 MB and p95 frame time below 16.7 ms on the lowest supported device.

I would use a custom RenderObject only after proving existing slivers cannot express the two-axis virtualization within budget.

• The render object would compute visible row and column ranges from constraints and scroll offsets, then lay out only cells intersecting the viewport plus a small cache extent.
• It would separate layout inputs from paint-only selection changes, implement hit testing and semantics, and avoid intrinsic measurement across all 2,000 cells.
• I would first prototype with existing two-dimensional scrolling primitives because custom layout carries long-term accessibility, gesture, and framework-upgrade costs.
• The custom path is accepted only if p95 layout drops below 8 ms and semantics tests cover keyboard and screen-reader traversal.

I would profile the Impeller path and asset workload rather than assume all shader-related hitches disappeared automatically.

• A profile build with Perfetto and Flutter timeline data separates Dart work, texture upload, pipeline creation, raster time, and GPU completion during the first animation.
• I would simplify unsupported or expensive effects, reduce large saveLayer regions, and warm only the small deterministic animation path if pipeline creation is proven dominant.
• The 3 GPU models stay in the benchmark matrix because driver behavior and texture limits can differ even under Impeller's precompiled shader model.
• Release requires first-run p95 below 16.7 ms or an intentional reduced-motion fallback, with no visual mismatch in golden or screenshot checks.

I would isolate stable expensive content from moving markers, then keep only boundaries that produce measured raster savings.

• Static labels and map decoration may share one RepaintBoundary if they remain unchanged across marker ticks, while animated markers paint in a separate lightweight layer.
• I would inspect raster-cache entries and repaint rainbow output, removing per-label boundaries whose cached textures cost more than repainting their simple text.
• Large images are decoded near display size and reused by cache key, while transient transformed layers avoid forced caching unless repeated frames amortize the upload.
• The target is less than 15 MB raster-cache growth and p95 raster time below 8 ms over a 60-second animation.

I would separate the scene model, viewport transform, interaction overlay, and semantic representation so each can update at its own rate.

• A CustomPainter or render object draws visible nodes from a spatial index, while selection handles and cursors repaint independently without rebuilding the 500-node model.
• Pointer, keyboard, and focus commands feed one deterministic Dart 3 sealed-action reducer with undo records, rather than mutating canvas objects directly.
• Semantics exposes selected and nearby nodes as navigable controls even though the visual canvas is custom, and reduced-motion settings disable nonessential transitions.
• Benchmarks cover pan, zoom, multi-select, and undo with p95 frame time below 16.7 ms and hit-test latency below 50 ms.

I would benchmark from process start to the first usable frame and optimize only traced work on that critical path.

• Flutter integration or native macrobenchmarks run at least 30 cold starts in profile or release mode with identical device state, separating engine start, Dart initialization, plugin registration, and first-frame work.
• Only crash reporting and launch-critical configuration stay synchronous; analytics, remote config, database warming, and noninitial routes initialize on first use.
• The first screen uses small local assets and no blocking network dependency, while Dart 3 startup code avoids eagerly constructing the full provider graph.
• I would gate p95 below 1.5 seconds and require warm-start p95 not to regress by more than 5 percent.

I would separate retained-object leaks, decoded-image pressure, and native allocations before changing cache limits.

• DevTools heap snapshots and retaining paths compare visits 2 and 10, while Android Studio or Instruments confirms whether the missing memory sits in Dart, GPU textures, or native plugins.
• Controllers, stream subscriptions, and Riverpod auto-dispose scopes must release with the route; a repeat test requires zero retained gallery owners after collection.
• Decoded images get a measured ImageCache byte limit and target-size decoding, accepting redecodes to keep peak RSS below 210 MB.
• A 15-minute gallery loop passes only if post-GC memory returns within 10 MB of the second-visit baseline and no out-of-memory kill occurs.

I would request, decode, and cache thumbnails at their displayed pixel size instead of moving 12 MP images through the UI path.

• The CDN supplies width, format, and quality variants, while cacheWidth or ResizeImage limits local decoding when a server variant is unavailable.
• The list prefetches only a small viewport window, caps concurrent fetches, and cancels work for rows that leave the window before decode.
• Memory cache stores decoded thumbnails under a byte budget, disk cache stores compressed responses, and full resolution loads only in the detail view.
• Benchmarks require first visible thumbnails within 500 ms, peak RSS below 220 MB, and no more than 8 concurrent decodes.