Systemic approach to ace your next system design interview
So you have your interview with a company in which you always to longed to work say Google and you aced that pair-programming session and next comes whiteboard session which is a very subjective topic as there are no few right answers like how you solved that coding challenge but you want to ace that 1-hour session and show your abilities that you could design an efficient system to crack that job. But how can you plan your preparation for this type of interview?
In this series of posts, I will try to layout a systemic approach to ace your next system design interview.
System design is a very subjective topic so whatever I am going to say here is based off my experience and talking to friends and peers, First I’m going to talk about the basic things you need to do in the interview and spend a good amount of the time about the topics which are very important for system design Interviews
Things to keep in mind during interview
What is your MVP
It is your responsibility to ask questions and define the minimum viable product for the system design problem you are going to solve. Any system design question problem could have many features you could implement but it’s your responsibility to work with to interviewer and figure out which features as an interviewer cares most about and which features is not very important. Remember, you’re working under very strict time frame, so make sure that your feature set is small and you go deep into those feature sets.
Scale of the system
Question should be about, “how much the system should scale?” So, for example, how much detail you need to you need to store in the database or how many requests per second needs to be handled or what kind of latency is expected from that system
Avoid BUZZ words
Suppose your interview is in a day or two and you read about this consistent hashing. Don’t just go to the interview and start throwing those words in the interview. It might work sometimes, but it does not work most of the time and in fact most times it backfires. So make sure whatever technologies are concepts you’re mentioning in the interview, you have some sort of in-depth knowledge on those.
50000 feet view
Before going into finer details of the problem, Attempt to define the 50000 feet view of the problem.
- Define all the APIs.
- Draw the right boxes.
- Make Understand who are the actors for the system.
Once the above layout is framed, then dig into finer details and prepare to drive the discussions. Maintain 80–20 rule, Which is you should be talking 80% of the time and interviewer should be talking twenty per cent of the time and always lead the discussion and don’t be rude and be humble, polite and importantly Listen, really listen to everything interview says.
Above points are easier said than done, Nothing comes out without practising so you can improve each of them in 3 parts
- Personal experience. If you’re working on a highly complex distributed system, it’s much easier to improve your learning by building those things or solve those problems in your project.
- Practice Think about system design question and work with your friends and peers and brainstorm those ideas and see what technologies you can use, what architecture pattern you use to solve this problem.
- Read Gaining knowledge through reading blogs and going through videos on YouTube.
Additional reading material:
The important thing after this is you need to work with the interviewer is on the features this system you are designing should have just enough to release it be as a minimum viable product, by asking good questions to the interviewer. For example, if the interviewer asks you to design a Whatsapp, then some features you would want to include is one to one chat and if to show the fact that the other party receives the message and read the message and so on, and some features could be excluded like group chat which can be built in the next iteration.
Identify the features, feature is something you have to work for the interviewer to understand what they really care about at that point of time and what they don’t care about and can be excluded.
Step 2(API spec):
Next is defining API’s. You need to establish what are the API’s for your service and Who is going to call these API’s and how are they going to call those API’s
Thinking about the availability of the service. You need to figure out how available the services. For example, if a Database went down, if the service still going to be available or if the entire datacentre went down with the service would still be available and you have to discuss with the interviewer to understand the how much availability disruption they can tolerate for this service.
Understanding the system latency. So if it’s a background service, they might not pay attention too much about the latency. On the other hand, if it’s a customer-facing service, then obviously you want your system to be super fast and based on the requirements you might want to introduce caching to improve system latency.
Now you designed a service that works for 100 users. But the question to ask if it is going to work for a thousand users or is it going to work for a million user and beyond that?
This might be important for some interviews and might not be for some other issues. So the reality is the fact that data can be stored in a database securely and data is neither lost nor compromised. So sometimes it’s OK to say that you will use X database and that will do all the job for me. On the other hand, where you are designing the database, where durability plays a central role and you need to make sure that your system is durable. Then we need to have a solid designed using class diagrams, establishing relationships between tables.
When you get questions like designing a parking lot or design an elevator system it is interesting knowing how you would design the classes and which are object-oriented principles you would use for solving those problems that we have security and privacy
When you get a question to design an authorization server for such a questions security and privacy will play a central role
Step 5(Cost Effective):
Whatever solution you suggested you need to this if it is a cost-effective solution and Is there an alternate solution which would be more cost-effective and you have to discuss some pros and cons of different solutions as far as cost is concerned.
Now that we know some of the basic things, we need to do an interview next. Let’s jump onto the concepts and topics which we care about, which you should know for before going into a design interview in the next post as this is time you might need to stretch your legs, drink some water. See you in the next post