What problem does late solve in Dart?

WHAT THIS TESTS: This question probes your grasp of Dart sound null safety and the compiler's definite assignment analysis. The interviewer wants to see if you know why the compiler rejects some non-nullable variables that are not immediately initialized, and how late provides a controlled escape hatch without dropping to a nullable type.

A GOOD ANSWER COVERS: A strong response hits four points in order. First, state the core problem: Dart requires every non-nullable variable to be definitely assigned before use, which fails for fields that depend on constructor arguments or framework injection. Second, give two practical patterns: one is a non-nullable instance variable initialized after construction but before any method uses it, such as a repository field injected by a dependency framework; the other is lazy evaluation via late final for an expensive computation that should run only on first access, like parsing a large config blob. Third, explain the runtime contract: late removes compile-time checks and replaces them with a runtime check, so reading the variable before assignment throws a LateInitializationError. Fourth, note that late final combines deferred assignment with single assignment semantics, making it ideal for init-once dependencies.

COMMON WRONG ANSWERS: Watch for three red flags. One is treating late as equivalent to a nullable type; late variables remain non-nullable and do not carry null in their type. Another is claiming that late disables null safety; it does not, it merely shifts one specific check from compile time to runtime. A third is proposing late for every deferred field without mentioning the crash risk or without contrasting it with a nullable alternative that safely models absence.

LIKELY FOLLOW-UPS: An interviewer might push on when to choose late over a nullable field with null assertion; generally prefer late when you have a genuine guarantee of initialization before every read, and prefer nullable when absence is a valid state. They might ask about the difference between late final and a factory constructor that eagerly initializes fields, or how late interacts with override and inheritance. You could also be asked about the performance trade-off: late final adds a hidden boolean flag to track initialization state.

ONE CONCRETE EXAMPLE: Consider a ProfileController class that needs a non-nullable UserService. The service is provided by a route argument after the widget builds but before any user interaction. You declare late final UserService userService. In initState you assign userService = context.read. If a teammate accidentally accesses userService inside the build method before initState runs, the app crashes with LateInitializationError. For the lazy pattern, consider late final String jsonHash = computeHeavyHash on a data model class; the hash is calculated only the first time a test or serializer reads it, saving work when the field is never used.