Interview decision
Locate the shared invariant, create observable seams, and evolve the smallest owning boundary when a requirement changes.
Mental modelConcurrency, testability, and evolution are three stress tests of responsibility placement - not reasons to add infrastructure everywhere.
Use it to
- Serialize two reservations for one room.
- Inject time for pricing tests.
- Add recurring reservations without replacing conflict ownership.
Keep out of scope
- Teaching lock-free algorithms or operating-system internals.
- Mocking every internal object.
See the responsibility boundary
RoomCalendar exposes one atomic reserve operation, Clock is replaceable for deterministic tests, and RecurrencePolicy expands requests while overlap stays with the calendar.
interface Clock { now(): Instant; }
interface AtomicCalendar {
reserve(request: ReservationRequest): Promise<Reservation | Conflict>;
}Discuss concurrency only where simultaneous behavior can break an invariant
Concurrency matters when two actions can observe or change the same state in a harmful order. Name the shared state, the invariant, and the synchronization or serialization boundary at the level the prompt requires.
Two booking requests can see the same room as free. A Calendar can expose an atomic reserve operation, leaving the storage-level enforcement as an explicit later boundary if needed.
Interviewer follow-ups
- What race would violate the invariant?
- Where should the atomic operation live?
Do not over-engineer: Do not drift into lock-free internals, kernel scheduling, or distributed consensus unless the interviewer asks for low-level systems work.
Make behavior testable at the boundary
Testability comes from observable contracts, deterministic policies, and replaceable external collaborators. Test a use case and an invariant, not only individual getters.
Inject a Clock and DeliveryChannel into a scheduler so a test can simulate cutoff time and a failed notification without contacting an external provider.
Interviewer follow-ups
- What behavior can this test observe?
- Which collaborator is nondeterministic or external?
Do not over-engineer: Do not introduce a dependency container when constructor parameters are sufficient.
Evolve by locating the pressure
When a follow-up arrives, say which assumption changed, which responsibility owns the resulting change, and which contract remains stable. Senior and Staff+ candidates should also discuss scope boundaries and the organizational or system interface that should own a cross-cutting change.
When a scheduler adds recurring reservations, introduce a recurrence policy and expand reservation generation while keeping conflict checking in Calendar.
Interviewer follow-ups
- What existing contract stays stable?
- Does this new concern belong inside this component or at a system boundary?
Do not over-engineer: Do not make Staff+ mean more classes; it means clearer scope, boundaries, and judgment.
Validate the design, not the diagram
Walk one representative flow
- Two callers submit the same TimeRange.
- RoomCalendar serializes the invariant check and insert.
- One receives Reservation and one receives Conflict.
- A deterministic test controls time and asserts the final calendar.
Tests that protect the reasoning
- Concurrent requests cannot both confirm the same room and range.
- A fake clock makes expiration deterministic.
- Adding recurrence reuses the same single-reservation conflict rule.
Evolve it without losing the boundary
- Follow-up change
- Add a waitlist and decide whether it reacts to cancellation or becomes part of the calendar transaction.
- Concurrency, when relevant
- Name the harmful interleaving and atomic owner. Do not specify locks, transactions, or queues beyond the detail the interviewer requests.
- System Design boundary
- Cross-process locking, database isolation, messaging, and multi-region reservations belong to System Design after the object-level contract is explicit.
What depth looks like by level
- Entry
- Recognize a concrete race and write behavior tests.
- Mid
- Choose useful seams and preserve invariants under failure.
- Senior
- Explain atomicity, idempotency, and targeted evolution.
- Staff+
- Frame consistency and ownership across component, platform, and organization boundaries.