5 Tips for System Design Interviews (2023)

Introduction

Here are 5 Tips for System Design interviews. They are helpful when preparing for a System Design interview.

1. Don't get into details prematurely

2. Avoid fitting requirements to a set architecture in mind

3. Keep it simple, stupid! Remember to look at the big picture and avoid too many hacks when solving.

4. Have justifications for the points you make. Don't use buzz words or half hearted thoughts in your design.

5. Be aware of the current solutions and tech practices. A lot of solutions can be purchased off the shelf which simplify implementation. You should be able to argue for a custom implementation with it's pros and cons.

Have these on the back of your mind during you interview, and all the best!
Here are three major points evaluated during the interview:
1. Clarity of Thought

a. Express your thoughts in a clear manner.

b. Justify your decisions. Critical reasoning and argument are key to a successful software design.

c. When faced with a problem, use standard approaches to mitigate it. For example, say you are faced with an availability problem. State that replication and partitioning help increase availability in general, and move on to offer a solution.

d. Don’t make points without thinking them through. Half-hearted attempts at solving problems are frowned upon heavily.

2. Know about existing solutions

a. Stay up to date with the current solutions in the market. This includes products and design practices. If NoSQL is being adopted left right and center, you need to be aware of it.

b. Know when to pick a solution vs. building something custom. If you name a product, you should be (generally) aware of the features it provides.

c. Design practices enable you to meet custom requirements. Examples are decoupling systems, load balancing, sticky sessions, etc…

3. Flexibility

a. Switch your targets as the requirements shift. If the interviewer wants to know about one particular part of the system, do it first.

b. Never have a set architecture in mind. We all try to fit requirements to a system, but only after it has been shaped by the initial ones. A rigid attitude creates a brittle architecture. It will break before you do.

c. Take a step back at times to make adjustments to the general architecture. Being focused on one part can narrow our vision and bloat those areas. There will be components which can be extracted out and extended to the rest of the system.

Looking to ace your next interview? Try this System Design video course! 🔥
get.interviewready.io

With video lectures, architecture diagrams, capacity planning, API contracts and evaluation tests. It's a complete package.
Use the coupon code 'earlybird' for a 20% discount!

Video

Hi everyone, we are talking about five do's and don'ts for system design interviews.

Now these tips are very useful.

If you have your system, design interviews coming up soon, or if you're just practicing, and you want the maximum amount from each practice session.

Now, the first system design interview tip that I would like to give you is do not go into detail prematurely.

This happens very often when you're drawing services and databases.

And you know, clients that are going to be connecting to these people get into one part of the system and go into very very deep detail.

For example, if I look at the client and I say that I'm going to be connecting to these services, sometimes people say that all right there's going to be a gateway here is this too much detail maybe not.

But this is I.

Am going to be using the HTTP protocol, what's going to happen with this kind of a flow is that you are going to be talking all the time and that's, not what you want in a system design interview you're going to be talking for the majority of the time.

But you want the interviewer to be giving feedback where you often what happens with this is that when you go into detail and you take a flow, which is not what the interviewer wants.

They won't even stop.

You they'll, just let you run along.

And once you make the mistake, you'll need to backtrack and that's, not just wasting time in your interview that's, also a negative point because in the real world, if you did this, and you had to backtrack that that would cost money right? So avoid this point it's, very important that you do not get into detail until and unless you're sure, or you have asked that what should I do? So a good way to actually talk about the same thing is I'm going to be talking to all my services using a gateway.

Yeah, this is reasonable wait for one.

Second, wait for a response and then say, it's going to be talking to this service using a protocol, I, prefer, HTTP because it's widely used, and so the clients don't need to do something.

But again, take that pause, if there's something important it'll come up, maybe there direct you if I'm going to be talking about databases, and they want details, mostly they're going to be talking about drawing an entity relation degrom.

So you'll be defining your tables.

Well so that's how you go into detail you you wait for some time.

And you actually look for the first point, which needs detail for the system to be defined better.

Now for the second point, the second point is that don't have a set architecture in mind.

