DEV Community

Cover image for System Design is More Important Than You Think
David Zhang
David Zhang

Posted on

System Design is More Important Than You Think

This past month, I've been going all in on system design. After face-planting badly in one of my interviews (Temper your imposter syndrome by reading my previous blog post about my hilariously bad performance), I took the failure personally and decided to dedicate some serious time towards improving my system design knowledge and skills. If there's one thing I learned on this journey, it's that system design isn't just an interview prep thing, or something that only senior engineers should worry about. It's a vital skill that every software engineer should try to regularly practice and develop.

Story time: I launched System Design Daily, an interactive study tool for myself mainly, but also other engineers who want a more engaging way to learn these concepts. I've recently added some gamification features that I'm pretty excited about, but that's a story for another article.

system-design-daily-progression

Hard-stuck bronze in both Valorant and system design interviews

After launching the site, I got a whopping 3 users: me, my test account, and my partner who I definitely did not force into using it.

system-design-daily-users

Me checking my user numbers at launch

It was time for some #digitalmarketing and #buildinginpublic. The only problem was I had about 14 followers on Twitter and about 4 posts in the span of 9 years. I'm not a big social media guy.

At first I went the Herbalife route and hit up all my software engineer friends and family, begging for some feedback on the site. This kind of worked, though one issue was that all my close friends and family were job-havers, and weren't actively interviewing. So this tool wasn't really of much use to them. (Hopefully by the end of this article I'll change their minds).

I decided to change up my strategy and talk to strangers on the internet instead. Instead of asking them to go use my site, I asked for stories and experiences. I began by hitting up my LinkedIn network, specifically looking for #opentowork folks like myself. I then expanded to Reddit and random Discord communities. And in speaking to people and reading people's comments and replies, I began to realize a few things about system design.

The Job Market 💩🔥

Speaking to fellow unemployed brothers and sisters yielded two key realizations about the state of tech hiring in 2024:

  1. The job market is super competitive and terrible
  2. If you're a new grad - point 1, but like put it in big red text with flames and a skeleton for extra emphasis.

It's freaking brutal out there. Engineers are getting laid off left and right. Tons of people with lots of experience are flooding the market. Many of them are absolute Leetcode gods - I've seen some profiles with more Leetcode problems solved in a single day than I do in like a whole year.

What does that mean? It means that everybody is good at the coding interviews now. There are half a billion Youtube channels explaining Three Sum and Fast and Slow Pointers. Literally every question ever asked or ever will be asked is on Leetcode. As a result, the interview landscape is starting to change now that companies are starting to get wise to Leetcode grinders memorizing solutions, and, in some cases, system design and behavioral interviews are supplanting Leetcode-style interviews entirely. The bottom line is: if you are an engineer trying to compete, Leetcode is no longer enough.

For industry hires especially, you can't really afford not to be good at system design. At your level, system design and behavioral interviews are going to be the determining factor for whether or not you even get the job. System design in particular will be used to determine your seniority level. So it also serves you well to know this stuff if you want to make the big money and impress blind.com.

system-design-studier

The Average System Design Studier, circa 2024

For you new grads out there, you might be thinking - well I'm off the hook right? Wrong! (kind of). While it's true that you won't normally be asked to showcase system design knowledge in your interviews, it's an extremely important long term skill to develop. That's because knowing system design will accelerate your career. I'll get into this in more detail, but long story short, you'll build up a design "sense" and systems knowledge that'll empower you to reach for more responsibility in your job. The end result is a fast track towards those senior / principal engineering roles with the giant paychecks.

And another thing for the new grads out there - While the system design reaper won't be knocking at your door for now, it's evil little brother low level object-oriented design most likely will. Sure, it might not operate at the same granularity, but it exercises the same overall skillset: you'll need to gather requirements, organize and describe your classes, and explain how they interact with each other.

Career Growth

So you might be thinking to yourself, "well, I have a job. Let those unemployed fellas worry about system design"

First of all, I admire your confidence in believing you'll have permanent job security - especially with the recent mass layoffs in tech and the rise of AI.

But secondly, I believe that system design can be useful even for you employed folks out there.

There's a reason why system design is used to hire for senior engineers. System design is a gauge of experience. The people who are best at system design have seen a lot of things and have built a lot of systems. They know what can go wrong because they've been there, and can design accordingly to mitigate potential problems.

But just how do you get to work on those systems? Sure, maybe your manager will trust you enough to just hand you large scale projects unprompted. But 99% of the time, you'll need to ask for more responsibility and ownership. And in order to do so with confidence, you'll need to prove that you understand things like architectural patterns, data storage technologies, and scaling strategies. In short, system design will help you go from junior to senior.

Ok, so what if you're already a senior or principal engineer? How does this help you? First of all, teach me pls. But second of all, technology is constantly changing, and it's easy to lose these skills if you don't keep them sharp.

When I worked at Amazon, one of the biggest things I was cautioned about was how easy it was to get isolated from the rest of the wider software world. When you always use the same tools and processes, you start to rely on their ability to do the right thing, and eventually forget why they're built the way they are in the first place. You also shut yourself off from new ways of approaching problems that you might not have thought of. Reviewing system design topics will also help you stay on top of the latest paradigms and technologies and will make you more adaptable.

System Design Ain't Leetcode!

That brings me to my next point. System design is not like Leetcode. What do I mean by that? Well, there's a popular mentality among software engineers that "interview prep stuff" (which usually consists solely of Leetcode), is a thing that only sees the light of day when it's time to find a new job. Under normal circumstances, "House Robber II", "Merge K Sorted Lists", and the rest of the Blind 75 gang get buried under a foot of cement in the basement of your memory.

john-wick-opening-guncase

Engineers re-starting their Leetcode premium subscription be like

To be honest, this is a perfectly fine way to approach Leetcode and DSA/coding interview prep in general. That's because most of the problems you'll be solving aren't things you'll encounter in your actual job. And what's more, the "whiteboard interview environment" is a completely unnatural setting contrived by large companies trying to filter out applicants. In no real world context will you ever have to produce an efficient implementation of an often obscure algorithm entirely from memory in under 40 minutes. So, like a pull-based CDN, you pretty much only retrieve this knowledge and skillset from object storage when needed.

This isn't a new idea at all. "Leetcode interviews" have been getting (rightfully) roasted by tech influencers for some time now. But I'll argue that while this "cold storage" mentality makes sense for Leetcode, it does not and should not apply to system design.

As I've mentioned before, system design actually has real world applications. You won't always have a ton of opportunities to design high level system architectures in your job. Your day to day will inevitably get crammed with non-design related work, so you need to exercise your design muscles with a healthy regimen of study and practice.

Furthermore, system components and design patterns are constantly evolving alongside the tech landscape as a whole. That means you need to keep up with them if you want to stay on top. Understanding system design gives you a framework to do that effectively.

The Takeaway: System Design Is Dope

At the end of the day, knowing system design will make you a better engineer, plain and simple. Though it might just sound like I'm just saying that because I'm working on a system design study tool, I really believe that understanding how scalable distributed software systems work will make you better at building scalable distributed software systems.

I've also just found it fun and cool. Of course, the prescribed methods and resources for system design can feel like the opposite. But if you can get past the often dry and bland presentation format of the material, you might, like me, become captivated by how companies with insane scale deal with the unique, often unexpected problems that come with it. For all the gamers out there, it's not unlike playing one of those optimization or management simulator games (think Factorio, Two Point Hospital, etc.).

Anyways, I just think System Design is great and underrated and wanted to talk about this. That's about it. See ya.

Top comments (13)

Collapse
 
veldakiara profile image
Velda Kiara

I really enjoyed reading your article Zhang.

I played the quiz game on your site, I would be happy to be part of the people you ask for feedback incase you want to add more features or games.

Thank you 😃😊.

Collapse
 
squidbe profile image
squidbe

That's because most of the problems you'll be solving [in interviews] aren't things you'll encounter in your actual job.

(My response to this is looong, so the tl;dr is there's little to no evidence that algo solving correlates to on-the-job success, so why not test candidates on something that reflects what their day-to-day experience will be?)

Long version:
As someone who has been on both sides of the interview table more times than I can remember, I find what you pointed out to be endlessly frustrating. Given that interviews are such an important process for any company, it's baffling that there's so little science backing up the ways many companies choose to conduct interviews. Frankly, there's a lot of lemming behavior. "FAANG does it, so it must be right."

In interviews, we're sometimes asked, "Tell me about a time you used data to make a decision." I'd like to ask interviewers, "How do you use data to determine how you conduct technical interviews?" I've actually asked some colleagues this question (I haven't been brave enough to ask it of an interviewer when I was the interviewee, though I've often wanted to 😊). I haven't received a single answer that wasn't some variation on anecdotal evidence, and that's not surprising because correlating interview performance with job performance is a highly qualitative assessment, and a difficult one at that.

But given the lack of quantitative data on the subject, doesn't it make sense to ask engineers to do something that reflects what they'll be spending most of their time doing on the job? (That's a rhetorical question 😊.)

The last time I was in a position where I was interviewing candidates a lot, I came up with a mini app for them to build which included a variety of assessments including algorithmic, experiential, research methods/approach, language knowledge, and time management among other things.

The last one (time management) was important in that the app was purposely designed to be impossible to finish in the allotted 45 minutes – I told them they were not expected to completely finish it, and they were free to use Google or any other online resource for help. The point of this was to have a better metric to compare candidates. If everyone finished the exercise, then the assessment would be entirely qualitative and, hence, less insightful. The goal was to come up with the most complete app experience possible in the time allotted. Giving candidates more work than could be completed showed how they prioritized tasks and managed time/pressure.

My team agreed this approach gave us more insight into candidates than just doing some leetcode algo(s). What's weird is that this approach was hardly revolutionary. In fact, it's how most technical interviews were conducted years ago. Why companies became obsessed with algo solving as THE technical interview metric is a mystery to me.

Collapse
 
dezhango profile image
David Zhang

Hey! Thanks for reading and I appreciate the input here.

I can definitely relate to being frustrated with contrived interview formats. To be fair, algo interviews are a super quick way to screen out a lot of applicants which, in practical terms, makes sense for FAANG who get hundreds of thousands of people applying every day. But like you mentioned, it kind of went too far when other companies started following suit, eventually over-relying on these kinds of questions to gauge a candidate's technical skills.

The good news is that in recent times I've seen a lot of pushback against traditional "Leetcode" interviews. Virtually all the startups I interviewed with recently asked me relevant questions that were representative of the day to day work. And none of those ever felt like interrogations - they were collaborative experiences that tried to simulate working with a coworker as opposed to working with an audience.

Collapse
 
squidbe profile image
squidbe

That's encouraging!
Forgot to thank you for your well-written article 😊.

Collapse
 
sinisterchef profile image
Kyle O'Brien

Love your writing, both your articles are fun and funny.

Collapse
 
dezhango profile image
David Zhang

Thanks! Glad you enjoyed them.

Collapse
 
darshangaikwad profile image
Darshan Gaikwad

Excellent, it's very helpful.

Collapse
 
meshamakes profile image
Mesha

Ahh this is such a good read, I've been struggling with system design myself so I'd love to give this a shot !

Keep up the good work man :)

Collapse
 
klimd1389 profile image
Dmytro Klimenko

Thanks for sharing your experience. Your story is very inspiring, and I'm sure it will be helpful to other readers.

Collapse
 
deepak-mind profile image
Deepak kumar

Thank you for this post, great learning

Collapse
 
tankala profile image
Tankala Ashok

Loved the article man. The way you convinced readers that system design is important is amazing.

All the best to you & your product

Collapse
 
andylarkin677 profile image
Andy Larkin

so easy and clear to read! All the most important points are covered! Thank you

Collapse
 
0xsheff profile image
0xSheff • Edited

Your System Design Daily is awesome, thanks for that! It's exactly what I'm looking for

Some comments may only be visible to logged-in visitors. Sign in to view all comments.