“How To Pass Your Systems Design Interview”: Sophie Novati, CEO & Founder at Formation (Video + Transcript)

Sophie Novati, the founder of Formation, discusses the importance of understanding system design in engineering interviews. She explains that system design interviews test high-level problem-solving skills and real-world engineering experience, and emphasizes the importance of asking questions to understand the limitations and scope of the problem, as well as identifying technical challenges.

Transcipt:

Sophie Novati: Thank you so much, Amanda, for that wonderful intro. Thanks for everyone else for also being here in today’s session with me. I’m super excited to be here with all of you today.

And before I start, just wanted to say that please do drop questions as you have them throughout this talk. I know we don’t have a ton of time, but I’ll try to leave at least a couple of minutes at the end. And if not, I will definitely try to follow up with written or Looms or something, follow up to answer any questions that people have. Please ask them.

I think we mostly went through the intro already, so I’ll say hi again. I’m Sophie. I am the founder of Formation. We help people land top-tier engineering roles. This is just a really important topic for me because I remember starting my career as a software engineer at Facebook as a new grad just thinking that engineering was about just solving weird algorithms all day and coding, essentially.

And I distinctly remember throughout my career from Facebook to Nextdoor progressing to a staff level engineer transitioning into the mindset from being just a coder to being an engineer, which is really about building products that are actually changing the world and solving real user problems. And I think that this shift was the single most important change in my mindset that helped me become a way better software engineer, but it also made me just enjoy my work so much more. And I think that system design, understanding how your entire system works and the information, how it’s all flowing through the system to go from user input all the way to user response is very much part of that picture of progressing in your career as a software engineer. So anyway, to add a little bit to my background as well, I was one of those people that was very, very involved in our interviewing processes.

I was one of those people that did hundreds of interviews and I was very involved in thinking about diversity and onboarding and all things just bringing in new, great engineers related. And prior to starting Formation, I mentored at a bunch of different training programs trying to figure out why there was such consistently a skill gap I was seeing as an interviewer on my teams. And so I really started Formation because I just love the space and really want to spend my life hoping to create an impact in there. So I’m super excited to get to do this talk today. So today’s agenda, wanted to just really introduce you to the system design interview format. And this is roughly going to be the agenda. Obviously, it’s only 20 minutes, so you’re not going to become an expert at this at all by the end of it, but hopefully it gives you a little bit of sense of direction where to go.

So I want to start with talking about why system design as an interview format even exists, and from the perspective of your interviewer, what are they looking for, what are they thinking about? And then we’ll go through and we have this thing called the engineering method at Formation. And I’ll roughly just break down some of the stages of a system design interview. Note that these aren’t just orderly, like you do this, then this, then it goes back and forth between steps, but you slowly transition your way through these steps. And I’ll walk through an example as well. And then finally, I’ll leave off with a little bit of how do you actually prepare for this, knowing why it’s being done and what it looks like. Okay, so let’s get started. So the first thing is why systems design? So I think most people are usually familiar with coding interviews, so I’ll make a couple analogies.

But coding interviews, it’s really about testing fairly practical day-to-day coding skills. Now, I know the problems are oversimplified, so they’re not actually real problems that you’re solving, but it is fairly practical in that it is testing a skill that you will be executing every day, which is coding or most days. And system design is very much not that. It’s almost the opposite. It is really testing for high level problem solving and it is less practical because you’re not going to be building anything during a system design interview. You’re just going to be talking about a system in theory. And so it’s very high level problem solving. It’s testing for a lot of real world engineering experience, which is very different from coding, and so it relies on a little bit more theoretical stuff. And sometimes the system design is also meant to test for specific tech stack experience.

And this is sometimes, not always. Usually for specialized senior roles, system design will be very, very important because they might be looking for an experienced engineer who has worked with finance software specifically or security or some amount of obscene level of scale. And so for this in general, this is why I think it’s actually quite important, especially as you progress into your career, to really look at the job descriptions of the roles that you’re applying for, especially at these big companies where there are many job descriptions for the same level and each one might have a different thing because the different team needs a different skill.

