Nov 09, 2021
Three Steps to Make a Design Interview More Efficient
Study what others ignore, and learn how others fail.
Tao Te Ching, Lao Tse, 500BC
学不学，复众人之所过
春秋战国 老子 《道德经》
Since early October 2021, we have been regularly conducting mock system design interviews online. Every Sunday since then, more than 100 engineers have joined us. These events have given us ways to develop our design skills and opportunities to find ways to improve ourselves when communicating under time pressure. We learned a few lessons along the way.
The usual steps for a system design interview are:
- collecting functional requirements
- collecting nonfunctional requirements
- designing architecture and API
Under time pressure, interviewees have often skipped some details, but the missing information cost them even more time during the interview. I highlighted them in the following diagram using green boxes:
Here are the lessons that we learned.
- Clarify essential design expectations; do not over-engineer.
- How we learned it: When we conducted a mock interview on metrics system design, the interviewee assumed that the
interviewer required the creation of three backend subsystems: logging, visualization, alerting, whereas the
interviewer initially only planned to ask about visualization.
- Collect requirements on traffic and storage when gathering nonfunctional requirements.
- How we learned it: When we conducted a mock interview on payment system design, the interviewee dived deep into system
design without clarifying the traffic and storage requirements upfront. The interview flow was interrupted when the
interviewee covered the database design. At that point, the interviewee went back to gather traffic and storage
requirements to validate that the plan could satisfy the traffic and storage requirements.
- Define the external API before other parts of the design.
- How we learned it: When we conducted a mock interview on the job scheduler design, the interviewee covered a portion of the system design, then discovered that they had misunderstood the functional requirements. Upon that discovery, the interviewee went back to define the external API for the system, but the back-and-forth reduced the communication efficiency.