By Zhiyong Tan, author of Acing the System Design Interview

In this article, Zhiyong Tan explores aspects of his career development that led to success and planted the seeds for his book, which is available in the Manning Early Access Program now.

Read this if you want to learn tips, tricks, and experiences regarding high-level software engineering and system design interviews.

Take 25% off Acing the System Design Interview by entering fcctan into the discount code box at checkout at

When I graduated with a master’s in electrical engineering in 2013, I barely knew how to code. My experiences with writing more than 20 lines of code in a single file was scripting MATLAB to process some field measurements or draw simple 3D diagrams, or the C++ assignments of sophomore courses I took as a grad student in a semi-misguided effort to “learn coding fundamentals”. I had bought a copy of Gayle Laakmann McDowell’s 5th edition of Cracking the Coding Interview, learned Java to follow it (generics took me a while to understand), and had only just learned basic data structures in the past year.

I got a job as a data engineer in a startup, an accessible entry point for people without formal computer science education, and happily did my work writing Python scripts for machine learning. My curiosity drove me to interview for software engineer positions, which led to my first system design interviews in 2014 and 2015. I exited my first interviews with the understanding that they were not coding interviews. At one of them, I had even treated it like a data engineering interview. My interviewer asked for an application to access certain data. I drew database schemas on the whiteboard and explained an ETL (data) pipeline to obtain his desired data. My interviewer commented that he had never seen anyone approach the problem the way that I did. Apparently, it was his first experience interviewing a data engineer. I didn’t get an offer. It was also difficult for me to learn more about these system design interviews. Back then, I was in a small office with only a few engineers, and discussing interviews wasn’t a wise idea.

When I stepped into a system design interview in 2015 at a prominent tech company, I didn’t know that it would be the most significant event of my life that year. I answered the interviewer’s question in my usual fashion of drawing tables and pipelines, and he instructed me to draw boxes to represent services or data centers, and arrows between them to represent their communication. We spent the next 50 minutes discussing replication (copying data) between data centers, so someone on a smartphone or laptop can load data from a data center in the same country instead of on another continent, which would be much faster. He asked me if this would cause data inconsistency (different data on various data centers), about rerouting traffic to other data centers in case one was down to maintain service availability, and introduced me to many other basic system design interview concepts. Looking back, I believe that my interviewer knew from my resume and from our first few minutes together that I wasn’t ready for a software engineer role, and he decided to use that hour to introduce me to system design interviews.

That single hour with a good engineer was a life-changing event. Sometimes, all we need is to be pointed in the right direction. I started reading books on scalability, and I studied online articles and videos on various sample system design questions, such as designing Craigslist or Flickr. Along with continuing to practice coding interviews, this helped me to pass the software engineer interview at Uber in 2016, where I grew considerably for the next 4 years.

When I started interviewing again in early 2020, I noticed there were much more online resources available. The sheer amount of online content, diversity of topics, and the varying quality made quite an impression on me. I searched for system design interview books, and didn’t find any good ones. I did, however, find and study a few good books on scalability. On one such afternoon, I had finished watching another system design interview video while taking notes and screenshots. I scrolled through my notes, then stopped looking at my screen for a moment, and contemplated my learning journey. I remembered that interview in 2015. I remembered myself then and at other times, of the multiple periods in my life where I worked longer and harder than necessary because I walked an unorthodox path in my software engineering career, lacking formal education and mentorship whose value that I had since learned to appreciate so much more. I remembered my efforts, my naivety, and that interviewer who guided me. I thought of others walking the same path. If there was no good book for them, then I should write one from my notes. This moment became the seed of my book.

They may know “thou shalt guide me with thy counsel”.

-Psalm 73:24

What is a system design interview?

A system design interview is a conversation between 2 engineers. Given some vague requirements, these engineers will discuss and define more well-defined requirements, followed by engineering designs that an engineering team can implement. There are numerous questions and considerations. How do we divide this system into components, and at which stage in the system’s development does it make sense to spin off a component into an independent service? How can we isolate certain required complexity into components that will be useful to many different systems? Which components require more hardware resources than others, and how can we maximize performance and minimize costs by allocating specific hardware to components that need it most? What are the potential human factors to be considered in designing and implementing a given system? What other problems and constraints might we encounter?

This discussion is open-ended, but we can identify patterns in system design interviews. This helps us best display our abilities within the interview’s 50 minutes. A common theme is to design a scalable web service that lets users interact over the Internet, which can rapidly and cost-efficiently scale up or down to serve anywhere between a handful of users to billions of users.

Why system design?

