Flutter Developer interview questions
The 8 questions that actually come up, each with what a strong answer covers. These are not scripts to memorise — interviewers can tell — they are the shape of the answer that gets a yes.
8 questionsFlutter Developer career guide →
Explain the difference between StatelessWidget, StatefulWidget and an InheritedWidget.
What a strong answer coversBeyond definitions: WHEN each rebuilds and what that costs. Bonus for explaining why most state now lives in providers instead of setState.
What actually happens in a widget rebuild? Why is Flutter still fast?
What a strong answer coversWidget → Element → RenderObject trees. Widgets are cheap descriptions; the element tree diffing is what makes rebuilds affordable.
How do you decide between Riverpod, Bloc and Provider?
What a strong answer coversThere is no universal winner — they test whether you can justify a choice for team size, testability and app complexity without religion.
A list screen janks while scrolling. Debug it.
What a strong answer coversDevTools timeline first: builds vs raster. ListView.builder, const constructors, image caching/precacheImage, and moving work off the UI isolate.
How do platform channels work, and when have you needed one?
What a strong answer coversMethodChannel/EventChannel mechanics plus a REAL example (a payment SDK, background service, native camera). Theory alone reads as inexperience.
Release build crashes that debug never showed — what classes of bug do that?
What a strong answer coversStripped asserts (layout contract violations), tree-shaken reflection, minification issues, and race conditions timing changes. Mention testing in --profile/--release.
How do you structure a Flutter app so business logic is testable?
What a strong answer coversLayers: widgets thin, logic in providers/blocs, data in repositories. Unit-test logic, widget-test screens, one or two integration flows.
How do you handle an API that sends numbers as strings?
What a strong answer coversDefensive parsing at the model boundary (tryParse, typed fromJson), never `as num` deep in a build method — one bad cast should not grey-screen a release.