What is BuildContext? Give two tree-interaction examples.

WHAT THIS TESTS: This question probes your mental model of the Flutter framework's three-tree architecture. The interviewer wants to know if you see BuildContext as the public face of an Element, not as a widget or a generic bag of utilities. They are checking whether you understand directional lookup rules in the element tree and the subtle parent-child boundary that causes the classic own-context trap.

A GOOD ANSWER COVERS: First, define BuildContext as a handle to the widget's location in the element tree, noting that every widget gets its own context and that the underlying object is actually an Element. Second, give two distinct usage categories: one is accessing inherited data, such as calling Theme.of(context) or MediaQuery.of(context) to read the nearest ancestor of that exact type; the other is accessing ancestor state or services, such as calling Scaffold.of(context) to show a drawer or Navigator.of(context) to push a route. Third, explain the parent boundary trap: inside a build method, the context passed in belongs to the widget whose build method is running, which sits above the widgets being returned, so a Theme or Scaffold created inside that same build method will not be visible to Theme.of or Scaffold.of using the original context. Fourth, mention that because a context can move or become invalid when its widget unmounts, you should not cache it beyond a single synchronous function, and you must guard async usage with context.mounted before calling navigation or setState.

COMMON WRONG ANSWERS: Saying BuildContext is the widget itself or a global application context. Claiming that any widget can find any other widget anywhere in the tree regardless of ancestry. Using the build method's context to look up a Scaffold or Theme that is defined in the same build method without using a Builder to obtain a descendant context. Storing BuildContext in a state variable or passing it into a Future and using it after an await without checking mounted.

LIKELY FOLLOW-UPS: How would you access a Scaffold that is created in the current build method? The expected answer is to wrap the subtree in a Builder so the callback receives the Builder's context, which is a descendant of the Scaffold. What happens if you cache a BuildContext in a StatefulWidget and use it after a network request? The interviewer expects you to say the context may be unmounted and you should check mounted or use a StatefulBuilder pattern. Can you explain why dependOnInheritedWidgetOfExactType returns null? They want to hear that the requested InheritedWidget is not an ancestor of the given context.

ONE CONCRETE EXAMPLE: Imagine a StatelessWidget whose build returns a Scaffold with an AppBar and a body containing a TextButton. If the button's onPressed calls Scaffold.of(context) using the build method's original context, it returns null because that context belongs to the StatelessWidget, which is the parent of the Scaffold. To fix it, wrap the TextButton in a Builder whose builder callback receives the Builder's own BuildContext. That new context is a child of the Scaffold, so Scaffold.of now finds the correct ancestor and showBottomSheet succeeds.