And even if the interview format, like schedule is the same, like coding, then system design, then hiring manager interview, whatever the schedule is, the system design might heavily be influenced in terms of what the person is looking for based on the role that they’re trying to fill. And so really, system design also is the big seniority differentiator. So with a coding interview, it’s actually quite hard to disambiguate between a senior versus a junior engineer, but system design is where it’s at. And really, I like to say that it is trying to get a sense of how battle-scarred you are and the scale of problems that you’re really used to worrying about.

Okay, so how are we doing? So that’s the why behind system design. So let’s progress into the actual interview format itself. So the first step of the system design interview is somewhat, I find the scariest, to be honest, because it is often the time when you have the least amount of information. So classic system design interview, it’s like, hey, design Coder Pad and it is just incredibly open-ended and that’s it, that’s the prompt. And then you’re let go. And there’s a moment of just uncertainty because you don’t even know what problem you’re solving yet, yet you’re solving it. And so this step is really about discovering the limitations of the prompt on your own. And as part of this, you have to discover what is in and out of scope to be solved in this interview. And this is much more important in a system design than even in a coding interview.

This is an important step there, too. But you really want to be asking all kinds of questions and make sure you’re thinking about the system both at the macro level. So how many users are you supporting overall, right? What’s the scale of the system as well as the micro level? So what does the end to end end-to-end user flow look like? And the challenging thing here is that you don’t have infinite time, and so you also want to make sure you’re strategically asking the right questions in a binary search format so that you can quickly hone in on what it is that you need to focus the rest of your time on in this interview. And so quickly, to give an example, let’s go use our Coder Pad example. So what are some questions that you might ask for this? You might first ask, well, what coding languages does it support?

So briefly, what do you think about this question? I think that this question could be better, especially if this is your first question. And the reason is that by asking this first, it is implying that I think this is one of the core challenges of this problem, right? It’s like setting a code pattern. What coding languages does it support? And it’s like, oh, is that the most important thing? And I would say that this at the highest level actually feels like more of an implementation detail even though it’s a huge project to support many languages. But when we’re first starting off and slowly starting to expand breadth or depth first search of the problem space, it just feels like an oddly specific thing to ask about.

So a better question might be, Hey, do we need to support real-time collaboration? This is a fantastic question because it is immediately getting to the heart of why this prompt might be extremely challenging. If the answer is yes, we know we’re going to be spending a lot of time thinking about the idea of supporting real-time collaboration. And a few other good questions here are do we need to support code compilation or is it just display only? Do we need to be able to run structured test cases? Some things, like I’ve seen some products where you can input test cases and then it runs and tells you if it’s correct or not.

And then last one is, do we need to protect against anyone writing some kind of malicious code? Quick note on this, I oftentimes see junior candidates shy away from this phase because I feel like they’re nervous or panicking that they won’t be able to solve the problem they’re asking about, so they almost want to ask about things they are more comfortable with. And I would really urge you not to do that. Even if you have no idea how to do something, identifying the problems themselves can sometimes be just as important as identifying the solutions. And in fact, sometimes it is not an expectation at all for you to know the solution, but simply to identify the problem. I’m doing short on time, so I’m going to skip a little bit of the explanation as to why. But really here, focus on identifying where your major technical challenges are going to be through your questions.

And from there, we do have to come up with some form of solutions, right? And an important thing to keep in mind here is that there is no right solution for any problem and especially, especially in the system design interview. So try to reduce your stress. This is a conversation, not just a test of getting the right answers all the time. It is not about that. In a great system design interview, in fact, you should be offering up solutions and immediately almost critiquing your solutions to break down where the problems are. And I think I see people not doing this because it’s almost like, oh, well, if I attack my own solution, then I am not defending it and making it seem like the right answer. And that is very counterintuitive, but the right way to think about it. For example, let’s say we’re thinking about how to do session replay on Coder Pad.

And so the first thing that you’re doing is you need to be able to show edit history. And so it means that instead of storing the whole text document, you also have to store every single change that the user has been making in order to play it back in session replay. And so the second you think of this solution, you’re like, well, what’s wrong with this solution? What would cause this to be a problem or create a scaling bottleneck? And just a really simple one to me is now we’re storing a ton more stuff. We have to store maybe in a database every single character change.

