OOD Interviews: Stop Guessing Classes—Identify Core Entities Like a Pro

In object-oriented design (OOD) interviews, interviewers aren't impressed by a long list of classes — they're looking for a systematic approach. The quickest way to show you know what you're doing is to identify the domain's core entities: objects that own both data and behavior (for example, Product or Order). Here's a practical, repeatable method to do that confidently.

A 5-step checklist for finding core entities

1. Understand the domain first

   • Ask clarifying questions to reveal goals, constraints, and key flows. Don't assume terminology — confirm what the interviewer means by terms like "user," "account," or "session."

2. Extract nouns from requirements

   • Scan the problem statement and notes for nouns: Book, Member, Loan, Product, Cart, Payment.
   • Nouns are candidates for entities. Keep them as seeds, not final answers.

3. Assign clear responsibilities (apply SRP)

   • For each candidate entity, ask: what is this responsible for? A class should have one primary reason to change.
   • Example: Loan manages borrowing dates and status; Member tracks member details and loan history; Book contains bibliographic info and availability.

4. Define relationships and ownership

   • Map associations: Member has many Loans; Loan links to Book; Order contains OrderItems; Product has Inventory.
   • Decide aggregation vs. composition and which side owns lifecycle (does deleting a Member delete their Loans?).

5. Iterate and refine as requirements evolve

   • As you add features (reservation, fines, search), some nouns split into new entities or become value objects.
   • Refactor responsibilities to keep classes cohesive and decoupled.

Mini example: library system

• Noun extraction: Book, Member, Loan, Reservation
• Responsibilities:
  • Book: metadata, availability check
  • Member: profile, borrowing limits, fines
  • Loan: start/end dates, renewal, status
  • Reservation: queue position, notify on availability
• Relationships: Member 1..* Loan; Loan -> Book; Reservation associates Member and Book

Show this thought process in the interview—draw a simple UML or diagram and narrate why each class exists and what it does.

Interview tips — what to say and show

• Think aloud: explain how you derived entities from nouns and scenarios.
• Prioritize: highlight the core entities first, then secondary ones.
• Justify responsibilities: use SRP as your reasoning for why a class has (or doesn't have) a responsibility.
• Discuss trade-offs: when to merge vs. split classes, or use value objects instead of full entities.
• Iterate: ask "what if" questions (concurrency, deletes, scale) and show how your model adapts.

Quick checklist to use during interviews

• Did I extract nouns from the prompt?
• Can I name 3–6 core entities and their main responsibilities?
• Have I defined relationships and ownership?
• Can I point to one reason each class might change (SRP)?
• Did I sketch a small diagram and explain it clearly?

Identify entities like this and you'll stop guessing classes — you'll design them deliberately.

#ObjectOrientedDesign #SystemDesign #SoftwareEngineering