When applying to a software engineering position at a senior or principal level, you can expect to go through a long process of interviews and tests. One step along the way is very often a system design workshop, or a Case Interview, where you will demonstrate your ability to work with real-world-scale systems. You will be asked to either design, or reason about, a software system that can handle real-world use cases and volumes.
Even if you have experience with developing large-scale systems, there are a few things about these interviews that make them really difficult. First of all, there are no standard answers. The questions you’ll get are open-ended, and there might be many different solutions to each single problem that would be valid answers. An experienced interviewer knows that a good applicant can deliver answers that are better than any formulaic “right answers”. Also, as the interview goes on, an earlier good answer might prove really bad, when new requirements are added. You need to stay on your toes and know when to revisit earlier decisions, change them, and identify how those changes can cause ripple effects, and affect the rest of what you’ve built.
The topic for a Case Interview often falls into one of three different categories:
- Famous Cases: The interviewers can ask how you would build a slightly simpler version of some well-known system like Twitter, Google Search, or Netflix.
- Flagship Product: The interviewers provide requirements, little by little, for something that slowly turns out to be what you’ll be working on if you get the job. This is where the interviewers want to see if you’ll come to the same conclusions as they already have, which is good because then you’d be a good culture fit, or if you have some new creative take, which is also good, because you would bring something new to the team. In my case, this is exactly what happened when I applied for my first principal engineering position.
- Problem Solving: The interviewers give you a description of a software system, and it’s up to you to identify one or many flaws, and suggest how to solve them.
In the next few blog posts, I will present a process that lets you approach case interviews with confidence. I will give you a few examples and show you how to apply each step to your benefit. Let me first describe the process briefly, so you know what to expect from the rest of the series:
Typically, the interviewers will start by presenting a case in a very broad way. It can be anything from one single sentence (“How would you build the Amazon Kindle Store?”) to a few minutes of background and requirements. Starting to build something right away is not the right answer; at this point, you are expected to ask the right questions. The interviewers will probably be intentionally vague about things, and it is up to you to get enough clarity before starting to build a solution. Remember, trying to get every single requirement defined up-front is not a good idea. Instead, use what you get, and be prepared to ask follow-up questions later as you move forward.
During this part, don’t forget to ask for non-functional requirements. Ask about the expected load, the size of data to store, the number of users to handle, and the expected performance of the system. The answers to these questions will guide your decisions as you go along. Do a rough calculation of required bandwidth, storage capacity and possibly also the yearly cost of running the system.
Start with drawing a very rough sketch of the system you intend to build. Lay out the bare minimum of parts needed to fulfil the functional requirements on the highest level. Think of things like data flowing into and out of the system, data and file storage, and front-end components.
Then start fleshing the sketch out by adding elements that solve the non-functional requirements. Add load-balancers, caches and elements of distributed systems as needed. Think about how data should be stored. Does the scenario include users searching for data? Is there a need for reporting or sending notifications? Is the system read-heavy or write-heavy? The answers to those questions will help you decide on which type of storage to use.
When the bird’s eye view is finished, start thinking about how to structure data, and what users and other systems can do with that data. Approach it as if you are designing a simple API. Identify the main operations from a user perspective, and from an integrations perspective. Write down 5-10 functions that your API should expose.
Designing the API should help you identify data entities, so the next step is to draw the structure of those entities. Define which entities exist, how they relate to each other, and how to identify them. Draw a simple database table diagram, or a UML diagram.
If the interviewers have given you continuous feedback, you already have an idea about which components to dive deeper into. Otherwise, pick out a couple of the elements you have already drawn, or ask the interviewers what parts of the system they are most interested in.
What you focus on now depends very much on the type of system you are being asked to build. Generally, you should discuss more advanced features and technologies. Every solution to a problem also comes with its own challenges, so it’s important that you are able to suggest different options, and show that you understand the tradeoffs.
This part is where the interviewers are looking for your actual experience with a wide range of technologies, and it will generally guide their decision about moving forward with you or not. In the Deep Dive segment of the rest of the series, I will take the opportunity to show you various technologies that you should know about when applying for a position on this level.
Every interview is different, and even though these techniques will help you stay focused, they are definitely not enough. You also need to show creativity, demonstrate deep technical knowledge, and to communicate clearly. So in addition to what I will show you in the rest of the series, you’ll need to work on your communication and presentation skills. Practice your handwriting. Work on rhetoric and posture. Think of your non-verbal communication. If you land a job on the senior or principal level, the case interview isn’t the only time you will stand in front of people to present or defend what you have built.