Question 1

Which mistakes do you see most often when reviewing Dart code?

Accepted Answer

The question looks open-ended but really tests how systematic you are. Listing mistakes at random sounds weak; speak in categories and give one example per category. 1. Async: the forgotten await — the function returns before the work finishes and errors bypass try/catch. Most common in methods returning void, because the analyzer is silent by default. 2. Null safety: silencing the analyzer with !. ! is not bad in itself, an unjustified ! is — when I see one I ask "what guarantees this is not null?", and if there is no answer I suggest ?./??/promotion. 3. Collections: comparing lists with ==, mutating while iterating, traversing a lazy Iterable twice. 4. Numbers: money in a double, and / confused with ~/. 5. Lifetime: touching an already-disposed object after an await, and never cancelling a StreamSubscription. Finish with your stance: "Most of these should be caught by tooling, not people — unawaited_futures, avoid_dynamic_calls, cancel_subscriptions. In review I want to look at design and naming, not hunt for missing awaits."

Question 2

How do you compare two Lists or two Maps? How do you implement equality for your own class?

Accepted Answer

Start with the fact, because it is the real subject of the question: == on Dart collections is identity, so [1, 2] == [1, 2] is false. Practical solutions: const DeepCollectionEquality().equals(a, b) from package:collection, which also handles nested structures; on the Flutter side, listEquals/mapEquals for flat ones. In tests expect(a, equals(b)) already compares element by element — worth knowing, because people get confused by "it works in the test but not in the code". For your own class: override == and hashCode together. The rule: equal objects must have equal hash codes, otherwise an object lands twice in a Set and cannot be found as a Map key. Use Object.hash(a, b) for fields and Object.hashAll(items) for a collection field. An important addition (few candidates make it): the fields feeding hashCode must be immutable. Put an object in a Set and then mutate a field, and it is effectively lost inside that Set — which is why I write value classes with final fields and a const constructor. Alternative: with many value classes, code generation (freezed) or Equatable replaces the handwritten boilerplate — at the cost of a build step, so writing it by hand is fine on a small project.

Question 3

When is late justified and when is it a code smell?

Accepted Answer

Start by stating precisely what late does: it converts the compiler's "this field must be initialised" check into a runtime check. You take the guarantee onto yourself. Justified cases: Lazy computation: late final int total = _rows.fold(...) — the expensive work happens on first access and is cached. This is late at its best. Cyclic setup: two objects referencing each other that cannot both be built in one constructor. Framework lifecycles: the object is built in a later initialisation phase rather than in the constructor (Flutter's initState follows that model). Smell cases: late used merely to avoid writing ? — if the value genuinely is sometimes absent, the type should be nullable; late hides the problem instead of solving it. A field assigned from several different places — then there is no answer to "when is it ready?", and a LateInitializationError is only a matter of time. My rule: whenever I write late I ask myself, "can I prove this field is written before it is read?" "I'm pretty sure" is not enough; then I choose late final with an initialiser, a constructor parameter, or a nullable type.

Question 4

How would you tackle forgotten awaits in a large team?

Accepted Answer

The shape of a senior answer: a system, not individual vigilance. 1. Tooling: add unawaited_futures (and discarded_futures where it helps) to analysis_options.yaml and make it blocking in CI with dart analyze --fatal-infos. That closes about 90% of the problem for good. 2. Make intent visible: where fire-and-forget is genuinely wanted, write unawaited(future) — the lint goes quiet and the reader sees a decision. It must sit next to a catchError or a zone handler, otherwise the error is lost. 3. API design: the deepest part — an asynchronous method should return Future<void>, not void. An async method returning void denies the caller the ability to await at all, and such signatures create "impossible to await" spots across the codebase. 4. Rolling it out on an existing codebase: enabling the rule at once yields hundreds of warnings that everyone then ignores. I go module by module: raise the rule to error in one package, let dart fix handle the mechanical part, review the rest, then move on. Close: "These bugs come not from carelessness but from the language not forcing await. So the fix must be configuration, not an appeal to attention."

Question 5

What are lazy Iterable semantics, and what problems do they cause in production?

Accepted Answer

Give the mechanism in one sentence: map, where, expand, take do not compute; they return a description of a computation. The work happens only at traversal (for-in, toList, length, first, fold) and is redone on every traversal. Production problems — be concrete: Repeated expensive work: final rows = ids.map(loadFromDb); rows.length; rows.first; hits the database twice. It is hard to spot in a profiler because the code "was written once". Repeated side effects: a log line or counter inside map fires twice. A mutating source: an Iterable keeps a live reference to its source list, so changing that list later changes a result you thought was already computed. This is the hardest variant to find. Late-throwing errors: a throw inside map surfaces at the traversal line, not the map line — the stack trace points you at the wrong place. My rule: if the result is used more than once or returned out of the function, I materialise it with .toList(); returning a List from an API surprises callers less than returning an Iterable. The other side (show balance): laziness is a gift — where().take(10) over a huge file or a Stream does only the work actually needed. The point is not "lazy is bad" but knowing how many times you will consume the result.

Pitfall	What goes wrong	The right version
A forgotten `await` (fire-and-forget)	The function returns before the work is done; the error bypasses `try/catch` and goes unhandled	`await repo.save(x);` — if deliberate, `unawaited(...)` + `catchError`; lint: `unawaited_futures`
Silencing the analyzer with `!`	A compile-time error becomes a runtime `Null check operator used on a null value`	`?.`, `??`, an `if (x != null)` promotion, or `late final` — use `!` only where you can prove it
Mutating a list while iterating it	`ConcurrentModificationError` — and it may only appear on certain data	`list.removeWhere(...)`, or `for (final x in [...list])` over a copy
Comparing collections with `==`	`[1, 2] == [1, 2]` is `false`: `==` on a `List` is identity, not deep equality	`const DeepCollectionEquality().equals(a, b)` (package:collection); in Flutter, `listEquals`/`mapEquals`
Traversing a lazy `Iterable` twice	`map`/`where` re-run on every traversal — work is done twice and side effects repeat	Materialise once: `.toList()` / `.toSet()`
Using `/` for integer division	`7 / 2` is `3.5` (a `double`); using it as a list index is a type error	Use `7 ~/ 2` for integer division; keep money as an `int` in minor units
`late` as "we will fill it in later"	If read before written you get a `LateInitializationError` — the compiler no longer helps	Set it in the constructor or keep it nullable; `late` is for lazy computation and cyclic setup only
A shadowed variable inside a closure	The local name hides the field — the code looks right but changes nothing	Use distinct names or be explicit with `this.count`; `dart analyze` catches some cases
Confusing `==` with `identical`	`==` compares value, `identical` compares object identity; for strings the results can differ	Always `==` for content; `identical` only for cache/canonicalisation questions
Touching a disposed object after an `await`	The async work outlives the object: `Bad state: ... after dispose`, or a silent leak	After every `await`, `if (_disposed) return;`; cancel subscriptions and timers in `dispose()`
Doing money arithmetic with `double`	`0.1 + 0.2 != 0.3`; rounding errors accumulate and corrupt reports	An `int` in minor units, or a `Decimal` package; format only at display time
Escaping the type system with `dynamic`	All checks move to runtime; `json['user']['name']` eventually throws `NoSuchMethodError`	`Object?` plus pattern matching, or parsing into a model class; lint: `avoid_dynamic_calls`

Common Dart pitfalls

📚 Sources and documentation