In my last 10 years at Uber + eBay, I have taken on 100+ interviews with Candidates coming from top companies like FAANG to no-name startups. I myself have interviewed in 10s of great companies. I have interviewed in the Bay area as well as Bangalore. During all this time, I made tons of mistakes in my interviews and lost many interesting opportunities. Like everyone, I blamed myself, but not for the right reasons. After being on both sides of the table for years, I learned how this actually works. I wish I had known these things earlier. But it is never too late to share. So starting with this one, I plan to talk a lot about how tech interviewing works or doesn't ;)
Among all different types of interviews, the Architecture round is one of the most crucial rounds for Senior Software Engineers. Many engineers who are really well at coding and problem solving, make a few mistakes in the Architecture round and are then either rejected or down-leveled. In fact, in strong tech companies, even Senior Managers are expected to do well in this interview. While the expected level of depth may vary, the fundamentals expectations remain the same.
That is why, I intend to demystify the architecture round in this blog. If you are preparing for an interview at some of the top companies like Amazon, Apple, Google, Facebook, Uber, hottest startups or equivalent tech companies, read on.
Let's first try to understand this interview better. The fundamental question is - *What is the interviewer seeking by asking you to design your own twitter or URL shortener or Video Streaming Service? * Generally, many good interviewers tell their expectations upfront. You should really pay attention to that. But if I have to write it in a one-liner, the purpose of this round is -
To understand how the candidates break down a high-level system into its sub-components, identify the most appropriate technologies to build those components, keeping principles like separation of concern, efficiency, reliability, security, and scalability in mind.
But in order to give the interviewer answers to what he/she is seeking, you need to approach the Architecture problem in the right manner.
I have broken down this into 6 different areas to explain this.
1. Collaborate with Interviewer
Interviews are very much like role-play scenarios to mimic a real work environment. The interviewer just initiates the conversation by putting forth a problem statement. After that. you are expected to drive the discussion forward. But like a real work situation, the interviewer wants to collaborate with you to reach the final solution. As you go on discussing the problem, you should take the interviewer's response into consideration, propose choices, and make decisions that are correct and agreeable to both. This process is more like a conversation than QnA.
2. Ask Right Questions
Just like a real work environment, the problems are never crystal clear. After giving a high-level goal like say "design Netflix like system", the interviewer expects you to refine this problem. The refinements are in multiple dimensions. The candidate is expected to ask questions, state assumptions and bring clarity into -
- Business goals - i.e. Define the primary entities and use cases of the system.
- Engineering goals - i.e. Number of users, frequency of engagement, security, scale, performance, reliability, developer experience and responsiveness of the system
Spend a good 5-7 minutes to discuss these and understand what kind of system you are about to design. Instead of following this like a checklist, ask the questions that make the most sense for your problem statement. e.g. If you are designing a banking system, security may take the highest importance. So right from early design, keep the focus on these aspects.
3. Divide and Conquer
Now that you understand the problem better, the interviewer is expecting you to define sub-parts of your system. Remember the principles of good designs e.g. separate of concern, synchronous vs asynchronous flows, customer obsession, etc.
But in a real work environment, systems are designed iteratively. So, don't go crazy calling everything as a separate component. In most likely cases, either interviewer is not interested in all of them or not going to have enough time to go into all of them. So rather, define a few high-level components, define their responsibilities and then break them down as conversation starts going deeper into each of them.
The same goes for your data modeling/architecture. Define key attributes about each entity to store and relationship between them etc.
4. Choose the right technologies to build components
The next step after defining components is implementation choices. In order to implement any component right, one must understand how use cases drive the usage of each component. e.g. Is your system read-heavy or write or both? Is data freshness important in this search functionality? How many jobs are expected to be run on this scheduler? What is the criticality of this component? How many developers are going to write code into this framework? etc. So again, collaborate with the interviewer to be clear on goals and then choose the right technology to fill the gap.
Often, there are more than 1 technologies that can solve the same problem. So you should propose all options and discuss the trade-offs before you commit it as a solution. This gives the interviewer insight into the depth and breadth of understanding of the technologies you are proposing. Also, the interviewer expects you to know much deeper about the technologies you have used even in your past experiences. So go prepared for that :)
5. Think of points of failures
For all the core flows of each component, you should talk about how failures and hotspots will be handled. Being proactive to call these out matters a lot. Also. be specific about things that should be done instead of just throwing buzzwords e.g. X system is at risk if this Y service goes down and hence we should have a circuit breaker here. Or this image cache should have an LRU eviction policy.
Most outages in companies happen because of human mistakes. Great senior engineers not only talk about the technical failures but also talk about what best engineering practices to be followed to make the system more resilient. e.g. keeping a free form JSON data in a NoSQL database can lead to abuse and mistakes. So there should be schema management with it. Best practices could be about configs management, testing, environment management, monitoring, and logging. You should proactively talk about these.
6. Manage time efficiently
This interviewer is going to be your representative in the final debrief. Do not beat around the bushes and waste time into trivial conversations e.g defining 10s of attributes for a User entity. Defining the key ones like user_id, email, password, and a few secondary ones are enough. While covering all the aspects of the system design in a given time can be challenging. But you want to make sure that a moderate level of depth and breadth of the system has to be discussed for the interviewer to feel confident.
That's it! If you have made it this far reading into the blog, you can see how Architecture interviews go both - broad and deep. Mastering this interview is hard, but make sure you do enough practice with your peers, senior colleagues. Nail the fundamentals and all the best!
Thanks for reading. If you find want to talk more on this subject, you can reach out to me on Twitter
Top comments (1)
Hey nice article, I also wrote about Circuit Breaker Pattern, dev.to/boxpiperapp/circuit-breaker.... I guess dev.to community is not ready for such content, interpreted on the basis of impressions we have on this topic.