If you have something already thought out, you know, you have read some blog, which says that this is a really good architecture, maybe MVC, maybe event-driven.

And you just say that, okay, I'm going to be having this architecture and don't care about the requirements I'm somehow going to fit the requirements into the into the system.

So if I'm a fan of publish or subscriber models and I say, there's going to be a publisher and subscriber here, which is the only way that services are going to be talking to each other, maybe it's, not the best for the given scenario.

So if you are doing this again, what could happen is the interviewer might take it aman upon themselves to actually break this architecture somehow.

So the requirements may change, in fact, very often that's that's.

The thing that is done it's to test your flexibility when you have something which you feel is really good, and they throw requirements, which are completely different.

So don't have a very set architecture in mind.

It happens often when we don't have time for system design interviews, we are just reading all blog posts.

And we see something really go and feel like.

Yeah, this is going to fit everywhere.

That's, not the case, you know, whatsapp and uber have very different architectures.

The third one is actually a ki SS, which is very famous amongst programmers, keep it simple stupid.

You don't want to pick up one point of the service and just go on.

You know, getting into more and more detail about this service like I'm going to have maybe I'm going to have a heartbeat server, which is going to be talking to this.

Specifically, I am also going to be having another database for analytics for this service, you know, more and more you get into this specific portion of the architecture, the more and more narrow your viewers.

So what I would suggest is take a step back often enough, just take a step back and have a look at the entire architecture.

Maybe some of the things that you're doing here, maybe the heartbeat.

Maybe the analytics can be extend to the entire system.

And very often what happens is if you if you have a look at the diagram that you're drawing.

And if you see one part of the system, you know, huge and the other ones all tiny, thin, then it's, a good idea, it's, a good indicator that maybe your system either it needs change or it needs to become more simplified.

You can extract out components from one part and extend them to the other bits.

The fourth point is probably the most common mistake made in system design interviews.

And that is to make points without justifications.

If you have nothing backing up, what you just said, for example, I say that the database is going to be a no sequel database and I go even more concrete and say, it's, Cassandra.

One logical question is why? Why do you want that? And many of us in in these interviews? We feel the need to speak.

We feel the need to actually make points continuously because it's it's awkward.

The silence that is between you explaining and the interviewer evaluating that is very awkward.

So you might make a half-hearted comment on, hey, I can use Cassandra here, or you might feel like, hey axe, land was really cool.

So why not just add that to the system be sure about what you're speaking? If this Cassandra database is not going to be working well here that's going to be a negative point and that's going to be against you.

So avoid speaking without thinking, the points through the final point is to be aware of current technologies with this.

What happens is if you draw a part of your system, which is, for example, the database you can actually name the technology are using in that database.

So for example, if I say I'm going to be using an or sequel database, and we have already said, Cassandra, you can also use Amazon DynamoDB and so on and so forth.

What about a relational database, which is not like a no sequel database? I can use my sequel I can use Postgres.

Another thing that you might use for load.

Balancing is elastic load balancer.

So you might use the Amazon architecture to give you this for heartbeats.

You might use zookeeper for this message queue.

You might use rabid MQ so on and so forth, but me being aware of these databases.

These off-the-shelf solutions shows that I am knowledgeable and I'll probably take lesser time and lesser testing to implement my entire feature.

So these are the five important do's and don'ts for your system.

Design interview are three pillars that I see our system design interview standing on are the first one being clarity of thought.

So if you can express yourself clearly to your, interviewer, you can do the same with your teammates and that's a big plus point.

The second one is flexibility.

We talked about don't be stuck with one architecture.

And you know roll with the punches so flexibility is important when you're designing a system system design, an interview.

And the final pillar is knowledge if you are aware of what's going on around the world and you're able to design the system successfully.

Then this system design interview is a success.

So remember the five do's and don'ts that we have discussed over here and I'll be seeing you next time.

That's about actually designing a system from scratch.

So we are going to be picking up something and building it from scratch.

If you want notifications for that, you can subscribe.

And if you like this video hit the like button, I'll, see you next time.