I personally find that system design interviews are a lot easier than coding interviews. Much of the skill sets are the same but the abstraction and level of detail is different. Instead of knowing the intimate details of the code logic, it's more important to know the intimate details of the interfaces you're creating and the trade offs you're making by choosing one tool over another.

I think system design interviews are easier as long as you have the requisite experience and knowledge. In other words, it's hard to know what you don't know, and if you haven't had experience with certain technology, you're at a disadvantage. From my recent interview experience, I've come up with a few tips for system design interviews.

Ask clarifying questions to understand the problem

Depending on the setup of the question, system design can start out pretty simple. For me, it's easier to communicate my understanding of the problem if I write out things on the board. Much like a coding question, it can be hard to anticipate the nuances of the problem before you test it against a solution. This isn't to say that you shouldn't try to ask initial questions, but writing something down may help you trigger questions you can ask to clarify and understand the problem.

Write things down

Draw out a high level diagram describing the data flow of your solution. Write out the trade offs using a pros and cons list. Write down the schema of your communication protocol.

Discuss the trade offs of your solution

System design and engineering are all about trade offs. What is the advantage of picking one technology over another? What are the trade offs you're making by picking one over the other? Is one technology or solution outright better? Why?

Ask yourself why when you make any decision and be sure to verbalize and vocalize why you made the decision.

Modularizing your design

If you have a backend, maybe it's better to split it up into separate services maybe it is better to leave it as a monolith. Discuss this with the interviewer, and modularize services when it makes sense. Operating at a larger scale is a great reason to split up a monolithic service.

Think about how your solution scales

Your interviewer will likely try to throw a wrench in your simple system. Scale is the number one thing you want to think about as it's the most common complication a system can encounter. Suddenly, you go from 10K users a month to 1M users, how does your database, services, and system as a whole handle this?

The most common one I've seen, is what happens when your database can no longer handle the amount of data. A few generic solutions I like to consider are caching, alternate storage mechanisms, sharding, etc. And as with any solution, discuss the trade offs of these different scaling solutions.

When thinking about scale, think about fault tolerance as well. What will your system do if calls to an outside service fail?

Creating database models

Write out a schema. Your interviewer and you will greatly appreciate it. You'll be on the same page for how this data may be queried.

Make sure to discuss optimizations like choosing indices, foreign keys, and reasoning for join tables. Does something need a many to many relationship? Why?

If you choose to use a non-relational database, explain why this will be advantageous and over a relational database.

Designing a communication protocol

Write out the schema for your interfaces. If it's a RESTful API, mention that it will be RESTful and adhere to restful semantics. Describe the schema of the responses and potentially any error cases that might be worth discussing. Ask yourself how this schema will be used by its consumers.

Iterate on your solution

Just like in a coding interview, iterate on your solution. Break things down into separate services where it makes sense.

Final Thoughts

System design is about gaining experience, seeing different problems, and knowing what technology work best in different situations and why. At the end of the day, justify your solution by weighing the trade offs and keep calm, if you get stuck. Also, remember your interviewer is a resource. They want to know how you'd behave and act during an engineering discussion, so treat it like you're coworkers where you're leading.