The 5 Reasons Why System Design Interview Questions are Hard and What to Do About It
In recent years, System Design Interviews have become an integral part of the hiring process for almost all tech companies. They are particularly popular and notoriously difficult at top tech companies like Google, Amazon, Microsoft, Facebook, and Netflix, and for a good reason.
Those companies operate some of the world's most complex and successful software systems. They are constantly pushing the boundaries of fields like Distributed Systems, Cloud Computing infrastructure, and Software Architecture to improve the end user’s experience while keeping operating costs to the minimum. Those companies want to ensure that the engineers they hire can continue making solid design and architecture decisions to keep their competitive edge, which is what System Design interviews are all about.
However, most software engineers struggle with System Design Interviews, which remains a big obstacle in their career progression and the ability to land their dream job. So in the article, we will understand why System Design Interviews are so hard for even the most experienced software developers and, most importantly, what to do about it.
Scope
A typical task for a junior, mid-level, or even senior engineer generally has a very narrow and well-defined scope.
Examples include:
Adding a feature that does X
Fixing a bug to produce X result instead of Y
Implementing a method, class, or API that produces an expected, easily testable result or outcome
However, the scope of a typical System Design interview question ranges from one of a Principle Software Engineer to a CTO/ Software Architect of a company.
And while 1-2 engineers can easily implement most tasks we generally work on, the scope of a System Design interview question requires 10-1000 engineers to implement across multiple months or even years.
So how do you handle tasks in a scope that you’ve never handled before and doesn’t even fit in your head?
The answer to this is “abstraction”.
An experienced Software Architect doesn’t deal with implementation details, methods, classes, or even modules. And it’s not because they are not technical or don’t like coding. They developed the muscle to think and reason about system design problems on a much higher level of abstraction, where code, libraries, or even programming languages are too insignificant and even distracting.
So to be successful at a System Design Interview, you need to start thinking of big problems on a much higher level of abstraction.
2. Ambiguity
In a typical daily task of a software developer, ambiguity is minimal. Sometimes we are not sure how to use a method of a library or how to implement an algorithm optimally. But we can always find the answer on StackOverflow or in the documentation of that library. And when we don’t find the answer, we can simply prototype and discover the answer ourselves.
However, when we move to a higher level of abstraction and design a large system that potentially may not have been designed by anyone before, we don’t have that luxury. No documentation comes with designing the next Uber or TikTok. And no StackOverflow thread exists for solving a system design problem that has never been solved before.
Additionally, the scope of architecting a large-scale system doesn’t allow us to mindlessly prototype and see what works best because even prototyping is a large endeavor.
To make things even more challenging, in some cases, the client or product managers initiating a system design don’t have all the answers upfront, so the Software Architect's job is to ask those questions and reduce the ambiguity.
That is why System Design Interview questions are sometimes deliberately ambiguous, to test if a candidate can handle and find their way through the unknowns. Since most software engineers are not used to this level of ambiguity, they often find themselves lost and disoriented during such interviews.
So what to do about it?
Acknowledge the inherent ambiguity of a System Design question.
Ask intelligent questions that reduce ambiguity to the minimum.
Make common sense assumptions about what ambiguity is left after narrowing down the scope of the problem.
Architect the system in a way that leaves room to back away from those assumptions with minimal changes to the Software Architecture of the system.
Following those principles will lead you to a successful outcome of a System Design Interview because, by the end of an interview, the interviewer will be confident that you will make good design choices in architecting a real-life system, despite its ambiguity.
Needless to say, you should also follow those principles when you design a real system.
3. There is No One Right Answer
As software developers, we are always looking for the right answer. That is how we were wired in school when we learned algorithms and data structures, for instance, we always look for the best and most optimal solution. When using a library in our application, there’s usually only one right method that we need to call for each task. Otherwise, the API is considered bad and confusing.
System Design is all about Trade-offs.
Trade-offs in system design can be hard because they often involve balancing multiple competing factors. For example, a system may need to be designed to be both cost-effective and performant. These two factors may conflict, as increasing performance often comes at a higher cost. Additionally, the trade-offs can be hard to evaluate, as it may be hard to predict future use cases and scalability requirements.
An inexperienced engineer may panic and think, “oh, there are two possible options; I don’t know which one is correct. I must be wrong”.
But that’s actually OK. You are not expected to develop an optimal solution at a System Design Interview!
Instead, you must demonstrate that you can identify where such trade-offs need to be made. Weigh in the pros and cons for each. And use your judgment, based on assumptions or data the interview gives you, to make that trade-off and move on.
4. Communication
Let’s face it. Software Engineering attracts a disproportionally high number of introverts. Even extroverts like myself sometimes find it liberating to spend the entire day coding. However, System Design Interviews require a high level of communication skills.
The entire interview is actually one long discussion. The ability to discuss the problem with your interviewer, gather the requirements, explain your solution, and the thought process is sometimes even more important than the solution itself.
However, if you ask too many questions, then that is a red flag that may indicate you are incompetent.
If you talk too much and don’t ask any questions. That is also a red flag because that indicates that if you were given a real project to design, you would just run and implement it without clarifying that you are doing the right thing.
So the key is to find a balance.
Make it a two-way conversation that you drive most of the time, but allow your interviewer to take the reins when necessary.
5. Lack of Experience & Software Architecture Skills
In computer science programs at most colleges and universities, there is a big focus on what many refer to as low-level design and core computer science/programming fundamentals.
Data structures & algorithms
Programming languages
Object Oriented Design
Networking and Computer Architecture
Those are all important skills, rightfully emphasized by the education system and entry-level interviews.
However, the longer you work as a software engineer, the more you’re expected to naturally become proficient in “high-level design” and Software Architecture. So when you come to a System Design Interview or even just a typical job interview for a senior-level position, you are expected to demonstrate such skills.
But the reality is most developers don’t get to design such systems in their daily jobs. And even if you’re lucky to work at a company that runs large-scale, globally distributed systems, learning how they work on your own is not easy.
So you may have a resume working on a large-scale system, but in practice, you cannot design one on your own.
If this resonates with you, you’re not alone.
Most software developers don’t get to design the next Google or Facebook at their work. And it may take years before your manager assigns you a task that scratches the surface of that kind of scope.
So what to do about it? Be proactive.
If you are determined to accelerate your career growth, you must fill in your knowledge/skillset gaps without relying on your company/manager to hand it to you. And learning how to design such systems in practice, not only for an upcoming System Design Interview but for your own professional career progression, is super important.
That is why I created the Software Architecture & Design of Large Scale Systems course.
In this self-paced and easy-to-follow online course, you will learn the fundamentals of designing and architecting large-scale systems, which are critical for any System Design Interview.
Unlike many other System Design resources, this course is not focused on teaching you buzzwords to throw at your interviewer or memorizing names of technologies that will become irrelevant in 1-2 years.
Instead, this course will teach the fundamental skills of:
Designing a large-scale, real-life system.
Making correct system design choices and tradeoffs, and.
Following industry-proven best practices.
By the end of the course, you will have the skills and confidence to handle any System Design Interview question and real, practical software architecture skills you can use in your next project.
