Why this matters
- Wrong assumptions in minute one waste twenty minutes of class design.
- Functional vs non-functional split shows structured thinking interviewers reward.
- Explicit out-of-scope boundaries prevent over-engineering under time pressure.
- CampusOS problems all start with the same clarification checklist.
1. ClarifyRequirements + scope
2. EntitiesNouns, verbs, ownership
3. APIsPublic operations
4. Class diagramRelationships
5. PatternsWhere they earn their keep
6. CodeCore paths + edge cases
Overview
The questions that prevent you from designing the wrong system in the first five minutes. Study each section below in order — every list is interview-ready reference material.
Functional requirements
Points to cover
- What users can do — create, read, update, delete, search, pay, cancel
- List actors: student, admin, system cron, external payment gateway
- Primary happy path in 3–5 steps before edge cases
- Write each requirement as a testable statement
Non-functional constraints
Points to cover
- Scale: users, QPS, data size — even rough orders of magnitude
- Latency: p99 target or 'best effort' for LLD scope
- Consistency: strong vs eventual for contested resources (seats, rooms)
- Security: auth required? roles? PII handling?
Out-of-scope boundaries
Points to cover
- Explicitly state what you will not design in this session
- Mobile UI, analytics pipeline, ML ranking — common outs
- Saying out-of-scope shows prioritisation, not weakness
- CampusOS LLD stays in one JVM unless interviewer redirects to HLD
CampusOS example
Points to cover
- Parking: in scope = park, ticket, pay, display board; out = mobile app, multi-city
- Write assumptions on board: single lot, hourly billing, four vehicle types
- Revisit assumptions if interviewer adds a constraint
// CampusOS — apply "Functional requirements" on paper first, then in code
public final class RequirementsClarificationExample {
// 1. Name entities from the problem statement
// 2. Draw relationships before writing methods
// 3. Introduce patterns only when a force appears
}
Quick recall
Everything you need if you only revisit this box.
- Functional requirements — review this slice before mock interviews.
- Non-functional constraints — review this slice before mock interviews.
- Out-of-scope boundaries — review this slice before mock interviews.
- CampusOS example — review this slice before mock interviews.
Test yourself
Answer these before moving on — recall is what makes it stick.