You Too Can Make Diagrams

Written: February 16, 2024

Updated: October 23, 2024

Spoiler Alert: It's Not About Natural Talent

I often recieve compliments on my diagrams or my ability to make them while talking to people. Many are intimidated by technical diagrams assuming they require some deep knowledge or artistic ability but this is a learnable skill.

During an interview, it may be useful to use them to demonstrate your knowledge and your communication skills. If you have never drawn technical diagrams or used a whiteboard before, I highly recommend learning. You may also want to check out my post All About API's !

A few tools you might want to know about:

Draw.io
Mural
Figma
Gliffy
Google Drawings (very basic, shown below)
Visio (a bit old school now)

I'll include a few diagrams to give you some ideas but you'll have to dive much deeper for real world examples and applications. It is also important to remember that visualizations can be used to express complex ideas efficiently but they can also hide complexity. Interviewers, especially engineers, will want to know more about each box and each line. What are its properties? What are the technical implications? Try to keep the content of the diagram relevant to the conversation and be prepared to dive into details.

3-Tiered Architecture.

Often referred to as the "wedding cake" architecture or "pancake" diagram, this diagram intends to showcase a common pattern for web services to logically separate their code. The goal is for each layer to remain agnostic to the other so that they may evolve more independently.

Let's say you were using JQuery, Spring Boot, and Oracle DBMS to build your website. Keeping these technologies neatly separate in your code and minimizing their interactions means that you can swap out pieces over time. You could introduce AngularJS, or Django, or NoSQL databases without having to rewrite all three layers.

Check out Wikipedia information about multi-tier architectures.

Three wide stacked rectangles with text "presentation", "service", "data" from top to bottom.

Model-View-Controller (MVC)

The MVC architecture offers a similar pattern to the 3-tier architecture in that it abstracts specific characteristics of your API or service into separate components. A developer defines a model (think classes in object-oriented programming or entities in database design) which can represent the problem, domain, or state of the world. The model is just a container for information and does not specify behavior, business logic, or visual representation. Data in the model is changed by the controller. An HTTP endpoint is usually analogous to the controller. Finally, the view handles presentation, formatting, visualization, of the information in the model to the user. A popular implementation is Spring MVC though it is being quickly replaced by more cloud oriented solutions.

Entity Relationship Diagram

In broad terms, an ERD depicts the objects or entities that matter to the domain and their relationship to each other. The goal is to capture the names of the entities and their properties (both property names and their data types) and whether they relate to each other in a one-to-one, many-to-one, or many-to-many relationship. This is also where you'll see STAR patterns, dimension and fact modeling patterns, or OLAP/OLTP patterns visualized. You may consider tracking primary keys, foreign keys, and indexes as well if you are designing for a database.

This isn't purely a database technique though. You can also use it to describe payloads for API's without writing them in JSON or XML during an interview.

It's Just Boxes And Lines!

Again, it's all just boxes and lines. Just like in coding interviews, you want to keep talking while you are drawing. Not literally, just draw a box or a line, state what you did and why, then move on.

You can use conventions to improve your impact. For example, databases are often drawn as barrels/cylinders, data lakes are lakes, and clouds for clouds.

Logos And Icon Sets

There is a lot of common iconography all over the web. Many logos are available for popular tools and some companies like AWS even produce assets for public use. These can make diagrams more exciting or familiar. However, there's a limit to the specificity available to logos and icons. Summarizing your entire streaming architecture as "Kafka + Flink" is at most directional. This can be very useful when you need to leave implementation details for later but can also be overly vague and create false confidence in your teams ability to integrate two tools.

Have Fun!

When you're just trying to get the point across, boring straightfoward slides will get the job done. This is especially true when whiteboarding live. However, if you find yourself with a few minutes, play around! Visual interest can be a powerful tool to keep people engaged and drive home a message.

Take this diagram about dbt. Using rectangles with dark fill color and basic lines felt heavy. I lightened mixed up the shapes, lightened the background, and even played with gradients. Gradients seemed like a terrible idea but using a subtle color shift helps a lot. Finally, the chunky orange curvy dashed lines add a splash of color and a playful vibe.

Or not, I'm not a designer but I think it looks better. Don't be afraid to have fun and express yourself a bit.

More Tips

A lot of software diagrams borrow from Unified Modeling Language or UML. The spec can be quite detailed. In practice, I have found few workplaces that adhere rigidly to UML.
Pay attention to your options in your tools like available shapes, colors, arrangement/alignment options, and line options. Simpler tools provide limitations that can improve your efficiency for simpler tasks but can be prohibitive for more complex tasks. Simpler tools are easier for others to learn and share your diagrams and let you focus on the problem, not the diagram. However, if you find yourself unable to express your idea or spending lots of time grouping objects to represent more complex ideas, consider a more advanced tool.
Use a legend. Introducing a legend means that you can introduce diagram-specific conventions. For example, a dashed line might represent the response to an API call or the return value of a function. In this case, you might mix line features like thickness or solid/dash/dotted patterns which should be explained to the viewer.

Did you find this useful?

Tell Us What You Thought

Page updated

Google Sites

Report abuse