Explain Flutter's 'constraints down, sizes up' rule and unbounded height error

WHAT THIS TESTS: This question evaluates whether you understand Flutter's box constraint protocol, which is the foundation of every layout decision in the framework. Interviewers want to see that you know layout is a two-pass conversation between parent and child, not a single-step sizing operation. Senior engineers are expected to diagnose constraint violations quickly without relying on trial and error, and to explain why the error occurs rather than just memorizing a fix.

A GOOD ANSWER COVERS four things in order. First, state the core rule clearly: constraints travel from parent to child, and the resulting size travels back up. Second, explain that a constraint is a range with a minimum and maximum width and height, not a fixed size, so a child must choose a size that falls within the bounds its parent provided. Third, identify that some widgets like Column and ListView have special layout behaviors that create unbounded constraints in one axis, which means the maximum in that axis is infinite. Fourth, demonstrate that you know multiple resolution strategies and when each is appropriate, rather than applying a single recipe.

COMMON WRONG ANSWERS include saying that widgets simply decide their own size and the parent must accept it. Another red flag is offering only one fix regardless of context, such as always recommending shrinkWrap without explaining that it defeats laziness and can hurt performance for long lists. Confusing unbounded width with unbounded height errors also signals shallow understanding, as does blaming the framework instead of recognizing the constraint mismatch.

LIKELY FOLLOW-UPS include asking how the constraint system differs for flex widgets like Row and Column versus pass-through widgets like Stack, or asking you to explain how IntrinsicHeight works and why it is expensive. An interviewer might also ask what happens when you nest multiple Expanded widgets inside a Column, or why CustomScrollView with slivers avoids this particular error pattern, or how BoxConstraints actually get passed through the render tree.

ONE CONCRETE EXAMPLE: A Column containing a ListView.builder without any height restriction will throw an unbounded height error. The Column lays out its non-flex children with unbounded maxHeight in the main axis, so the ListView receives loose infinite vertical constraints and cannot determine a finite size. To fix it, wrap the ListView in an Expanded widget so the Column assigns it a bounded flex proportion after measuring the other children. Alternatively, set shrinkWrap to true if the list is small and you want it to occupy only the space of its visible children, though this is less efficient for large data sets. Another valid fix is replacing the outer Column with a ListView if every child should scroll together as a single sliver.