~/problems

Problems

Basics first, then the classics, then company-style assessments. Every problem has tests you run right here; multi-level ones unlock as you go. See the roadmap.

Simulation & OOP design

Object-oriented design and extensible simulations

Classes that survive new requirements: games, payments, subscriptions, refactors.

Notes

Recognise it when: you implement a small domain (game, payments, ordering, subscriptions, battle system) where every level adds requirements, or you refactor messy code.

  • Nouns become classes and verbs become methods. Keep state where the behaviour is.
  • Extension points: strategy objects or registries (handlers[type] = fn) instead of growing if/elif chains. New requirements should add code, not edit everything.
  • Invariants live in one place (e.g. a balance never goes negative). Validate inputs at the boundary.
  • Refactor rounds: add tests around the current behaviour first. Then extract functions, remove duplication, and replace flags with polymorphism, keeping behaviour identical.
  • Talk as you go: interviewers grade the trade-offs you say out loud (why a dataclass, why an enum, how you'd add feature X next).

Gotchas: over-engineering before requirements arrive, shared mutable defaults (def f(x=[])), and equality/hashing of domain objects.

31 problems

Practical systems

Simulation & OOP design Model the rules precisely, keep it extensible.

Object-oriented design and extensible simulations

esc