Coding interviews
Reveal answer and reasoning
The persistence boundary can accept a valid proposed decision and perform a conditional stock update in one storage transaction. It should report a concurrency failure if availability changed, rather than trusting an earlier pure calculation as a reservation. Idempotency and logging belong around that operation with explicit ownership and data-retention policies.
The decision uses constant time and fixed-size result data. Record construction allocates small objects in this class-record version. Extracting a pure function improves deterministic testing but is not by itself a performance optimization. Overflow remains an explicit exceptional outcome for otherwise valid but unrepresentable totals. Refactoring should preserve observable error precedence unless the contract intentionally changes. Checking stock first could classify a malformed negative-stock request differently.
A successful decision is also not evidence that stock remains available when another caller later performs an external write.
An effective code-review answer preserves the behavior table, extracts a deterministic core and identifies the remaining external consistency problem. It shows why the same three-hundred-cent calculation can be tested without mocking a logger or database. It also avoids claiming that records, dependency injection or a pure function reserve stock. Senior discussion focuses on who publishes the decision and how a changed stock value is detected before committing an effect.
The related multi-file project contributes twelve independent boundary checks, providing a concrete review artifact rather than a stylistic refactor with no behavioral evidence. Reviewers should also preserve the distinction between a valid free order and a denied decision carrying zero. Comparing only Total would miss that observable status difference.
What a strong answer covers
- The persistence boundary can accept a valid proposed decision and perform a conditional stock update in one storage transaction.
- The decision uses constant time and fixed-size result data.
- Refactoring should preserve observable error precedence unless the contract intentionally changes.
Common pitfall
Refactoring should preserve observable error precedence unless the contract intentionally changes. Checking stock first could classify a malformed negative-stock request differently. A successful decision is also not evidence that stock remains available when another caller later performs an external write.
Follow-up questions
- Add fixtures where several validation rules fail simultaneously and specify the desired precedence. Hint: assert decision Status and total, not an internal sequence of helper calls. Compare the refactor against a written behavior table.
- How should persistence respond if stock changes after the pure decision but before the write?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.