System Design Interview – Tips & Tricks | Common Mistakes to Avoid

When preparing for a system design interview, it’s important to be aware of common mistakes that candidates tend to make. Here are some mistakes to avoid:

1. High-Level and Low-Level Design

A lot of times candidates don’t ask if the interviewer is expecting low-level design or high-level design and jump on with any one of the designs. So make sure to ask the interviewer, the design level he/she is expecting before presenting your solution.

Let’s understand the basic difference between High-level design and low-level design

In high-level design (HLD) we focus on the overall architecture and structure of the system at a conceptual level. It deals with the system as a whole, identifying the major components and their interactions. In contrast, low-level design (LLD) delves into the specific details of individual components, modules, and algorithms.

HLD involves abstract thinking and decision-making, emphasizing system-wide functionality, major modules, and their relationships. You will need to use block diagrams, flowcharts, and conceptual diagrams to represent the system. LLD, on the other hand, works with concrete implementation details, specifying how each module functions, data structures, algorithms, APIs, and interfaces.

2. Functional Requirements for a Design

Let’s say the interviewer has asked you to design Uber. And let’s say you know how Uber is built. So, you might directly jump on to the solution by explaining your approach right?
But don’t do this, Why? Because Uber(or any other Application) can have lots of functionality. Maybe the interviewer is interested in some particular part of the implementation.

So make sure to ask what are the specific functional requirements for a particular design. Based on the functional requirements your design could totally change.

3. Scale of the Design

Let’s say you are building a chat application that is to be used in a small company having 50 employees. The design of that application would be totally different when compared to a chat application like WhatsApp, which is used by millions of users.

So, let’s say the interviewer is expecting you to build a small chat application and you give him the design procedure for WhatsApp, then that won’t have a good impact on the interviewer.

So clarify this in advance, what kind of scale is being expected?
1. Like what number of users will be there?
2. Some information on throughput
3. Data Size, etc, before jumping into your approach.

4. Ignoring scalability

Scalability is a critical aspect of system design. Neglecting to consider how your system will handle increased load and user growth can be a major mistake. Always think about horizontal scaling, caching mechanisms, and load balancing.

5. Overengineering

While it’s important to design for scalability, overengineering can lead to unnecessary complexity. Keep the design simple and modular, avoiding excessive layers and unnecessary components. Strive for a balance between scalability and simplicity.

6. Time your Design Solution well

What happens is sometimes people get some much involved in some particular component and they skip all the remaining details as they run out of time. Typically design interview goes for 40-45 mins. So, remember this time one needs to cover a lot of things.

Let’s say you’re asked to explain high-level design for any application. One good approach could be:
1. You could start with basic building blocks on what all components are there.
2. How do they interact with each other.
3. And then get into the depth of one or two of them.
4. While deciding which one to be explained in depth, don’t just assume and go with any component/functionality.
5. Ask the interviewer what they would like to talk about.

7. Nobody expects you to know everything

Candidates may assume they are supposed to know everything and might become uncomfortable when the interviewer asks them something which they might be not aware of. Or they may pretend as if they know and present an improper solution/approach.

Don’t do that if it’s a small component that you are not aware of. Let’s say the interviewer asks you to build a rate-limiting system(a mechanism used in system design to control and limit the rate at which certain operations or requests are processed or served) for Uber. You could clearly say, I don’t know how to build a rate-limiting system, but if I were to build it, I would build it in this way. That would give a good impression on the interviewer irrespective of whether your approach is right or wrong because it says at least you know what you don’t know.

And it’s always okay at this point to ask the interviewer about some tips, and if your approach is going in the right direction or not.