The — 5-Minute — Design — Answer

"Design a database for a library."

You have five minutes and a whiteboard. Most candidates start drawing tables immediately and forget half of what they know.

There's a better opening move.

Why & what

Design questions aren't testing whether you can invent a schema. They're testing whether you have a method — and whether you mention the things beginners forget: cardinality, normal form, transactions, indexes.

A design answer has four checks after the tables: what are the cardinalities, is it normalized, what needs to be one transaction, and what needs an index.

Say those four out loud and you've covered Modules 2, 4, 6 and 7 without being asked.

How it works

The library question, answered properly.

1. Find the nouns → tables. Member, Book. Each gets a primary key: member_id, isbn. Say the keys out loud; candidates who skip them get asked anyway.
2. Find — the — verbs — → — relationships, — then — check — cardinality. — A — member — borrows — manybooks. A book is borrowed by many members over time. Many-to-many — which means a third table, Loan(loan_id, member_id, isbn, issue_date, due_date).
3. Check normal form. Is the book's title stored in Loan? It shouldn't be — it belongs in Book, because title depends on the book, not the loan. Say "so we're in 3NF" and move on. One sentence.
4. Find what must be all-or-nothing. Borrowing is two changes: insert a Loan row, and decrease the available copy count. Half of that is a broken library. Wrap it in a transaction.
5. Find the hot query, then index it. Members search by title constantly. Add an index on Book(title). Mention the cost — writes get slower — so it's clear you know it isn't free.

The library adds fines. Where does fine_amount belong — Member, Book, or Loan?

Loan. A fine comes from one specific late return, so it depends on the loan — not on the member generally, and not on the book. Putting it in Member would break as soon as someone has two overdue books.

Notice: the same four checks work on any design question you get.

Common confusion

Candidates think a design answer means "produce the perfect schema." It doesn't. Interviewers are watching how you think, and they will deliberately change the requirements mid-answer to see if your design bends.

So narrate as you go. "I'm making this many-to-many because a book can be borrowed by different people over time — if that weren't true, I'd put a foreign key in Book instead." That one sentence shows you understand cardinality far better than a correct diagram drawn in silence. Second: don't skip the boring tables. A junction table is the single most common thing candidates forget, and it's the thing that proves you understood M:N.

Interview angle

1. "Design a database for [anything]." — Nouns to tables, verbs to relationships, cardinality on each one, then the four checks. Narrate your reasoning throughout.
2. "What would you change if the system had 10 million users?" — Indexes on the hot lookups, possibly a denormalized reporting table, and shorter transactions to reduce lock contention.
3. "Where would you put this new column?" — Answer with a dependency: it goes in the table whose key actually decides it. That's the 3NF reasoning from Module 4, applied live.

Recap

Answer any design question with nouns-to-tables, then four checks — cardinality, normal form, what must be one transaction, and what needs an index — narrating your reasoning as you go.