FAANG Interview Reality Check - What They Actually Want

Transcript is auto-generated and may contain errors.

Hey folks, we're going to a submitted question. This one is about how to get ready for Fang interviews and specifically they add on do all roles and levels uh require elite code style coding. So we'll talk about this. Just a friendly reminder, if you want questions answered, leave them below in the comments or you can go to codeamed.com, submit questions anonymously just like this person did or of course just find Devleer on social media and send me a message. So, um, this is going to be an evolving topic, especially with AI. So, the stuff I'm about to tell you right now, um, keep in mind that you're going to want to do some additional research. If you're watching this video, depending on, um, you know, how how recent this video is by the time you watch it, things may have changed even more. But um with AI uh there are changes that are coming with how big tech companies are interviewing around the coding uh questions.

So um we'll kind of touch on that towards the end but generally speaking we have three major categories of interview questions for software engineers in big tech companies. Um there's a lot of similarity and overlap across different tech companies. Um just to give you an example even as an engineering manager I get similar types of questions. So context principal engineering manager at Microsoft um when I was interviewing for this role uh 5 and a half years ago it was very much like um you know software engineering interview except we put different weights on different categories of things. So usually how this works is that you have multiple rounds of interviews and interviewers generally will uh be divided up into some will have uh like coding questions, some will have system design questions and others will do behavioral interviews.

Now I have also seen where um sometimes interviewers are split up so that uh you know maybe everyone does a little bit of behavioral interviewing and everyone will also do uh some type of technical component whether that's a system design question or uh like a coding question. So the point is that you'll have multiple rounds of interviews almost always. I don't know an example where you don't and it will generally be broken up across a coding question or multiple coding questions, system design questions and behavioral questions. So these are the categories that we're going to be talking through um to start things off. Uh coding questions are generally speaking like a lead code style question. Um, if you've seen other videos of mine, uh, you'll know that when I talk about this, I get pretty frustrated by it because I don't think that lead code is, uh, a useful mechanism for gauging anything except that you practice lead code.

Uh, and if you like doing lead code, I think that's awesome. Like, you're welcome to enjoy anything you want to do. If you find that's a good challenge, it's fun, it's uh, helps you kind of like think on your toes or think creatively, great. like I don't want to discourage you from doing it. Uh and of course it is especially valuable when interviewing for big tech companies at this point unless AI shifts things away from this. Um it's like necessary for interviewing with big tech companies. I just personally as an interviewer and as an engineering manager for 13 years, I don't I don't see any value whatsoever in lead code uh for gauging candidates uh capabilities. So, you should absolutely practice lead code questions. Uh, I mean, the crux of this person's question is like, you know, do we need it? Yes. Um, 100%. I don't know a big tech company at this point in time that doesn't ask this type of question.

Um, again, just to give you some, I don't know, some comparisons. As an engineering manager, I interviewed at Microsoft, I had a lead code style question. Uh, at Google, I had a lead code style question. Uh at Facebook, I've had lead code style questions. Uh I had two as an engineering manager. Um and at Amazon, Amazon was the only big tech company I interviewed at as an engineering manager that did not. But that's as an engineering manager, right? So my point is that as an engineering manager who is not coding in my day-to-day role, they still ask me lead code questions at like almost every single big tech company that I interviewed at. So, you can bet your ass as a software engineer, they're going to ask it. Okay, the like I said, and I'm going to keep bringing it up, the only reason or way that's going to be changing is like if AI is going to throw a wrench into the mix more and more.

Okay, so I do recommend that you practice lead code style questions. Um, I would say even if you're like, man, like I crush programming. I'm very confident. Like if you're the kind of developer that feels like you can build anything, I think that's awesome. I still think that you're going to want to specifically practice lead code style questions. And I say that because again like it's a it's a different approach. I I don't feel like it's like building real software at all. Um there are word problems generally speaking uh you know especially when you get to the more mid and advanced questions there's usually like tricks to them for runtime. So you could naively go implement a solution and it will work. Um and the reality is there's usually some type of trick or optimization you can do um that's going to dramatically affect the runtime performance or like uh or memory characteristics.

