Caching, load balancers, message brokers? Becoming an engineer requires more than just learning to code! As applications become more complex and deal with more data, system architectures or designs have become more complicated as well, and increasing numbers of Codesmith grads have reported that they are asked questions related to Systems Design in their engineering interviews.
SYSTEMS DESIGN IN THE ENGINEERING INTERVIEW
Unlike coding-related technical interview questions, which have very straightforward solutions with clear, consistent inputs and outputs, a Systems Design-related interview question may be as simple as: "Design Twitter" — it is up to the interviewee to think through most of the details before jumping into a solution. Two solutions could be vastly different, using different tools to solve the same problems, but still be acceptable and demonstrate the ability to think through the challenges related to designing an application.
Using Excalidraw to prepare for technical interviews
THE IMMERSIVE PROGRAM’S HIRING PORTION
Codesmith is known for its hiring outcomes, in part because the Codesmith team keeps a finger on the pulse of what it takes to not only be prepared to perform as a mid-level or senior-level engineer, but also to communicate that ability to others.
In response to the reports from alums, Codesmith has integrated Systems Design into its curriculum to prepare its residents for those conversations not just in interviews, but also on-the-job as engineers encountering these issues and technologies in the real world.
We also had the option to dig deeper into a systems design topic and deliver a Tech Talk on that topic — I chose to deliver a Tech Talk on caching, which is briefly described below. After preparing for my tech talk, I can’t think of a better way to learn about a topic than to prepare to publicly share what you know!
In addition to lectures and tech talks, we had several sessions in the hiring portion devoted to Systems Design. We had chances to work through design problems with other residents and fellows, and dig into the tradeoffs between design choices and the reasons to use specific technologies. Here are a few of the Systems Design concepts that we explored in these lectures and sessions.
At the very least, a basic full-stack application like the ones we've been building at Codesmith will have a client and a server. A client refers to the machine that requests data from the server and displays that data to the person who is using the application, and the server listens for those requests and provides the data when needed.
Many applications store data in one or more databases. This could be data related to user information, products, posts and comments, etc. Oftentimes when a client makes a request to a server for data, the server will need to request that data from the database first, which has a higher and more secure capacity for storage. This brings me to the topic of my tech talk...
A cache is another type of data store that can exist pretty much anywhere within an application. After data is initially requested and received from the database, it is stored in a cache for next time the client needs it. A common example of caching occurs in your browser: website content such as images or videos may be stored in your browser’s cache, so the same content on the website will load much more quickly the next time you visit. Caching comes into play when designers want to reduce the number of queries, or requests, to the database, which can increase application speed and reduce the amount of work the database has to do.
Applications have become pretty large and complex, and include lots of possibilities for user interaction. Consider a typical social media application: users can create an account, log in, post content, and interact with content through comments and reactions. Due to the scale and complexity of modern applications, multiple servers are often needed to handle client requests — this is where load balancing comes in. Load balancers add an additional layer of technology to a system dedicated to assigning each request to a server, so one server doesn’t get overloaded with requests that it can’t handle. Load balancers can be configured to divvy up requests in a number of ways, and designers will make decisions on how to do this based on their needs and hardware capabilities.
The last topic I’ll mention here is called redundancy, and refers to the need to duplicate hardware to avoid system failure. It’s important for most systems to remain highly available to their users — a system isn’t very reliable if it contains “single points of failure.” For example, imagine that an entire system depends on one server to handle all client requests. If that server crashes, the entire application will be unavailable to its users. Systems can avoid this problem by using multiple servers, databases, and other components so there are backups if a piece of hardware fails.
Systems design is a fascinating field to dive into, and I was barely able to scratch the surface in this post. Hopefully if you’re new to systems design, you’ve gained a bit more understanding of the problems and thought processes that go into designing complex applications. As more companies require this knowledge of their engineers, Codesmith has responded by giving its residents the tools to communicate their understanding of systems design throughout the hiring process.
Blog written by Jackie W, Codesmith Full-Time Remote Immersive Cohort 4.
--
Learn more about Codesmith's Hiring Portion and Graduate Outcomes in this blog post.