Before you start

The whole course has been leading here. 37 lessons of hand-holding are behind you. Now you fly solo.

Why this lesson exists

The real interview has no template. The interviewer says "design X" and hands you a whiteboard. You:

• Ask clarifying questions
• Find the classes
• Pick patterns and defend them
• Write real code
• Test the important cases
• Walk through the design

Every lesson in module 4 gave you the requirements. This lesson makes YOU write them. That's the missing muscle.

What an interviewer is really judging (silently)

• Did you scope well? Under-scoping is safe but boring; over-scoping means you don't finish. Middle ground is interview gold.
• Did the design follow from the requirements? Reverse-engineering ("I used X because it's cool") gets caught in 30 seconds.
• Are patterns justified? Or just reflex?
• Do tests cover the rules, not just happy paths?
• Can you defend every choice? — the "walk me through your design" phase.

The design.md you produce here rehearses every one of these.

What good looks like

Say you picked "note-taking app". A strong design.md:

Requirements:

• Users have notes. Notes have title, body, tags, created_at.
• Operations: create, update, delete, search-by-tag, search-by-text (substring in body).
• Rules: notes can never be modified after deletion; every note has at least one tag (empty defaults to "misc").

Entities:

• Note — data class + matches(query) helper
• NoteStore — main class, holds the notes dict, offers CRUD + search

Patterns:

• No GoF pattern fits. Search is a plain method; only one algorithm (substring). If we added ranking or fuzzy match, Strategy would fit — but for MVP, plain code is right.

Trade-offs:

• Store notes in a dict[note_id -> Note] for O(1) CRUD. Search is O(N) full-scan. For MVP that's fine; if we needed sub-linear tag search, I'd add an inverted index dict[tag -> set[note_id]].

Rules:

• Deleted notes can't be modified. Enforced by the check in update() that the note is still in the active dict.
• Every note has ≥1 tag. Enforced by create() defaulting empty tag lists to ["misc"].

That's a design an interviewer would sign off on. Yours will look different — same shape.

Scope discipline

Cut features aggressively. A working 3-operation system beats a broken 10-operation one. Common pitfalls:

• "Also I'll add user authentication." — NO. Out of scope.
• "It should have a REST API." — NO. Out of scope.
• "Let me also model the database schema." — NO.

Anything you cut is fair to mention in Trade-offs. "I deliberately cut authentication for MVP scope; would add an AuthMiddleware later."

The tests-are-yours part

Writing tests for your own design is a real skill. Include:

• Happy path per operation. Basic add / read / search works.
• Invalid input. Duplicate creation, missing key, bad data.
• Rules. One test per rule you named in design.md. If you said "notes can't be modified after deletion", write a test that PROVES it.
• Interactions. Two operations in sequence exercise more than one op alone.

Aim for 5-10 tests. Not 50. Quality over quantity.

What the AI Code Review will notice

After you pass, click "Ask Claude for a code review". Claude reads all three files and comments on:

• Whether your patterns match your reasoning
• Whether your rules are actually enforced (or just claimed)
• Whether your tests cover the rules (or just happy paths)
• Whether your requirements section pins scope well
• Any obvious over-engineering

Take that feedback seriously. It's the closest thing to an interviewer's follow-up you'll get in a solo drill.

You've done 37 lessons. You've built vending machines and parking lots and chess boards and rate limiters. Now do one from scratch — with NO problem statement handed to you.

This is the closest simulation to a real LLD interview:

1. Pick a domain YOU care about.
2. Write down the requirements.
3. Design the entities.
4. Justify the patterns you'll use.
5. Implement.
6. Write your own tests to verify.

No spec sheet. No API contract. No hidden test suite. YOU make every call.

Pick a domain (examples)

• Music streaming subscription tracker (users, plans, playback tracking)
• Note-taking app with tags and search
• Todo list with subtasks and due dates
• Recipe manager (recipes, ingredients, meal plans)
• URL shortener (custom aliases, click tracking)
• Personal finance tracker (accounts, transactions, categories)
• Trip planner (destinations, activities, budgets)

Or invent your own — anything you'd genuinely find useful.

What you submit

Three files, all graded:

1. design.md — same four sections as before

## Entities
What classes exist? What's each one's responsibility?

## Patterns
Which module 1-3 patterns did you use? For each: which
requirement made it right? What alternatives did you reject?

## Trade-offs
What choices did you make between reasonable options?

## Invariants
What rules does your design enforce? Where?

Add a section before the standard four:

## Requirements
What does this system do? What are the operations? What are
the rules?

You defined the problem. Prove you thought about it.

2. main.py — your implementation

Whatever public API you decided on. No template — you own it.

3. test_solution.py — YOUR OWN tests

At least 5 test functions, each with at least one assertion. Test your happy paths, edge cases, and invariants. This is where interviewer follow-ups live: "how would you test this?"

The grader runs pytest -q. Your tests must pass. If they don't, either your implementation has a bug OR your tests are wrong — both are on you to fix.

What the grader checks

• design.md exists with all sections (including the new ## Requirements)
• main.py has real code (not just imports / pass)
• test_solution.py has ≥5 test functions, each with ≥1 assert
• pytest -q returns 0

The grader can't tell if your DESIGN is good — that's what the "Ask Claude for a code review" button is for. Use it after your submission passes; Claude reads all three files and comments on the actual choices.

The interview scenario

This is what a Bar Raiser at a big company does to you in 60 minutes:

• "Design a note-taking app."
• You: "Ok, some clarifying questions first — do notes have tags? Can they be nested? Search by text? Sort?"
• Interviewer: "Whatever you think makes sense."
• You have to pin the scope, design the entities, defend the patterns, write real code, verify with tests.

This lesson is that, at your own pace.

Advice

• Start small. A tiny app fully thought-through beats a huge app half-designed. Cut features aggressively for MVP.
• Write requirements FIRST. Don't start with entities. Requirements shape entities, not the other way around.
• Sketch on paper before coding. Draw a class diagram. Even ugly boxes on paper reveal design issues.
• Small commits. Design → skeleton → one operation end-to-end → next operation. Not "all at once".

Take your time. This is not a race. Skip forward when you can defend every choice in your design.md.