And so depending on your level uh you know places will expect more or less of you when you answer these questions. So you should be prepared to explain the runtime characteristics the the memory implications right if uh if it's like oh just store you know a million copies of everything in memory and uh that way it's all fast it's like well is that is that the right trade-off here right like you need to more um I feel like as a more advanced interview they'll be absolutely expecting you to do this kind of thing But I don't know, it's uh just something like absolutely practice it. If you're not sure where to start, obviously lead code, the website itself, there's a neat code. Uh there are tons and tons and tons of content creators that like strictly and purely focus just on lead code style questions. Okay?

So, there is no shortage of this stuff. But I highly recommend that if you're like, I don't, you know, I haven't done elite code style question in a long time or I never have practice, right? Set up time like, you know, if you're getting ready for interview, set up time every day or multiple times a week and go through some questions. Um, yeah, I don't know what else to say on it. I I hope that someday they change this because I I think it's the dumbest thing. Um, I don't think it's ever been valuable and I think it's even less valuable now. Okay, next up, system design questions. Uh, these are generally speaking I find less trick questions, although I've definitely been in interviews where I feel like people are trying to trick me with it. Um, which is kind of silly. But, uh, this is the kind of thing where most big tech companies, you're talking about big distributed systems.

How do you scale them? Um, similar type of thing. You might be like, "Hey, I can build anything. I feel comfortable doing it." And I think that's good. I'm not trying to discredit you. But I think you still want to practice the approach for these types of things. There are again tons and tons of content creators that focus on uh this kind of thing. And there are websites uh you could go ask ChatGpt or your favorite LLM to to direct you towards those. I personally do not make content on lead code. I personally do not make content on system design questions. And the reason for that is that like um the the spa and I don't I don't mean this to like discredit anyone or talk ill of anyone. The space really bothers me.

Like it feels like I know people aren't trying to gatekeep, but if they make it seem like content always seems structured in a way like this is the only way to go build this system or like the only way you're going to get a job is doing lead code. And I'm like I just I hate all of that. Um but there are lots of great content creators that explain the components of systems and I think that that's really valuable. But usually with system design questions, um they'll you'll get something that's like we want to build um a system that's like food delivery like Uber. Okay? And they might give you a little bit more, but the entire idea with these questions is that instead of you diving in to go build things, they absolutely expect that you're clarifying functional and non-functional requirements. and then what's in and out of scope.

So, just a heads up if you start diving into and I know a lot of us are like this because we're as engineers, we're like, "Oh, like I'm ready to go solve this. I got to go build this thing." Um, don't don't jump into like building the system. You need to clarify the requirements up front. Okay? So, it is absolutely expected. Um, go through, spend some time. you're going to want to uh you'll see a lot of recommendations online how to how to talk about scale, right? If someone's like, "Okay, you're going to have uh you know, a million daily active users." Okay, well, are you talking about um the amount of traffic, right? I know I was saying an Uber system. Think about like a YouTube style system. Okay. million uh daily active users, how many of them are creating videos versus watching them, what kind of bandwidth do we need to think about, um storage constraints, uh like all these types of things.

So, there's lots of things online to kind of guide you through in these different scenarios how to think about estimating things. Now, I would say that a lot of the time you could probably, and I don't recommend this, but you can you'll probably end up memorizing some of this stuff because you'll see the same systems coming up over and over. My big recommendation to you is like I don't think memorizing is ever a great strategy for like actually getting better at things. I think understanding is the way you get better. So, if you're finding that like you're just recalling stuff because like, oh yeah, I just I just did this Uber question when I'm practicing and I know that I need to go ask these things, try to understand why, right? Like what parts of the system are you optimizing for and what questions are you trying to answer to do that?

So, you clarify these things up front and then that should give you an indication to the different major building blocks that you're going to want to consider and then you're going to want to talk about how these components integrate, right? So, you're going to need some type of storage somewhere. Okay, who can access this storage? Uh, how does it scale out? What does eventual consistency look like? Um, there's things like like acid. there are uh latency considerations. There's all these things that you're going to want to try and understand about the system you're building and then looking at the different components that you select uh and how you integrate them to optimize for those things. So again, I I recommend you practice these types of questions. I don't recommend that you rely on memorizing them. If you are a junior developer, you might be able to get away with that kind of stuff.

