Final Design Interview Checklist

What to cover every time

Before you finish, make sure you have: clarified functional and non-functional requirements; stated assumptions and rough numbers, clearly labelled as assumptions; identified core entities and APIs or classes and interfaces; drawn a clear diagram and walked a use case through it; deep-dived into the hardest part; addressed consistency, concurrency and idempotency where money, inventory or shared state is involved; discussed scaling, bottlenecks and failure modes; named trade-offs and alternatives; and summarised the design and possible extensions in the last minute.

The checklist

Keep it beside you when practising.

[ ] requirements clarified; scope agreed; out-of-scope stated
[ ] assumptions + rough estimates labelled as assumptions
[ ] HLD: entities, APIs, data model   |  LLD: classes, interfaces, relationships
[ ] diagram with labelled flows        |  class diagram with multiplicities
[ ] one use case walked end to end
[ ] deep dive on the hardest component
[ ] consistency, concurrency, idempotency where shared state or money
[ ] scaling: partitioning, caching, replication, async work
[ ] failure modes: timeouts, retries, failover, degradation
[ ] trade-offs and rejected alternatives explained
[ ] LLD code: readable names, small methods, edge cases handled
[ ] 1-minute summary + extensions

End with a summary

A crisp one-minute recap of requirements, design and key trade-offs leaves the interviewer with a clear picture of your reasoning.

Quick check: Which belongs on a design interview checklist?

• Avoiding any mention of failures
• Skipping requirements to save time
• Labelling estimates as assumptions and explaining trade-offs
• Using every design pattern you know