10 Tips for Using Diagrams to Ace The System Design Interview

If you’re a software engineer interviewing for a backend role, you’ll probably be tested on how well you can design a system architecture given some goals and constraints. It's one of the most high-signal interviews, because it’s open-ended, which presents more opportunities for both mistakes and flexes. An important detail is that these interviews test not only your knowledge of backend systems, but also how effectively you can communicate your ideas.

The most effective way to communicate your design is to diagram on a whiteboard the design that you’re verbally explaining. It’s often necessary to draw it out, because sometimes the interviewer takes a picture and saves it for later review, potentially with other coworkers. From my experience of conducting hundreds of these interviews at top companies, the most effective diagrams are the ones that clearly explain your vision with minimal ambiguity.

To achieve that, the focus should be on simplicity, thoroughness, and cleanliness. It takes a deep understanding of something to explain something simply, and it's easy to see through any obscurity by complexity. Thoroughness is important to make sure there isn't some fundamental flaw that prevents your design from solving the problem. And if your diagram is packed with great ideas in a disorganized mess, the interviewer (and potentially others who review your interview) might not be able to understand it fully (or worse, misunderstand it).

Here are ten tips on how to diagram effectively for the system design interview.

When you start drawing your diagram, start with what you roughly think will be the core of your system, and draw it near the middle of the board. It might be tempting to start with what you're most comfortable with, or what comes to mind first, but given that the interview gives very little room for making big adjustments like redrawing an entire section, if you mismanage the space badly, it's going to result in a lot of mess.

Also take into consideration that some people might not be tall enough to reach the top of the whiteboard.

So, plan ahead and spend some time knowing broadly what your design will consist of and which directions it might expand into.

But don't spend too much time knowing exactly what will go where, because...

If you run out of time and didn't solve the problem but explained everything you presented in detail, that is as much if not more positive signal. You're not being tested on how you manage your time. Unlike an algorithm question, the open ended nature of this interview isn’t looking to solve for x. The prompt is generally to get the ball rolling on an in depth technical discussion.

Taking detours and diving deep on a particular area is part of the interview, and it often reveals strengths and weaknesses so much better than a shallow coverage of the system. If the interviewer has a particularly meaty section they want to get to, they'll let you know. If they interviewer presses on a particular part — great! Don't try to rush to completion, giving a thoughtful answer when they've specifically asked about something is a very positive signal. Improvise and make this discussion part of your diagram, even if it doesn’t fit neatly with your original plan.

After a back-and-forth, ask them if your responses make sense. Confirm that you've pulled this thread hard enough, you want to give your interviewer a feeling of satisfaction that you answered their line of questioning well enough.

The whiteboard is not just for drawing — use it to write as you're being given the prompt, as you clarify assumptions, and as you make inferences. Having a checklist helps guide your train of thought as you diagram. When you're drawing the components and interactions of your system, keep referring back to the checklist and make sure you aren't violating any constraints and are fulfilling the goals.

For example, in the classic "design a URL shortener" example, an item on the checklist might be, "can handle 1M requests/second". As you're drawing out each component, look back and make sure that it isn't a bottleneck for this requirement.

This also helps your interviewer and you be on the same page. Misunderstandings of the prompt happen all the time, and by writing a checklist, it leaves no ambiguities as to what the goals and assumptions are. It's worth the time to do this.

In the rush of the moment, it's easy to forget to label what you're verbally explaining a component is. Drawing a box and saying, "and here's a cron job that monitors health", everybody in the room could nod and you continue along, but will it be clear what that mysterious box is at the end of the interview or in two days when it's reviewed? Clearly give a label to every component, and sometimes even connections if they're not obvious.

With a cloud, cylinder, and rectangle, you should be able to convey every component that your system diagram represents. If you've done it many times before, you can use other universally recognizable shapes like a lock and key, but if you need to preface with the words, "I'm not an artist", don't draw whatever you're about to draw. If you've labelled everything, the choice of representation is extra. This can only hurt you by causing confusion and doesn't reward you if you draw the most beautiful key to ever represent encryption.

Some people might have a specific schema (e.g. UML) in mind they're used to, like dotted lines mean soft dependency or diamond-head connection end means foreign key. Don't rely on those assumptions in an interview unless you explicitly label it as well. There's simply no guarantee your interviewer shares the same diagramming language as you.

There's always extra insights you can give while you draw. Don't draw in silence and put the interviewer in the position to have to question you on everything for you to speak. They want to hear why you're drawing whatever you're drawing, what are some alternatives, what are the edge cases, when would this not make sense, etc. Practice simultaneously talking while drawing your diagram. Done well, it really shows confidence that you know what you're doing. It also invites questions. When the interviewer gets a question that they came up with on the spot answered well, they remember those moments.

Walked through the whole API request but added a queue somewhere? Do a quick revisit of already-explained flows to make sure that the new component doesn't inadvertently affect something. Don't spend too much time going over every detail that you've already gone over, since that could look like time-wasting. It demonstrates an attention to detail when you show that you're double checking how the introduction of a new part of the system affects other parts, as well as an awareness of the big picture.

If your diagram has a lot of components, make some logical groupings and outline the boundaries, maybe with different colors if convenient. Make sure you label the groups. This helps keep a potentially overwhelming amount of information more manageable. It also gives the diagram a very clean feel.

Chances are, as you diagram, you'll have to revise earlier drawings after discoveries midway through the process. Having an eraser on hand and actually using it lets you correct course quickly and cleanly. It's what a whiteboard is for. Sometimes interview rooms might not have an eraser — just use a tissue if that's the case, or in the worst case, use your hands or sleeves (you can buy a new shirt when you land the job). The point is, don't be afraid to backtrack once you know you've made a mistake. The self-awareness of it itself is a good signal, and erasing the original doesn't give later reviewers a chance to also see your mistake.

Lastly, one thing you should never do while diagramming is to leave a section nebulous with a handwave and a dismissive comment. This is something that comes up very often with candidates that are rejected. When faced with a weak point in their system design knowledge, they attempted to hide it rather than try to figure it out with what they know and some hints. With the former strategy, the interviewer is trying to break your facade, whereas in the latter, they can be on your side and supplement what you know with what you're missing and see how you take in new information. It's a huge red flag to assume something is trivial and handwave it off, only to be pressed to a point where you have to admit you actually don't know.

The system design interview is the most communication-heavy technical interview there is, and a great performance on it can really compensate for some weaker performances elsewhere. It also is a lot more related to what you'd actually be doing on the job versus some other interviews where you're tested on something like algorithms. As a backend engineer, you'll often have to diagram your designs in a way that's clear and explanatory in meetings, ad-hoc discussions, and recorded documentation. Hope these tips have been helpful! Feel free to email at jacob@terrastruct.com if you have any questions, I'm happy to help.