Why is system design so important and relevant? We must ensure that the system that we are building serves its users well and effectively helps them achieve their purposes. Our systems also contain features for our company’s purposes, which may include revenue-generation features like billing, analytics features that educate us about user reception and give us insights on possible future directions, and much more. It takes considerable code, time, and effort to build a system and its features. As software engineers, we code every day, and our daily code output must move us closer to our goals as efficiently as possible. To do so, we must understand the system we are building in detail, so we know which platforms and other systems that we can use, which parts of our system we need to code on our own, and how to put them all together.

Taking a step further, as a junior engineer, you may understand your system in detail, but do not see many of the other systems that make up your company. CTOs or architects, on the other hand, make broad decisions that consume much of your company’s scare resources. As you ascend in seniority, you will soon reach a point where you do not have the time to understand all the details. A platform your company develops may have fifty thousand classes, and hundreds or thousands of engineers working on your company’s various systems, changing code much faster than you can read it, and at least dozens of group meetings may be going on simultaneously to discuss new or current projects. To make the best possible decisions that will have sweeping effects across your organization and perhaps even the world, you must understand the high-level details of your company’s various systems and ask the correct questions. This will help you to know where to focus your attention and your organization’s efforts, where you can afford to allocate resources for experimentation, and when and where you must change course and cut your losses.

A system design interview is a discussion or role play that involves such factors. Similar to real life, you will have limited time to understand and discuss the system. The interview discussion will be less than 50 minutes, too short to discuss the intricate details of complex business logic. You must keep the discussion at a high level, break down the problem into its elements, and demonstrate your technical depth by your ability to fluently zoom in to any particular element and discuss its details. Similar to an engineering lead, you may not know all the fine details, such as the algorithms. However, you do know how to ask the correct questions to ensure that your company’s engineering resources are optimally allocated, that the systems can cost-effectively and fulfill your users’ requirements and our company’s interests, that they are being developed in a manner that anticipates possible future requirements, anticipate possible directions that our application development can take, and consider possible future constraints such as resource limitations or legal and privacy requirements. You can conceptualize various approaches to designing a system, discuss their tradeoffs, and predict possible problems with any particular approach.

A system design discussion is also a common exercise in team collaboration, part of an engineer’s daily life. It is the professional duty of every engineer in the team to contribute to their team’s system design discussions. The discussions can happen via various channels, such as reviews and comments of engineering documents like RFCs, in chat rooms, or in meetings. Meetings most closely resemble system design interviews. These meetings may be to discuss new systems to be developed, solutions to problems in current systems, or new features requested by product or engineering managers. These meetings may be short or long but they are finite, and a common situation an engineer must face is asking relevant questions and raising relevant concerns and ideas without knowing all the details. The system design interview may also be an exercise to discuss the vision for the group or company and possible directions based on the current situation.

System design and your powers

As web services consist entirely of software running on widely-available data centers, they do not require any lengthy preparation to produce, and can be developed in a short period, ranging from days to months depending on the system complexity and your company’s resources. With a good product-market fit, one can attract a sizable fraction of the world’s population to use a product. A tech company that executes a product roadmap well can achieve vast economic (and even political) power. Tech companies have been heavily overrepresented in the list of top companies by market cap over the last decade, and even with the recent downturn in tech stocks in middle of 2022, at least 6 of these top 10 companies are still tech companies. Prominent tech companies like Alphabet, Amazon, Apple, Bytedance, Huawei, Meta, Tencent, Uber, and many more directly affect the lives of billions of people, and hence often receive attention from the media, politicians, and government officials. A tech company with competent engineers who design and implement good systems with architectures that are scalable, maintainable, and easy to extend can remain prominent for many years.

The financial rewards can be great. Senior software engineers are well-paid in most organizations, regardless of size, and there is high demand for them in both the public sector and private industry. This alone is a strong motivation for many people to strive to become senior software engineers in large companies. At the very least, learning system design will improve your position in an industry with good jobs and endless applications.

Just like that interviewer opened my eyes to a new world, I hope that this book may open a new universe of opportunities for those who read it. If knowledge is power, then gifting knowledge is gifting power. How you wield your new powers is up to you. Even if you join a large company, where you may feel like an insignificant cog, it’s good to remember that you still have power. Being proficient in system design gives you the ability to lead engineering teams to design and implement systems that impact more people than you ever thought possible. You can use your newfound system design expertise to design systems that provide payment processing to small businesses or crowdfund charitable causes. You can democratize creativity and entrepreneurship in a social media company, by allowing artists and entrepreneurs to reach a larger audience without the permission of large media companies or governments. Or perhaps you will choose to develop software for any one of countless applications, like high-speed trains, autonomous cars, oil and gas drilling rigs, or high-frequency trading systems in Wall Street. There is no end to the demand and possibilities for capable software engineers.

I wish you the best in your system design learning experience, and in making choices of what you do with your new abilities.

If you’re interested in learning more, you can find my book here.