Coding interviews
using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
var approved=Decide(new Order(2,150,3)); var denied=Decide(new Order(4,150,3));
Console.WriteLine(approved.Status+":"+approved.TotalCents); Console.WriteLine(denied.Status+":"+denied.TotalCents);
Console.WriteLine("invalid:"+Decide(new Order(0,150,3)).Status);
static Decision Decide(Order order) {
if(order.Quantity<=0 || order.UnitCents<0 || order.Stock<0) return new("invalid",0);
if(order.Quantity>order.Stock) return new("insufficient",0);
return new("approved",checked(order.Quantity*order.UnitCents));
}
sealed record Order(int Quantity,long UnitCents,int Stock);
sealed record Decision(string Status,long TotalCents);
Reveal answer and reasoning
The output lines, in order, are “approved:300”; “insufficient:0”; “invalid:invalid”. Two units at one hundred fifty cents with stock three are approved for three hundred cents. Four units exceed the same stock and produce insufficient with zero total. Zero quantity is invalid before stock comparison. The harness exposes those outcomes without a logger, database, network call or dependency container. The zero total on insufficient or invalid decisions is a deliberate non-approved result convention.
Callers must inspect Status rather than interpreting every zero as a valid free order. Error precedence is visible because invalid input returns before availability is considered, making behavior stable when multiple rules fail together.
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.
What a strong answer covers
- Exact output: approved:300 | insufficient:0 | invalid:invalid
- Two units at one hundred fifty cents with stock three are approved for three hundred cents.
- 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.