Flutter interviews look like a list of unrelated topics — widgets, state management, isolates, build modes — and candidates prepare them as a list. Then a follow-up connects two of them and the answer falls apart.

They aren't unrelated. Almost everything a Flutter interviewer asks follows from one decision the framework made: Flutter does not use the platform's UI components. It draws every pixel itself. Rebuilding, keys, platform channels, accessibility, app size — all of it is downstream of that, and most of what isn't is downstream of how Flutter compiles.

So the sections below aren't topics. They're consequences.

1
Fact the whole framework follows from
3
Trees Flutter keeps — the middle one explains most bugs
0
Performance conclusions you can draw from a debug build

If you also work in React Native, the sibling list is here: React Native Interview Questions.

Because Flutter draws its own widgets

The opening round. Where the mental model either exists or doesn't.

  1. What actually happens when you call setState?
  2. StatelessWidget or StatefulWidget — what is the real difference between them?
  3. What are the widget, element and render trees, and why does Flutter keep three?
  4. What is a Key for, and when does leaving one out cause a visible bug?
  5. Why is const on a widget constructor more than a style preference?

Saying it out loud: question 3 is the one that separates people who use Flutter from people who understand it, and the trap is reciting the three names. Say what each one is for: "The widget tree is just configuration — cheap, immutable, thrown away and rebuilt constantly. The element tree is the one that persists and holds state, and it decides whether a rebuild can reuse the existing element or has to create a new one. The render tree does layout and painting. Most of the confusing bugs I've hit live in the middle tree — state attaching to the wrong element after a list reorders." That last sentence sets up question 4 without being asked.

Question 5 has a better answer than "it's a performance optimisation". A const widget is canonicalised at compile time, so the same instance is reused and the framework can skip rebuilding that subtree entirely — which matters precisely because rebuilds happen constantly.

Because rebuilding is cheap

Middle-level. The section with the most opinions and the fewest right answers.

  1. How do you decide where a piece of state should live?
  2. InheritedWidget, Provider, Riverpod, BLoC — how do you choose?
  3. How do you stop a rebuild from cascading through an entire screen?
  4. What is BuildContext, really — and how do you end up with the wrong one?
  5. Async work finishes after the user has left the screen. What do you do?

Saying it out loud: question 7 is where candidates most often audition for a side. Interviewers are not looking for your favourite; they're looking for whether you can name what each one costs: "For state that one subtree needs, I'd rather lift it and pass it down than reach for a library at all. Provider is enough for most app-level state. I'd move to something with more structure when the state has real transitions worth testing separately from the UI. And the honest cost of the heavier options is that a new person on the team spends their first week learning the pattern instead of the product." Naming the team cost is what makes it sound like a decision rather than a preference.

Question 10 is a correctness question wearing an async costume. The answer they want is that you check the widget is still mounted before touching state, and that anything the screen owns gets cancelled or ignored when the screen goes — not a general lecture about futures.

Notice what happened between those two sections. Almost every question in the second one only exists because of the answer to the first. Rebuilds are constant and cheap, therefore where state lives matters, therefore an unnecessary rebuild has to be stopped structurally rather than avoided. In an interview you can say that connection out loud — “this follows from rebuilds being cheap” — and it does more for you than any single fact, because it shows the model rather than the memory.

Because it isn't the platform's UI

Where Flutter's central tradeoff shows up, and where native-experienced interviewers probe hardest.

  1. Material or Cupertino — do you ship one design or two?
  2. How do you call platform code when no package exists?
  3. What has to be handled deliberately for accessibility when the framework draws its own widgets?
  4. How do you deal with keyboards, text input and safe areas across both platforms?

Saying it out loud: question 13 is the one candidates most often have nothing real to say about, which makes a concrete answer disproportionately valuable: "Because Flutter paints its own widgets, the platform screen reader sees Flutter's semantics tree, not native views — so anything I build by hand out of gestures and custom painting is invisible unless I describe it. Standard widgets come with semantics; custom ones do not, and that's where it breaks. I check with the screen reader on and with text scaled up, because oversized text is what actually breaks custom layouts."

The platform half of this — what the device is doing underneath — is its own conversation: iOS Developer Interview Questions and Android Developer Interview Questions.

Because Dart isn't the language you came from

Almost everyone learned Dart second. Interviewers know, and calibrate on it.

  1. Future, Stream, async* — when do you reach for each?
  2. What is an isolate, and when do you genuinely need one?
  3. What did sound null safety change about how you write code?

Saying it out loud: question 16 has a wrong answer that sounds knowledgeable — treating isolates as Dart's thread pool. Draw the line where it actually is: "Dart is single-threaded with an event loop, so async gets you concurrency but not parallelism — an await never blocks, but a long synchronous computation still freezes the frame. An isolate is a separate memory heap for genuinely CPU-bound work: parsing a very large payload, image processing. They don't share memory, so everything crosses as messages, and that copying cost is exactly why you don't reach for one by default."

Because it compiles ahead of time

Senior weighting. Also the section that decides whether your performance answers mean anything.

  1. Debug, profile and release builds — why can you never draw a performance conclusion from debug?
  2. A screen janks. How do you work out whether it's a build problem or a raster problem?
  3. Your app is noticeably larger than the equivalent native app. What do you tell the stakeholder who asks why?

Saying it out loud: question 19 is the most senior-sounding answer available in the whole list, because it starts by splitting the problem rather than listing fixes: "First I'd find out which thread is over budget, because they have opposite fixes. If the UI thread is slow, I'm doing too much work in build — expensive widgets rebuilding, layout thrash, something heavy called from a build method. If the raster thread is slow, I'm asking for expensive painting — big blurs, shadows, saveLayer, clipping with anti-aliasing. Profiling in a profile build tells you which, and until you know that, every fix is a guess."

Question 20 is not really a technical question. It's checking whether you can defend a tradeoff to someone non-technical without getting defensive — the framework ships its own rendering engine, that engine is why the UI is identical on both platforms and why one team can maintain it, and the size cost is the price of that. Say the number honestly and say what it bought.

The question that isn't technical

Somewhere in a Flutter loop, usually late and phrased casually, someone asks why Flutter at all. Sometimes it's curiosity. Often it's a native developer on the panel who has doubts, and how you answer decides whether they leave the room comfortable with you.

What goes wrong

Defending the framework

“Flutter is faster to develop, it's 60fps, and you write once and it runs everywhere.”

Marketing copy, delivered to someone who has shipped native apps and knows the exceptions. It reads as loyalty rather than judgement, and it invites them to start listing the exceptions back to you.

What lands

Naming the trade you made

“One team, one UI codebase, and pixel-identical screens on both platforms. The costs are app size, and that anything deeply platform-specific goes through a channel I have to maintain. For the products I've worked on that trade was clearly worth it — for something built around a platform-specific capability, I'd argue the other way.”

Now you sound like someone who chose, not someone who was assigned. And you've named a case where you'd choose differently, which is the part that makes the rest believable.

The general version of this — sounding certain about things you should be certain about, and calibrated about the rest — is the thing that most often separates two candidates with identical knowledge. We wrote about how that goes wrong in Why smart candidates fail interviews.

Practical target: take question 3 and question 19 and answer them back to back, out loud. They're the same skill at two different altitudes — naming which layer a problem lives in before proposing a fix. If both come out as lists of names rather than as a division of the problem, that's the habit to work on, and it's worth more than another ten facts.