The Situation
Back in December, I got the unfortunate news that I had just been laid off from my job. I’ll never forget that moment — I was on vacation at Disney World’s Animal Kingdom, sitting on the bleachers with my AirPods in, eating cold $12 Dinoland USA chicken strips. As I watched Goofy and Pocahontas wave to the audience from their party boat sailing across the lake, I grimly listened to our CEO talk about COBRA and equipment return policies.
Anyways, being freshly unemployed meant it was time to get back on the job-hunt saddle and start shotgunning my resume out into the ether. Since I’ve been lucky enough to have had steady employment for the past few years, my interview skills were pretty rusty to say the least.
But I had a plan. I would embark on an exhaustive, fine-tuned training regimen that would get me back to my glorious post-college interviewing prime. I daresay it’s the most comprehensive, sophisticated prep methodology ever devised by man or beast. I was unshakably confident that it was 100% scientifically guaranteed to land you any job at any company.
It went like this:
- Go to leetcode.com
- Do problem
Much to my surprise, this fool-proof process didn’t work as well as I thought. There was one key difference between me and the me of 5 years ago — 5 years. The jobs I was eligible for were no longer “New Grad” or “Entry-Level”. They were now “Mid-Level”, “Industry Hire”, or even “Senior”. And that meant Leetcode problems were no longer the main course. They were the appetizer.
Enter two new villains in the tech interview canon: System Design and Behavioral.
Behavioral interviews aren’t usually that stressful for me, since I’m generally a pretty passionate guy who loves to talk about things. Just ask my partner how many times I’ve kept her up until 3AM ranting about basketball. That being said, I’m not some master of behavioral interviews and there are plenty of ways I’ve f-ed these up (which I might cover in a different post)
System design, on the other hand, was a different beast entirely. It was an interview form I’d never seen before. My very first encounter with system design will forever be etched into my memory. In a cruel twist of fate and irony, I was asked to design a Leetcode-style coding interview platform. My answer went a little something like this:
ME: “Architecture? Sure, uhhh… I guess I’d have a client that talks to a server…And then I’d have that server talk to a database…”
Interviewer: “OK.”
ME: “…”
Interviewer: “…”
ME: “I am finished.”
Interviewer (thinking to himself): “You sure are, buddy”
And don’t even get me started on the incredible answers I’d give when they asked me questions about design details:
Interviewer: “So what happens if your database fails?”
ME: “….Two databases????”
Interviewer: “What’s the difference between SQL and NoSQL?”
ME: “One has SQL and the other one has no SQL.”
My interviewer, watching me draw my entire architecture diagram consisting of a box labelled “Client” that points to another box labelled “Server”
The Task
The task ahead of me was pretty simple. Boot up the ol’ terminal and git gud at system design. Like with any other software engineering problem, I figured Google Search was my best friend here. And so, after wiping my tears and deleting my rejection email from my inbox, I type “System Design interview guide” into the box and hit enter.
Immediately I am greeted with a flood of information. Atomicity! Consistency! Isolation! Durability! Consistency Again, but not the same as the previous Consistency! Availability! Partition-Tolerance! I find myself watching a 2 hour Harvard lecture from 2012 about load balancers and PHP. I watch countless Youtubers explain and re-explain how Twitter caches news feeds. I get recommended Designing Data-Intensive Applications (or “The Piggy Book”, as I like to call it), so I purchase a physical copy on Amazon and excitedly crack it open, expecting to gorge myself on the delicious knowledge within.
The "Piggy Book” about Computers and Stuff
I promptly fall asleep after reading 5 pages of the preface. Don’t get me wrong, it’s got lots of great info. I'd highly recommend those who like getting really in depth with scalable software systems go pick it up. But as a non-book reading doofus with a TikTok attention span, I really struggled to keep myself focused.
Me reading “Chapter 1: Reliable, Scalable, and Maintainable Applications” for the seventeenth time.
By the end of an 8 hour System Design bender, I find myself filled to the brim with knowledge, like Spongebob with Fine Dining and Breathing. That night, instead of ranting to my partner at 3AM about Steve Kerr’s rotations on the Warriors, I rant about LFU distributed cache eviction policies. (Just use LRU dammit!).
The next morning I wake up and it’s all gone.
The Action
Okay, it’s not all gone — that was, admittedly, for dramatic effect. But I did find myself suffering from chronic you-use-it-or-you-lose-it syndrome. Since I wasn’t actively using the system design information, I found the knowledge gradually slip away as I started doing other things. It was almost as if the information was being evicted from my mind-cache, replaced by more recently used keys like Baldur’s Gate 3 builds or Steve Kerr’s underutilization of Jonathan Kuminga on the Warriors.
Unlike with Leetcode, system design resources don’t give you a nice way to engage with the material. Which is a big problem for me, since I like to get hands on with stuff. Really get in there and get dirty with it.
My Github, where I remake the same Todo-list app every time a new JS framework is released
System design prep resources are entirely passive. It’s all reading articles and watching videos. You’re just soaking in information, like my dad at the local 24-Hour Fitness jacuzzi.
And furthermore, there’s no tangible feeling of progression, no feeling of pride and accomplishment after studying system design. (Believe me, I worked at EA so I know all about Pride and Accomplishment). For example, one of the best feelings you can ever experience is when you finally solve a Leetcode problem all by yourself. No Neetcode video explanation. No defeated scrolling through the Discuss tab. You excitedly run your code, pass all the test cases, smaaash that green submit button, wait for that little spinner and boom! It beats 0.2% of all solutions. It's terrible, but it's progress.
So being the do-er I am, I get an idea. Why don’t I just build it?
The Result
January 2nd, 2024 — I’m at my parent’s house watching some 34 minute Youtube video about the Punic Wars. I absentmindedly go to Github, thinking about better times when I programmed stuff and got paid for it.
I pull up an old hackathon project from sophomore year of college: https://github.com/david8zhang/nodepad, an interactive study tool that automatically converts your class lecture notes into daily quizzes. I marvel at how big a piece of crap it is and how bad I used to be at writing code. I also think about the major roadblock I hit during the hackathon. What I was trying to do required a powerful natural language understanding model that was far beyond the capabilities of a 2nd year CS student fueled only by free pizza and dreams.
I suddenly realize that a certain powerful natural language understanding model has just recently exploded into the public zeitgeist. Moreover, it’s extremely accessible — used by 2nd year middle school students, and it now threatened to devour software, art, and human interaction altogether.
Existential fear aside, I decided to dig nodepad out from the catacombs of my Github and reawaken it from its near-decade long slumber. Though the code was completely dead and unusable, its spirit could live again. The automatic quiz-generation concept could finally realize its true potential now that integrating sophisticated NLU is as easy 1–2-GPT-Three (ok, that sounded better in my head). This time, I set my sights on quiz-ifying the mountain of system design material that I had tried to cram into my tiny little noodle.
Fast forward a couple weeks and I’ve put together https://systemdesigndaily.com/, an interactive system design study guide that uses AI-generated daily quizzes to help keep those concepts “in working memory”, to extend the caching metaphor.
For now, it’s effectively just a glorified outline of all the notes I took during my weeklong system design binge. But being the gamer that I am, I’m planning to extend it with all kinds of fun mechanics, e.g. a rank progression system akin to competitive online games, daily rewards and badges, and maybe even a global leaderboard. I also have more features on the horizon, such as free-response tests and a “back-of-the-napkin scale estimation” practice tool.
I would love feedback for https://systemdesigndaily.com/, so if you have any, please feel free to DM me on Twitter / X: https://twitter.com/de_zhango. Please roast me if the topic article content is incorrect. After all, it’s entirely based on my own research and understanding of the concepts, and, if you haven’t figured it out already, I am a bozo.
Top comments (5)
This was a really fun read! Thanks for sharing it!
Side note: I started playing with your site a little and noticed a CSS bug -- the sticky progress footer blocks the quiz explanation on a laptop screen. I think you need to work through letting the content inside the quiz scroll, the pb-[90px] is just making extra space past the footer … Why is CSS always the hardest thing 😅
Glad you enjoyed the article, and thanks for checking out the site! Looking into that footer issue now 👀
And yeah agreed, CSS can be a pain
So you got a new job eventually or what?
sadly no, still on that grind
:(