Systemic approach to ace your next system design interview
| Reading Time : 6 minutes | #backenddevelopment
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
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.
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
Additional reading material:
https://github.com/madd86/awesome-system-design
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.
Step 1(Features):
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
Step 3(Availability):
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.
Step 4(Latency):
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.
Step 5(Scalability):
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?
Step 5(Durability):
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
powerctl is a little weekend project I put together to provide a simple tool for managing power states on Linux. I had previously put my laptop into suspend with a basic “echo mem | doas tee /sys/power/state”, but this leaves a lot to be desired. I have to u…
via Drew DeVault's blog August 28, 2022Links to exhibits from the Microsoft anti-trust case, with a bit of info on each link. Projection of PC marketshare Share of new browser users Share of the browser market, grouped by major ISP, 3 month moving average Share of the browser market, grouped by ma…
via danluu.com August 24, 2022Hi all! This month I’ve been pondering offline-first apps. The online aspect of modern apps is an important feature for many use-cases: it enables collaboration between multiple people and seamless transition between devices (e.g. I often switch between my pe…
via emersion August 14, 2022Generated by openring