Please enable JavaScript.
Coggle requires JavaScript to display documents.
System Design Interview - Coggle Diagram
System Design Interview
I. Purpose
Simulate a real situation at work of a high level task
The Software Architecture need to
Communicate
Translate into technical language
Desighn a system others can implement
II. Format
The interviewer provides a problem in a "vague" way
The Architecture Architecture will be assessed on
Design quality
Communication skills
Ability to handle
Ambiguity
Large Scope
Thinking on the right level of abstraction
Time limit of ~45 minutes (depending on the company)
III. Top 5 Tips for Success
Don't Panic
Memorization & Copy-Pasting don't work in System Design
Ambiguity is
Normal
Expected
Assessed on how you approach a problem you've never seen before
You have the process to handle this ambiguity (= System Design step-by-step process)
Communicate to Clarify the Requirements
If you don't understand the problem - ask the interviewer for
Examples on how the system can be used
Similar services in the real world
If you think you understand
Still ask the questions to gather Functional + Non Functional Requirements
What you think and what the interviewer thinks may be different
Clarifying the requirements
Can save your time
Is part of what you are assessed on
During the Clarifying process
Ask questions
Suggest potential requirements
Clarify what is
In Scope
Out of Scope
Figure out if this is Large Scale System Design Problem or not
The term "System Design" is overload?
If this is a Large Scale System, convince your interview of that by running some numbers (requests/day, storage)
Document your Design
The interviewer may not be the one making the hiring decision
Make sure to document important things you did
Discuss and agree on
Requirements
System's API
Calculation and estimations
Architecture Diagram
Documentation
Helps the hiring manager see the process and the final result
Helps you organize your thoughts
Think Out Loud
It's important for the interviewer to understand the logic behind your decisions
If you go in the wrong direction, the interviewer may help
Be careful not to get to much help
Discuss Trade Offs
If you're choosing:
A database type
Schema
Data Structure
Eventual Consistency vs Strict Consistency
Make sure to clarify
The benefits you're getting
Guarantees you're losing
It's ok if in the design in the interview is not perfect
Due to time limit we can evaluate everything
Demonstrate that with more time you would make the right decisions
IV. Interview Time Management
Gathering Functional Requirements
5-7 minutes (10 Max)
Gathering Non-Functional Requirements
5-7 minutes (10 Max)
Defining System's API & Sequence of Events
5-7 minutes
Designing for Functional Requirements
15-20 minutes
Designing Non-Functional Requirements
10-15 minutes