Discussing how to build something larger.
WHAT THEY ASSESS
Whether you can reason about systems at a level above code.
WHAT THEY TYPICALLY ASK
How you would design a familiar kind of system.
WHAT TO DO FIRST
Clarify requirements.
WHAT TO ASK ABOUT
Who uses it, and how many What it must do
What matters most: speed, consistency, cost
What is out of scope
WHY THAT MATTERS
Without constraints, any design is arbitrary.
WHAT TO DO SECOND
Sketch the main components and how they connect.
WHAT TO COVER
Data storage and its shape How requests flow Where state lives How it scales What fails, and what happens then
WHAT DISTINGUISHES A GOOD ANSWER
Naming trade-offs explicitly.
WHY
Every design choice costs something, and recognising that is the skill.
WHAT TO AVOID
Naming technologies without reasoning Designing for scale nobody asked for Silence while thinking
WHAT TO SAY ABOUT SCALE
What you would do at current scale, and what would change later.
WHAT TO DO IF UNFAMILIAR WITH THE DOMAIN
Say so, and reason from principles.
WHAT PREPARATION HELPS
Reading how real systems are built Practising describing systems you have worked on
WHAT TO PRACTISE MOST
Explaining out loud, with a diagram.
