Coding interviews
Reveal answer and reasoning
A service should record receipt using an authoritative server clock and persist the acceptance decision with the request identity. A retry can then return the original decision instead of using a later arrival to reinterpret it. Client countdowns can explain the deadline to users but should not authorize late submissions by supplying their own timestamps.
Creating the window and checking it use O(1) time and state. Capturing one deadline avoids repeatedly extending the interval on every query. UTC timestamps simplify this fixture, but a real elapsed-duration budget may require monotonic timestamps and a clear clock-change policy. A manual GetUtcNow override does not automatically control TimeProvider timers or Task.Delay. Client-supplied timestamps are also not trustworthy authorization evidence.
The code neither persists deadlines across restarts nor arbitrates concurrent submissions arriving at a server boundary.
The interview answer should separate clock injection, deadline arithmetic, equality policy and actual cancellation. The fixture uses the real framework abstraction while controlling only the method consumed by this synchronous decision. It proves a reproducible before/at boundary without measuring elapsed wall time or exercising timers. A senior discussion asks whether the requirement is elapsed duration or an absolute deadline, how the decision survives restarts and how retries observe the first accepted receipt.
These ownership and trust questions matter more than adding arbitrary sleeps to a test that should be entirely deterministic. Deadline construction can also exceed the representable DateTimeOffset range; that is a separate boundary failure from a negative duration and should not be confused with a normal expired decision.
What a strong answer covers
- A service should record receipt using an authoritative server clock and persist the acceptance decision with the request identity.
- Creating the window and checking it use O(1) time and state.
- A manual GetUtcNow override does not automatically control TimeProvider timers or Task.Delay.
Common pitfall
A manual GetUtcNow override does not automatically control TimeProvider timers or Task.Delay. Client-supplied timestamps are also not trustworthy authorization evidence. The code neither persists deadlines across restarts nor arbitrates concurrent submissions arriving at a server boundary.
Follow-up questions
- Test zero duration, a negative duration and one tick before the deadline. Hint: equality belongs to the rejected side because the comparison is strictly less than. Avoid adding sleeps to obtain these boundary cases.
- How should an absolute deadline behave when the authoritative wall clock moves backward?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.