- During the interview communication and problem solving skills are evaluated
- What is the communication? Show do you think → Tradeoff/Abstraction
- Interview Answering Framework
Before the interview:
- Is it OOP Design or System Design interview?
- Ask how much time do we have?
- Do we want to keep things on a high level? Or we need to go very deeply? What I mean we can start from single server, and DB and then think about scaling?
- I have a plan (front, backend, infrastructure), can we follow that?
- I want to have a conversion, and solve solve together. I want to show how it would be to work with me.
- Always restate the question.
- Check assumption.
- Always discuss tradeoffs. Pros and cons. And how we can solve cons.
During the interview communication and problem solving skills are evaluated
What is the communication? Show do you think → Tradeoff/Abstraction
- What are we looking for? Programming/Coding Fluency, Problem Solving, Communication/Collaboration
- What is evaluated? Your thought process and problem-solving ability. Your ability to listen and collaborate
- Check your assumptions always, repeat the question/argument, to check if you understand correctly!
- One of the most important skills as an engineer is to ask the right questions, make the proper assumptions, and gather all the information needed to build a system.
- Ask a lot of questions and disambiguate the problem statement.
- Always confirm all assumptions with the interviewer. Restate the argument.
- Why this solution is best, why the solution is not best? Defend your answer.
- Be open to feedback. Have a conversation/debate.
- Show how it would be to work with me. Talk like you are in a team at Reuters.
- Tradeoffs. If you add something, new problem will arise somewhere.
Dos
- Always ask for clarification. Do not assume your assumption is correct.
- Understand the requirements of the problem.
- There is neither the right answer nor the best answer. A solution designed to solve the problems of a young startup is different from that of an established company with millions of users. Make sure you understand the requirements.
- Let the interviewer know what you are thinking. Communicate with your interview.
- Suggest multiple approaches if possible.
- Once you agree with your interviewer on the blueprint, go into details on each component. Design the most critical components first.
- Bounce ideas off the interviewer. A good interviewer works with you as a teammate.
Don’ts
- Don't be unprepared for typical interview questions.
- Don’t jump into a solution without clarifying the requirements and assumptions.
- Don’t go into too much detail on a single component in the beginning. Give the high- level design first then drills down.
- If you get stuck, don't hesitate to ask for hints.
- Again, communicate. Don't think in silence.
- Don’t think your interview is done once you give the design. You are not done until your interviewer says you are done. Ask for feedback early and often.
Interview Answering Framework
Step 1 - Understand the problem and establish design scope. 10 min.
- The system design interview simulates real-life problem solving where two co-workers collaborate on an ambiguous problem and come up with a solution that meets their goals. The problem is open-ended, and there is no perfect answer. The final design is less important compared to the work you put in the design process. This allows you to demonstrate your design skill, defend your design choices, and respond to feedback in a constructive manner.
- Many think that system design interview is all about a person's technical design skills. It is much more than that. An effective system design interview gives strong signals about a person's ability to collaborate, to work under pressure, and to resolve ambiguity constructively. The ability to ask good questions is also an essential skill, and many interviewers specifically look for this skill.
- A good interviewer also looks for red flags. Over-engineering is a real disease of many engineers as they delight in design purity and ignore tradeoffs. They are often unaware of the compounding costs of over-engineered systems, and many companies pay a high price for that ignorance. You certainly do not want to demonstrate this tendency in a system design interview. Other red flags include narrow mindedness, stubbornness, etc.
Step 2 - Propose high-level design and get buy-in. 15 min.
- Come up with an initial blueprint for the design. Ask for feedback. Treat your interviewer as a teammate and work together. Many good interviewers love to talk and get involved.
- Draw box diagrams with key components on the whiteboard or paper. This might include clients (mobile/web), APIs, web servers, data stores, cache, CDN, message queue, etc.
- Do back-of-the-envelope calculations to evaluate if your blueprint fits the scale constraints. Think out loud. Communicate with your interviewer if back-of-the-envelope is necessary before diving into it.
Step 3 - Design deep dive. 25 min.
In most cases, the interviewer may want you to dig into details of some system components. For URL shortener, it is interesting to dive into the hash function design that converts a long URL to a short one. For a chat system, how to reduce latency and how to support online/offline status are two interesting topics.
Step 4 - Wrap up. 5 min.
- The interviewer might want you to identify the system bottlenecks and discuss potential improvements. Never say your design is perfect and nothing can be improved. There is always something to improve upon. This is a great opportunity to show your critical thinking and leave a good final impression.
- It could be useful to give the interviewer a recap of your design. This is particularly important if you suggested a few solutions. Refreshing your interviewer’s memory can be helpful after a long session.
- Error cases (server failure, network loss, etc.) are interesting to talk about.
- Operation issues are worth mentioning. How do you monitor metrics and error logs? How to roll out the system?
- How to handle the next scale curve is also an interesting topic. For example, if your current design supports 1 million users, what changes do you need to make to support 10 million users?
- Propose other refinements you need if you had more time.