Why this matters
- A fixed rhythm stops you from coding yourself into a corner in the first ten minutes.
- Interviewers score process as much as the final class names.
- CampusOS problems reuse the same six steps — muscle memory transfers across parking, booking, and cache design.
Step 1 — Clarify requirements
Ask about users, core flows, and what is out of scope. Write assumptions on the board.
Functional: park vehicle, issue ticket, pay on exit, show availability
Non-functional: single campus lot, in-process, hourly billing
Out of scope: mobile app UI, payment gateway integration, multi-site
Step 2 — Identify entities
Underline nouns in the requirements. Each stable noun is a candidate class; relationships become fields.
CampusOS parking nouns
Vehicle,ParkingSpot,ParkingTicket,ParkingLot,Payment,DisplayBoard
Step 3 — Sketch public APIs
List operations the outside world calls — not every private helper.
public interface ParkingLot {
Optional<ParkingTicket> park(Vehicle vehicle);
Money exit(ParkingTicket ticket, PaymentMethod method);
AvailabilitySnapshot availability();
}
Step 4 — Draw relationships
Use a simple class diagram: composition for ownership, interfaces for pluggable behaviour. Skip decorative UML.
Step 5 — Name patterns
Only introduce a pattern when a force appears: new vehicle types (Strategy), entry modes (State), notifications (Observer).
Step 6 — Write core code
Implement the happy path plus one edge case — full lot, invalid ticket, concurrent seat hold. Leave getters/setters for later.
Quick recall
Everything you need if you only revisit this box.
- Clarify — functional, non-functional, out of scope
- Entities — nouns and ownership
- APIs — public operations only
- Diagram — classes and relationships
- Patterns — name the force first
- Code — happy path + one edge case
Test yourself
Answer these before moving on — recall is what makes it stick.