Object-Oriented Design, API Design, And Testability

What's being tested

These prompts test object-oriented design, API contract design, and testability under changing requirements. Interviewers want to see clear abstractions, explicit invariants, deterministic tests for randomness/concurrency, and complexity-aware implementations.

Patterns & templates

• Model domain objects first — define Card, Deck, Move, Game, SnapshotStore; keep state private and expose minimal methods.

• Separate policy from mechanism — inject RuleSet, Random, Clock, AuthzService, or Storage so behavior changes without rewriting core logic.

• Design APIs around invariants — draw() should prevent overdraw, snapshot() should return immutable versions, put() should define overwrite/delete semantics.

• Use standard algorithms deliberately — Fisher–Yates shuffle() is O(n) time, O(1) extra space; avoid biased random swaps or repeated random removal.

• Versioned data structures — snapshotable stores often use per-key sorted version lists; get(key, snapId) via binary search is O(log v).

• REST robustness checklist — validate input, authenticate, authorize, enforce idempotency keys, handle conflicts with ETag/version fields, return precise 4xx/5xx.

• Test seams — inject deterministic RNGs, fake clocks, in-memory repositories, and mock clients; cover ties, empty decks, duplicate requests, races, and rollback cases.

Common pitfalls

Pitfall: Jumping straight to classes without clarifying operations, mutability, error behavior, and expected scale.

Pitfall: Treating randomness or concurrency as “hard to test” instead of injecting dependencies and asserting deterministic outcomes.

Pitfall: Overengineering with inheritance-heavy hierarchies when a small interface plus composition would be simpler and more extensible.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.