But think about it this way. Just imagine yourself in an interview and you've been trying to memorize these different systems, okay? And you get asked a question on what you've memorized and you're like, "Hell yeah, okay, like I can follow the script and I can go through and you start, you know, you start going through it. You're calling out the constraints. They're all on the same page as you. You talk about um the functional, nonfunctional requirements. You start building it out. Everything's good. And then they ask you a question about your system and they ask you to explain it and you actually have no idea what you just put down on paper or you know in the on the web page if you're drawing it out because you don't understand it. It's going to feel like really awkward. How did you just go build this entire system if you don't even know what any of it does, right?

So try not to just rely on memorizing things, please. Um, and that means it takes pra like time and practice. Go through these things. I seriously recommend if you're practicing system design questions, even for your lead code questions, if you end up getting stuck and you have to go look at the answer or get some guidance, if you're like, I don't know, I don't know why we'd need to put a Q here or like why we would need to um, you know, split up and shard user information this way. like this makes no sense to me. It just seems like it's overly complicated. If you don't get it and whatever you're looking at for a solution guide or whatever isn't explaining it, seriously, go to an LLM and ask it and ask it for pros and cons of different things and that way you can start analyzing and trying to make sense of it for yourself.

So yes, so far lead code style questions you can basically guarantee. system design questions. Uh very likely if you're more junior, you may have we talk about or I talked about the weight of these things very briefly in the beginning of this this talk. More junior people will get more coding style questions and then some system design. The more senior you get, I would say this kind of um you start to reduce a little bit of the hands-on coding and more system design questions. Uh and then that's going to lead us over to this last category which is behavioral. And behavioral itself can be broken down into some uh subcategories. Um which aren't uh super important to like try and dissect, but a lot of this uh your one of your best friends here will be the STAR method. I can't even remember what it stands for right now.

Um scenario something. Anyway, it's how you kind of it's how you talk through answering these questions and um scenario, task, action, result, something like that. Anyway, you can go ask Chad GPT or whatever you want to to explain it. And even if you're like, I know how to, you know, someone's like, tell me about a time when X, and you're like, oh, I have a you know, I have an example of that. If you're like, I don't know how to frame this like the STAR method, go type your answer or speak it to chat GBT, right? Tell it your story and then say like, how would you frame this like the STAR method for explaining it in an interview, right? So, if you don't know, you can use AI tools to help guide you and like restructure things so that you can start to see, oh, okay, I talk about this first, then this, then this.

You can see the flow. Okay, if you're like totally stuck on how to do it, my big recommendation with behavioral interview questions for software engineers is that they are behavioral interview questions. Behavioral. They are not tell me about the features you built and the technology. Yes, these are, you know, uh, points in your story or experience that you may touch on, but in behavioral interview questions, they're not focusing their attention on, oh, this guy picked uh, you know, my uh, my SQL over Postgress or oh, this guy uh, guy or girl picked uh, C++ instead of Rust like big dummy. Like, that's not the right answer. It's not it's not uh technical right it's not about your technical choices. Now you might have a scenario where someone says tell me about a time where um you know you were working with other engineers and you were suggesting a technical decision uh and they disagreed with you and how you navigated that.

that kind of behavioral interview question, even though it's like the scenario says something about a technical topic, the the focus of what your answer is is not technical. Right? Think about what I said. It's like you're you're uh in a situation where you have people that are disagreeing. How did you explain your perspective? How did you listen to other people's perspectives? How did you come to an agreement together and ultimately pick the best solution whether or not it was yours, right? Your solution, someone else's solution, a hybrid, right? Like how did you work with other people when you guys were stuck? It just so happens that it's on, you know, a scenario where they're saying for something technical. What they don't want you to do is, you know, start being like, "Well, Rust is clearly the best thing and here's a hundred reasons why Rust is better, right?" Like, that's that's not what they're asking because that's just missing the point.

