Are 45 Minutes Sufficient for a System Design Interview?

Don’t Panic if You Are Not Aware of the Domain

Show What Skills and Knowledge You Have Instead of Figuring Out What Interviewer Is Looking For in You

One of the best things about these interviews is there is no right or wrong answer. These interviews are meant for interviewers to learn how much you know to design a system, how diligent are you in understanding vague requirements, and finding your way out (which often happens in the real world). You will most likely not be able to figure out what the interviewer is looking for when you are meeting someone for the first time in a high-pressure environment! But, if the interviewer mentions upfront, for example, he/she/they are interested in knowing how you would do caching/distributed caching, then you have the clue where to focus. So, focus on showing your knowledge to solve the problem instead of figuring out the XYZ skills the interviewer might be looking for.

Use Blackbox Technique for Trivial Process in Context

Once you are clear with requirements and have a plan about what services to focus on, don’t get into designing each service with which there might be interaction needed. Spend time designing only the main services. If time permits, come back to trivial services later on. For example, if you are designing a buyer experience from a furniture store, don’t spend your time designing a payment processor to complete the checkout process. Instead, put a box and label it as a payment processor that takes credit card information and customer details to execute the payment. The payment processing platform itself can be a system design question. Also, this does not mean that you put a bunch of boxes in the design diagram and call it done. So, don’t design each and every service that will be part of the interaction; use black boxes to represent trivial services in the context.

Always Bring up Tradeoffs When Telling Your Choices

Just telling your choice to the interviewer is not always sufficient. Before interviewers question you further, it's a good practice to bring up trade-offs and any other context that made you select option A over B. This also shows the depth of understanding and that it's not just a fluke or a random choice. So, don’t wait for the interviewer to question your choice, explain the reasoning and discuss tradeoffs about other approaches you considered.

How To Divide 45 Minutes

One of the major challenges that most of us face is how do we efficiently manage our time so we can come up with the most effective solution. Here is how I usually try to divide my time. I use the FUSH’D technique (I just made it up; don’t think anything of this sort exists anywhere). The below outline shows what it stands for.

Let’s see how much time I usually spend on each of these. All the times are approximate times and may vary in certain situations; however, I found this breakdown very effective.

• F = Feature Freeze, 5 mins (approx.): Use the first 5 minutes to ask clarifying questions and try to freeze 2–3(or more depending on context) features that you are trying to design. For example: If you are designing an online furniture store, you can think about below features:
  • Buy/checkout furniture
  • Search Furniture under different categories and tags(colors, material, size)
  • Wishlist / Save for Later
  • User Profile (usually this will be common for most of the applications)

Do the first pass with these features and suggest more enhancements such as customization, delivery tracking, 3D visualization using AR, etc. Be mindful that these things might need more time to drill into. The interviewer may ask to pick one of the enhancements that may sound more interesting. Also, if you think something can be relevant to your past experience or something you are really confident about, now is the time to include it.

• U = Use Case, 5–6 mins (approx.): For each feature you locked in the previous step, come up with use cases. Make sure to include negative use cases as well and highlight what your system won’t be addressing clearly. You can discuss trade-offs/preferences about picking specific use cases. Take some time to also do the calculation about traffic patterns, calls per second, expected SLAs, etc.
• S = Store, 3 mins (approx.): Depending on use cases and scenarios, decide what will you be storing. For a furniture use case, you will need to store inventory — item id, price, and quantity—  as well as the state of items in the user’s wish list, user information, etc. Also, check the amount of data that you will end up storing depending on the target audience and come up with estimates for your data store. Leave the door open for extension and growth in the future.
• H = High-Level System Design, 7 mins (approx.): This is the soul of the problem. Come up with the various components/services and define their high-level interaction with each other as per the use cases and features. Also, include how the end user will interact with the system, whether will it be API endpoints, Web UI, mobile app, etc. Figure out what database interactions will look like, or whether you will use any queuing mechanisms to queue any requests. You can start with a small system and scale it later. It is also the right time to touch about how to deliver responses efficiently and quickly, if you need caches, if it will be browser cache, Memcached, etc. with their trade-offs (go deep into it with a detailed design section). These discussions will show your depth of understanding about different aspects that you are aware of and consider in your design. (P.S.: Just using the terms is not sufficient: you should have a proper understanding too. )
• D = Detailed Design, 20 mins (approx.): This is where I would spend most of the time. I usually divide this section further as below:
  • APIs and Interactions, 7 mins: Start with defining APIs for the various use cases. Define POJOs. You can use microservice architecture and define specific microservice for certain features. Think about how you can improve SLAs and response times. Some interviewers can ask you to define classes and relations, and maybe write a minor function for a certain use case. Be open to it.
  • Database design, SQL/No-SQL data stores, etc., 5 mins: The interviewer may ask you to write a few SQL queries here. Be prepared to justify your choice with solid reasoning. CAP theory often comes in handy in making the decision about which database to choose for which use case.
  • Scalability, 7 mins: Most interviewers will be interested in knowing how scaleable your solution is. This is where you will take various measures to scale and optimize your response. How will you do load balancing to ensure that a single server is not overloaded with tons of requests while other servers are sitting idle? How would you do the distribution of requests as well as data (data sharding)/will it be geo-location-based, key-based, hash-based, etc.? What kind of caching solutions can you use? One important question that often comes up is: What will you do when data grows enormously large? How will you truncate or archive the data that might not be needed frequently, etc? You can also touch base about caching solutions and how to flush caches, ensure consistency or availability of cache, etc.

Be prepared for a lot of cross-questioning, especially in this section, as interviewers would like to test your knowledge not just on the concepts but may be also interested in knowing how familiar are you with the existing solutions in the market. These discussions are also done to check your communication skills, temperament, convincing power, etc.

This pretty much sums up how I would spend my 40 mins out of the interview leaving 5 mins for introduction/questions, etc.