Self-mock: object-oriented design discussion

An object-oriented design (OOD) discussion round asks you to design the classes for a prompt and talk them through in about 45 minutes, on a whiteboard or in a shared document, usually with little or no running code. A self-mock rehearses that round alone. You take a prompt you have not seen, start a timer, and work through five stages while writing notes in a fixed layout. Only after the timer stops do you compare your notes with a sample answer and score them on a rubric. The sample answer shows one good answer, not the only one; the rubric keeps your scores consistent from one mock to the next, so that your weak areas become visible.

The five stages and the first prompt

The 45 minutes follow the budgets of the answer framework for a discussion round, and each stage ends with something written down:

The first prompt: Members of a neighbourhood tool library borrow tools such as hammer drills, ladders and pressure washers. They reserve a tool for a few days, collect it and bring it back. The library has a few items of each tool, takes a deposit, and charges for lateness and damage. Design the classes.

Ask your questions before you model anything. In a self-mock, the interviewer’s answers sit on a card that you read only after writing a question down. For this prompt the card says: members reserve a tool type, not a particular item; a reservation lasts 1 to 7 whole days; a tool is collected on the first day and returned by closing time on the last; every late day costs a fee taken from the deposit; a member may hold 2 reservations at once. In the worked mock that follows, five questions in the first four minutes drew out every answer on this card.

Keep the notes in five boxes, one per stage, so that the review can compare like with like:

# Self-mock notes: (the prompt)                     45 minutes, timer running

## 1. Clarify (minutes 0 to 5)
Questions asked, and the answers:
-
Requirements, numbered:
- R1
Out of scope:
-
Assumptions, numbered:
- A1

## 2. Model (minutes 5 to 20)
| Class | Knows | Owns the rule |
|-------|-------|---------------|
|       |       |               |
Options rejected, and why:
-

## 3. Diagrams (minutes 20 to 30)
- Class diagram, with multiplicities:
- One state or sequence diagram, for:

## 4. Key code (minutes 30 to 40)
- The method that holds the hardest rule:
- Its tests, by name:

## 5. Follow-ups (minutes 40 to 45)
| Follow-up | Where it lands | What stays untouched | The test that proves it |
|-----------|----------------|----------------------|-------------------------|

## After the timer
Scores from 1 to 4: clarifying __ · classes __ · diagrams __ · key code __ · trade-offs __
The lowest area, and one thing to do differently in the next mock:

When the timer stops, score five areas from 1 to 4, one for each stage:

• Clarifying and scope: the questions you asked and the numbered requirements you wrote.
• Classes and responsibilities: each rule has one owner, and rejected options are named.
• Relationships and diagrams: a class diagram with multiplicities and one diagram of behaviour.
• Key code and API: the method that holds the hardest rule, with its tests named.
• Trade-offs and follow-ups: where each change lands, and when a rejected option would win.

Score after the timer, never during it: a mock you stop to judge is no longer timed. Then add the five scores to a review log, which brings a weak area back as a short drill the next day and lets a strong one wait longer each time. Over a few mocks, the log shows which stage keeps costing you points.

The worked mock, stage by stage Pro: opens with a Pro, Premium or Ultimate pass