Flutter Developer interview questions

I make absence explicit in the type and avoid weakening the model with broad null assertions.

• A field that may genuinely be absent is T?, and a successful null check promotes a stable local variable to T.
• For required staged initialization, I prefer a constructor or factory; late is reserved for an enforced initialization contract and throws if read too early.
• The ! operator is only appropriate at a boundary where an external invariant has already been checked, because it converts a compiler warning into a possible runtime failure.

I use a bound to state the operations T must support, then account for Dart's covariant generic classes at mutation boundaries.

• T extends Object excludes null, while a domain bound such as T extends Comparable<T> lets the implementation call compareTo safely.
• Because List<Cat> is a subtype of List<Animal>, writing a Dog through an Animal view is guarded by a runtime type check and can fail.
• For callbacks I follow function variance: parameter types are contravariant and return types covariant, so the accepted producer or consumer type matters.

I use an extension method to add focused compile-time API to a type I do not own without changing its runtime identity.

• Resolution uses the receiver's static type, so an extension is not virtual dispatch and a value typed as dynamic will not use it.
• A real instance member wins over an extension member, and overlapping equally specific extensions can make the call ambiguous.
• I resolve a collision with an explicit extension override or import prefixes rather than relying on a cast that obscures intent.

I choose a class modifier by deciding which forms of external subtyping the package promises to support as its API evolves.

• A base class permits external inheritance but not implementation, so subclasses inherit its implementation and must remain base, final, or sealed, leaving room to add concrete members safely.
• An interface class permits external implementation but not inheritance, which exposes a substitutability contract and makes adding a required member a breaking change for implementers.
• A final class blocks external subtyping, while a sealed class also defines a library-controlled subtype family for exhaustive switching, so adding a sealed variant deliberately creates migration work.

I use an extension type when an existing representation needs a distinct static API without paying for a wrapper object at runtime.

• In extension type UserId(String value), String is the representation type and value is the representation field; declared members expose only the domain operations the boundary should offer.
• The value is represented at runtime by the underlying String, so calls and storage can avoid wrapper allocation, but runtimeType, dynamic code, and runtime inspection cannot rely on a distinct UserId object.
• This zero-cost boundary suits validated IDs and interop values when compile-time separation is enough; I choose a class when runtime identity, encapsulated mutable state, or an unpierceable runtime boundary matters.

After synchronous code finishes, Dart drains microtasks before taking the next event from the event queue.

• Future.microtask and scheduleMicrotask run ahead of timers, I/O completions, and other queued events already waiting.
• A long synchronous callback or a self-replenishing microtask chain starves rendering and input even though the code is asynchronous in shape.
• I use microtasks only for small ordering-sensitive work and schedule ordinary deferred work as events or move CPU work to an isolate.

A Future API should complete once with either a value or an error and preserve one clear asynchronous error path.

• A function declared async converts a thrown exception into an errored Future, including throws before its first await.
• then can provide onError, but catchError must return a value compatible with the Future type if it recovers; otherwise I rethrow with stack context.
• I await or return every meaningful Future so errors reach the caller instead of becoming unhandled zone errors.

I choose a single-subscription stream for one owned sequence and a broadcast stream for independent observers of live events.

• A single-subscription stream can be listened to once and is suitable for file, socket, or generated data whose source should follow one consumer.
• A broadcast stream may drop events when nobody is listening, and pausing one subscription does not globally pause the producer for every listener.
• pause and resume can apply backpressure when the source honors them; otherwise buffering must be bounded or the protocol must define dropping, sampling, or acknowledgement.

An isolate has its own event loop and mutable heap, so coordination happens through messages rather than shared mutable objects.

• SendPort messages must be sendable; mutable object graphs are logically copied, while the runtime may optimize immutable values.
• TransferableTypedData moves large byte payloads without retaining two usable mutable copies, which is better for image or file processing.
• I keep messages coarse enough to offset spawn and serialization costs and return plain results or domain DTOs to the UI isolate.

The garbage collector reclaims unreachable Dart objects, but it does not provide deterministic release of external resources.

• Each isolate owns its heap, and references from roots such as stacks, statics, closures, and active callbacks keep objects reachable.
• Short-lived and long-lived objects are handled by generational collection, so retaining a large graph through one listener can promote and preserve the whole graph.
• Sockets, stream subscriptions, controllers, and native handles need explicit close or dispose; Finalizer is only a fallback because collection timing is unspecified.

Flutter retains an existing Element only when the new widget has the same runtimeType and key, making identity a deliberate part of stateful tree design.