And then there’s a lot of follow-up questions immediately. It’s like, okay, well, how long do we need to store this for? How much time afterwards do we support session replay? Do we have to be as live as character by character? Things like that. And then the answers to those questions can then inform the solutions that you choose. So from there, you have identified some problems, created some solutions, critiqued those solutions, and this is also a very hard step. I see people not doing this, which is making recommendations. Again, I feel like people think that we need to produce correct answers, and I almost see people asking the interviewer, do we do this? Is that the right answer? And actually here, in coding interviews, I would say it’s somewhat just about the execution sometimes because you’re producing correct code, but in system design interviews, you are literally being tested for your judgment. You’re being tested on which choice that you make.

And so the more decisive you are able to be and the more you’re able to create rationale for why this is a good solution, you don’t even have to have the best solution. It’s possible that you have other ones, the better it is. And by the way, a lot of times you’re going to make recommendations and your interviewer might challenge those recommendations. They might say like, well, what about this? And that does not at all mean that you’re doing a bad job. If you’re able to respond to it, then all you’re doing is participating in a very healthy engineering conversation, which anytime you’re working on products as an engineer on a team, that’s what you’re doing. You’re constantly being like, what about this? Well, that has this problem. What about this then? Well, that has this problem. Well, how about let’s approach it a totally different way?

And that’s how you battle test the solution that you want to implement. Okay, I’m not doing good on time. Making recommendations. Final thing is verifying your solutions. This is also I find a skipped step. So you just get to the end of the interview and you are starting to just say like, oh, we’ve done all the parts. From here, I would recommend for you to take a user job to be done and really show it how each user request will flow end to end through your system. I forgot to mention, actually, earlier step one, when you’re asking questions, by the end of it, you should have as output a list of requirements, product requirements, system requirements for the system that you’re building. And when you have that requirement, that should be written up so you can see it in the interviewer can see it the whole time.

And if you’ve done that, then here in your verified solution step, you should have a fairly easy job and you basically just want to go through each of the requirements and verify that your system supports the thing that you decided was a requirement. Okay, I have two minutes. Okay, so how do we prepare? So I want to talk about things that I’m seeing people not do. So I already see a lot of people reading and consuming a lot of material that is very theoretical. And by the way, all of that is super needed. There’s a lot of great fantastic resources on system design out there that I highly recommend to people. So what I want to share to add on to what people are already doing is I have a very strong sense that the most important thing to develop here is real engineering experience.

And you don’t necessarily have to be the person experiencing it, so you don’t have to be on the teams doing it, but you can really accelerate your growth by reading, learning, hearing about other engineers solving problems and hearing about their battle scars. So things I’ve recommended, reading engineering blogs from other top companies, talk to other engineers, build a diverse network of engineers that you can speak to and ask them, what are you working on? What are some of the challenges of that? Are you guys using AWS technology as well? Why or why not? And this is I guess the long-term solution that I would like everyone to do more of. In the near term solution, I think that system design, you can only bridge small gaps in a short period of time. And so for that, my top recommendation is don’t just consume in theory. System design is an entire interview of talking.

And so practice talking about real solutions. Super specific recommendation is find a friend, an engineering friend, come up with a prompt that is something you are familiar with, like a problem you have solved yourself so that you know it pretty familiarly. And then have your friend do the same thing and then trade stories. Okay, so I see that Amanda is back here, which means that my time must be just about up. So I am putting up my LinkedIn. Please feel free to connect with me and I would love to answer any additional questions. I’m taking note of all of the questions that are here and I’ll be more than happy to send follow-ups on any questions that you guys have. I’m so sorry I didn’t plan my time better, but it was wonderful being here with everyone. Thank you so much for your time. And Amanda, I think that is…

Amanda Beaty: These questions may disappear for you when we end this, but we will collect them and send them to you if they do.

Sophie Novati: Yeah, okay. That would be fantastic. Let me try to take a quick screenshot. Here’s a couple of good ones, but yeah, if you could send them to me, that would be fantastic.

Amanda Beaty: All right. All right. Thanks, everybody. We are out time and we will see you in the next session.

Sophie Novati: Thanks, everyone.