Build fluency in the vocabulary of a value that's never actually computed until something else genuinely reads it.
0 / 5 completed
1 / 5
At standup, a dev mentions an expression whose value isn't actually computed until the exact moment some other part of the program actually reads it, rather than being computed eagerly the instant it's written. What is this technique called?
Lazy evaluation defers computing an expression's value until the exact moment something else in the program actually reads it, rather than computing it eagerly the instant it's written, which means a value that's never actually read is never computed at all. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This defer-until-read behavior is exactly what lets an infinite or extremely expensive sequence be represented and only ever partially computed, on demand.
2 / 5
During a design review, the team relies on lazy evaluation specifically so an expensive computation embedded in a data structure is only ever actually performed if some later code path genuinely needs its result. Which capability does this provide?
Lazy evaluation provides avoiding wasted work on values that turn out to never actually be needed, since the underlying computation only runs the first time its result is genuinely demanded by some other code path, and is skipped entirely for any value that's constructed but never actually read. Computing every expression eagerly the moment it's written would perform that expensive work even for values that end up discarded unused. This demand-driven behavior is exactly why lazy evaluation is useful for building large or even conceptually infinite structures where only a small portion is ever actually consumed.
3 / 5
In a code review, a dev notices a function eagerly computes and fully builds an expensive, large result up front, even though most callers only ever read the first few entries before discarding the rest. What does this represent?
This is a missed lazy-evaluation opportunity, since deferring the computation of each entry until it's actually read, rather than eagerly building the entire expensive result up front, would avoid the wasted work on all the entries most callers never actually touch before discarding the rest. A cache eviction policy is an unrelated concept about discarded cache entries. This eager, fully-materialized pattern is exactly the kind of inefficiency a reviewer flags once it's clear most callers only ever consume a small prefix of the full result.
4 / 5
An incident report shows a reporting endpoint's latency spiked because it eagerly computed and fully materialized an expensive, large result set on every request, even though the vast majority of callers only ever read the first page before moving on. What practice would prevent this?
Making the result lazily evaluated, so each entry is only computed the moment a caller actually reads that far into it, means callers who only read the first page never pay the cost of computing the rest, which is exactly the fix for the latency spike described in this incident. Continuing to eagerly compute and fully materialize the entire result set on every request is exactly what wasted so much work on entries most callers never actually consumed. This on-demand computation is the entire point of lazy evaluation, and it directly targets workloads where most of a large result is routinely left unread.
5 / 5
During a PR review, a teammate asks why the team reaches for lazy evaluation instead of just always computing everything eagerly, given that eager code is often simpler to reason about and debug. What is the reasoning?
Lazy evaluation trades away some of eager code's straightforward, top-to-bottom timing for the benefit of never doing work on a value that's never actually read, but that same deferred timing can make it genuinely harder to predict exactly when, or even whether, a side effect embedded in a lazy computation actually runs. Eager evaluation, by contrast, computes everything immediately and in a predictable order, which is simpler to reason about but wastes effort on values a caller never ends up needing. The tradeoff is precisely why lazy evaluation tends to be reserved for pure, side-effect-free computations, where its unpredictable timing carries no real risk.