• When both match, the Element updates in place and a StatefulElement keeps its State, with didUpdateWidget receiving the previous configuration.
• When either differs, Flutter deactivates the old Element and inflates a new one at that slot, so local State is not transferred and is disposed if the old Element is not reused.
• A matching GlobalKey can reparent its existing Element and State to another location in the same frame, but uniqueness, deactivation, and inherited-dependency updates make it a costly tool for intentional subtree identity.

A ParentDataWidget writes parent-specific layout metadata onto its child's RenderObject for the matching parent RenderObject to consume.

• Expanded applies FlexParentData such as flex and fit for a Row, Column, or Flex, while Positioned applies StackParentData coordinates for a Stack.
• The ParentDataWidget must reach a child RenderObject owned by that compatible render parent without an intervening incompatible RenderObjectWidget, or the metadata type and layout protocol no longer agree.
• To diagnose the error, I inspect the ownership chain named in the message, compare the expected ParentData type with the actual render parent, and move the widget under the parent that owns that contract.

Slivers participate in a viewport protocol that lays out only the portion needed for the current scroll position and cache extent.

• SliverConstraints include scroll offset, axis, remaining paint extent, and cross-axis extent rather than ordinary BoxConstraints alone.
• A sliver returns SliverGeometry describing paint extent, scroll extent, and visibility so the viewport can compose headers, lists, and grids.
• CustomScrollView lets SliverAppBar, SliverList, and SliverGrid share one coherent scroll position without nesting competing scrollables.

Build updates configuration, layout computes geometry, paint records drawing commands, and compositing assembles layers for the engine.

• setState marks an element dirty for build; changed parent data or render properties may then mark a RenderObject for layout or paint.
• Layout follows constraints through the render tree, while paint writes into a retained layer structure rather than directly changing screen pixels.
• Compositing sends the resulting layer scene to the engine, where rasterization turns it into a frame.

RepaintBoundary isolates a render subtree so a repaint on one side does not automatically repaint the other side.

• It helps when a frequently animated child sits beside expensive mostly static content, which can then reuse a cached layer.
• It does not prevent widget rebuilds or layout, so adding it cannot fix every kind of frame cost.
• Each boundary can add a composited layer and memory overhead, so I add it around measured repaint hotspots rather than every widget.

Local keys identify siblings under one parent, while a GlobalKey can identify and reparent one element across the whole app.

• ValueKey works when stable domain identity distinguishes repeated children, and ObjectKey uses object identity.
• GlobalKey can expose State or BuildContext and preserve a subtree during reparenting, but that work triggers dependency updates and is comparatively expensive.
• I avoid creating keys inside build and prefer callbacks or controllers over GlobalKey when cross-tree identity is not actually required.

InheritedWidget lets descendants register a dependency that rebuilds them when the inherited value meaningfully changes.

• Calling dependOnInheritedWidgetOfExactType records the current Element as a dependent; a non-listening lookup does not.
• updateShouldNotify compares old and new widgets and should report only changes relevant to consumers of that inherited value.
• For large models I use selectors or InheritedModel-style aspects so one field change does not rebuild every consumer.

I schedule work according to whether it must affect the current frame, run after it, or wait as ordinary asynchronous work.

• A persistent frame callback such as a Ticker drives animation each frame, while a transient callback schedules one frame-bound update.
• addPostFrameCallback runs after the current frame is flushed and is appropriate for reading final layout, but it does not itself request another frame.
• I avoid starting a recurring post-frame loop because it can hide lifecycle bugs and consume every frame.

At 120 Hz the whole frame is about 8.3 ms, so UI and raster work must both remain consistently below their deadlines.

• Build, layout, and paint execute on the UI isolate, where synchronous parsing or broad rebuilds delay scene production.
• Raster work includes drawing and layer effects, so expensive clipping, saveLayer, or oversized images can miss the raster deadline even with a fast build.
• I inspect UI and raster timelines in profile mode and reduce the phase that actually exceeds budget rather than optimizing widget count blindly.

I write a custom RenderObject only when the feature needs a layout, paint, or hit-test protocol that widget composition cannot express efficiently.

• Examples include one-pass positioning of many children, unusual parent data, or tightly coupled painting and semantics.
• The RenderObject must implement constraint-respecting layout, invalidation setters, painting, hit testing, and accessibility semantics where applicable.
• For ordinary decoration or drawing I prefer CustomPainter, and for standard layouts I keep composition because it is easier to test and maintain.