Behavioral interview questions are about the behaviors and interactions you have with others. So, I encourage you when you're practicing these types of questions, and you could even ask, man, like seriously, again, I'm going to keep saying it. Go to your favorite LLM tool, say, you know, give me 10 behavioral interview questions, right? And just like try to look at what the goal of the question is. As an engineering manager, this sometimes I feel like maybe this is a little bit more obvious to me. um only because I do interviews. So if I'm asking a question, I'm like I know what I'm trying to get out of, you know, trying to observe from this person's answer. So I I encourage you to think about that, right? They're asking you questions not randomly. They're trying to assess different behaviors based on your lived experience. So, you need to be able to clearly communicate, okay, like I here's a scenario that I've lived through and like here's why this demonstrates whatever.

And they're trying to get you to explain how you operate based on a real example. Okay. So, couple recommendations here for big tech companies is like um a lot of them publish interview guides like here's our core values. Okay, I want to give you an example. Uh I can't remember exactly word for word what it is uh from meta but meta has um one of their you know core values is like a bias for action. Okay. And if you think about this from a software engineering perspective, you know, if if everyone's debating the best course of action for 6 months and uh we could have actually made a prototype in a week and tried things out and started getting closer to answers like we would prefer the bias for action over just sitting and waiting uh and debating endlessly. One of Meta's core competencies or core values is this bias for action.

And I remember I had an interview question as an engineering manager and the way that the interviewer asked me the question totally caught me off guard because it the way that the question came out again I can't remember word for word made made it seem like tell me about a time where you did something without thinking about it wasn't quite like that but that's how it felt to me and I was like why would I do something without thinking about it the question was really about tell me about a time where you you basically had to take an action without having a ton of time to go do all of the research and like blah blah blah. So like when I got caught off guard, I was sitting there going like, man, like why is this guy asking me this? And that's the first question you want to ask if you're like hearing the question, what is it that they're trying to gauge?

And you know what it was? It was a bias for action in this case. Like tell me about a time where you you had to have a bias for action. You had to go get something done because of uh you know criticality severity of something. You had to go do something. You had to take action versus just waiting. And then I was like okay I can think of examples for this. But the meta point here, no pun intended, being that um you can use some of the company's core values uh alongside like example interview questions and you can even ask your favorite LLM to say like hey I'm going to go interview at Amazon or Google or whatever based on their values like can you uh create some behavioral interview questions that I can practice. Okay. And then try to take the STAR method approach. These are three different categories of interview questions that I would recommend you practice for big tech.

Um, one more final note cuz I'm just getting home and I said I was going to talk about some AI stuff a little bit more. Uh, just uh to touch on it with a lot of the AI tools that we have even at the time I'm recording this and it's only going to be crazier and crazier going forward. Um, stuff like the coding interview uh is probably going to have to change. Um, thank God because I think it's like I said, stupid. Um, I think it has to change because some companies are like, "Oh, we want people to we actually do want to start leveraging AI in interviews, which is interesting, right?" Like, how do we get people to use and show their usage of these tools that um they're going to be using on the job? We expect engineers are going to be using AI tools.

So if you can use an AI tool to answer a coding question and if you think about what I was saying earlier, how many content creators and websites have all these lead code questions, LLMs can answer the lead code questions very trivially, right? They can recite them, whatever. It's not it's not rocket surgery for them. So if you do this in an interview and someone's like, I want you to, you know, uh, reverse a doubly linked list or a singly linked list or, you know, invert a binary tree or whatever. Um, giving it to an LLM, it's going to give you the answer very quickly. Um, so what benefit is there in asking that in an interview? This kind of stuff is going to have to change. I don't know if we know what that's going to look like.

I'm hoping it moves that part of the conversation to either show us how you use AI tools, which I think could be very interesting, andor maybe we move away from the show me how you like actually write the code to um maybe more of a collaborative exercise. And I I don't know, maybe both of those I don't know the right answer. I just know that it's going to change. It basically has to if they want to start including AI more into uh into interview loops for the tech part. And I'm I'm just hoping that it moves it closer towards like what it's actually like to work with people versus show me how much you memorized for leak code. So um I just want to leave you with that because if you're watching this in the future or even if you're interviewing at places and this is already changing um you know I I want you to be kind of aware of that.

So, hope that helps and I will see you in the next video.