System Design Interview — The Blueprint!
If you’re applying for a Software Engineering role at a Tech company (e.g. Uber, Netflix, Amazon, etc.), you will most likely come across a System Design interview question. Companies usually use this type of exercises in order to find out about the level of a candidate. In fact, using an open ended question like: “How would you design Twitter?”, can easily open the door to a lot of different areas, such as scalability, high availability, service architecture, data management, network issues, load balancing, etc. These areas can be explored by a candidate during the interview and the more areas you can cover, the better. It is very different from a coding exercise since there isn’t a single optimal solution for a given problem, it really depends on the scenario. Building a Chat Service is very different from building a Ride Sharing app for example. They both cover different use cases, but, they do share a lot of similarities when it comes to the areas I mentioned above (scalability, high availability, etc.). That’s what an interviewer wants to hear about.
If you already have an in-depth knowledge in building distributed systems, you’ll certainly make a huge difference over a less experienced developer. There are many entry level engineers who are very good at tackling algorithms and data structure problems (since it’s easy to learn and to memorize), but they may not succeed at a System Design exercise. Maybe because of a lack of real-life experience. Again, in a System design question, there’s no unique good answer. You need to be adaptable and you need to be aware of a lot of various components involved in building large-scale distributed systems.
There are so many different systems out there, how do learn about all of them?
Well, the good news is, you don’t have to learn about all the systems out there, which is the point of this article. Similar to algorithms and data structures, you can easily understand the main areas and apply them to different problems. They may not be the exact answer to the problem, but they solidify your choices. If you decide to go with a certain type of systems, as long as you understand the trade-offs and are able to explain to the interviewers all the reasons why you picked them up, then you should be good to go. Unless you really picked a very bad design ;-)
One process to rule them all!
If you follow the process above, you’ll end up building a logical path while answering their open-ended question. This may be valid for most of the large-scale distributed systems out there. Of course, this is only the bare minimum excepted from a candidate, but I can guaranty you that this will lead you to a good feedback from the interviewer. There’s no limit to a System Design interview besides the clock. If you can cover all that in only 30 minutes, you’re pretty good at it! You should also be able to be very flexible with this process because you may end up starting at step 3 right away. Or maybe your interviewer can take you deep down into a database schema, so that he or she understands what data you’d like to handle prior to jumping straight into the architecture diagram. So be adaptable and know your current location within that process. This will help you navigate around and will increase your ability to respond right away to any question, since you already know all the possible directions.
Practice by starting on a blank canvas.
Practice makes perfect. Make sure to practice by starting from scratch on a blank canvas. The idea for you is to learn how to apply this process for different scenarios. Interviewers know you may not have any experience with video encoding or dispatching mechanisms, but they’re expecting you to know how to scale a distributed system and how to cover all the main components (data base, services, load balancer, etc.).
Good luck with your interviews and I’ll be happy to hear about the outcome. Feel free to leave a comment here!
Cheers,
F.
