Prepare Flutter interview answers on widget state, rebuilds, keys, asynchronous loading and testing with an original reorderable-list scenario. These original practice questions connect a concept to a decision and a failure case. They are preparation exercises, not leaked employer questions. State your assumptions before proposing an implementation.
What is the relationship between a widget and its state?
A widget describes configuration; persistent mutable state for a stateful component is managed separately by its State object. Explain the user's changing information and who owns it. Rebuilding a configuration is not the same as discarding all associated state. Avoid putting every value into a large screen object without considering which components should share it or derive it.
What should happen inside build?
Build describes the interface for the current state and may run frequently. Avoid treating it as the place to start an uncontrolled network request every time. Separate side-effect ownership from rendering and describe how loading results change the represented state. A test should reveal if repeated rebuilds accidentally submit work multiple times. Optimize after understanding which changes actually produce costly work.
Why do keys matter when a list changes?
Keys help the framework associate elements with their intended identity in relevant updates. If rows have state and their order changes, position alone may not represent item identity. Choose a stable key derived from the item's identity rather than a newly generated value on every build. Explain the visible failure: editing state or selection may appear attached to the wrong record after reordering.
How do you handle a result after a component is disposed?
Give asynchronous work a suitable owner and ensure the result is still relevant before changing component state. Cancel unnecessary work where supported and avoid updates to a disposed state object. Also address results from superseded requests; being mounted does not prove the response belongs to the current selection. Describe how loading, errors and empty content are represented.
How should you test a stateful screen?
Verify behavior with controlled input and dependencies. Test loading, content, empty results and failure, then add lifecycle and ordering cases relevant to the product. A screenshot can show presentation but does not establish that repeated taps or delayed responses behave correctly. Explain whether the rule needs a unit test, a widget test or an integration test and what each one proves.
Worked interview scenario
Original case: a list of tasks has editable rows. The user changes text in task B and then moves B above A. If row state is associated only with position, the edit can appear on the wrong task. Use stable task identity and define where the editable draft belongs.
Test reorder, deletion and insertion while one row is being edited. Add an async save that completes after the row is removed and define whether the save still belongs to a longer-lived model. A key does not solve the whole persistence problem: the product must still say when edits become durable and what happens if saving fails.
Practice exercise
Rehearse the task-list case with two rows and draw where each draft lives. Explain why a freshly generated key on every rebuild does not express stable identity. Then outline tests for reordering and a late save response, and identify which assertion checks the user's actual task text.
Review your explanation
Use Cluegent during practice to challenge your own draft. Ask for a follow-up about the scenario's weakest assumption, answer it without suggestions, then check your reasoning against the official reference. Review current plans before subscribing. Follow the employer's tool policy in the actual interview.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
Should network requests start on every build?
Give requests explicit lifecycle ownership so a routine rebuild does not accidentally repeat them.
Do keys make data persistent?
They help represent element identity in relevant updates. Persistence still requires a model and storage strategy appropriate to the workflow.