FAANG Interview Tips - Principal Engineering Manager AMA

see if we're going here. I think the streams are streaming. That's a good start. Hey folks, I am sick, [laughter] unfortunately. Um, I'll try my best. Keep it together. Uh, just took some medicine so I can hopefully keep trucking [clears throat] along. But, uh, we'll see how it goes. I'm just getting Instagram launched. Substack. Um, Substack has still not fixed anything and I've submitted multiple support requests now. But hey, um, I guess support's not a priority. This stream is about Fang interview tips. Uh, this is a topic that came from Code Commute. Um, this question comes up quite a bit actually. So, uh, obviously people that are interested in working for bigger tech companies, this is applicable really for for many, um, software development jobs, but people are interested in like, okay, well, what does that process look like? So, I answered it on, um, on code commute and figured, hey, like, it'd be good to to do the the newsletter on this. And then, of course, uh, we'll do a live stream to chat through it. And that means if uh folks if you're new to the live stream, the live stream, let me get my chat up. There we go. Um live stream is all like it's the it's all meant to be interactive, right? So it's an AMA style. If you have anything that you want to ask, even if it's not really related to the topic, feel free to just jump in the chat and say whatever. Uh aside from advertising free views because I'll just block you from the chat. [laughter] With that said though, yeah, please jump into the chat and feel free too if you have some experience with this kind of stuff or perspective you want to share. Jump in the chat. I'll read it out. Um, you know, as long as people are being civil, I'm happy to kind of read out what's going on in the chat. And let me pull up my newsletter. So, I'll go through the topic. I'll share it in the in the chat as well. If you're on Substack, you already know where the newsletter is because you're on Substack. My goodness, this is taking its time. Uh oh, Jeremy's here. Hey, Jeremy. [laughter] Um my perspective. Yeah. So, yeah, Jeremy, you were at Microsoft in early 2024, right? I can't I can't remember. Is that when you um like you started there in 2024 or were you there um in 2024? Sorry, left in 2024. I can't recall because I know that um we've over overlapped there. So would love to hear your perspective especially if you have both sides if you did interviewing at Microsoft and obviously as someone who applied at Microsoft that would be super cool if you want to share uh any perspective on that obviously no pressure. So uh one sec I'm just getting this newsletter ready. Oh there we go. There's the first person I have to block from my chat. Um oh browser lockup. Yep. Totally understandable. I'm just putting the newsletter in the chat for folks that want to see it. Oh yeah, we're in 2026. What am I talking about? [laughter] Jeremy's saying that he's there for all of 2024 and early 2025. And in my head, I'm thinking like we just started in 2025. No. Um Nick, you're a little bit uh off there. Um thanks Jeremy. I do appreciate that. Devin says, "I think I did a dozen le code problems before I noped out." Um, and I'll share this. I mean, it's going to come up in the newsletter in this discussion, right? But, um, as an engineering manager, like I did lead code questions like to practice and for my interviews. Um, so a bit of a spoiler as we get into it, but um, I interviewed at Meta, uh, Microsoft, Google, Amazon as an engineering manager, like at the principal level. And um yeah, the uh the only company as an EM that I interviewed for that didn't ask me lead code style questions was Amazon. Amazon was almost I think I had five interviews and they were all like behavioral style. Um and personally as an engineering manager that seems the most applicable. I can totally get like system design to make sure that I'm talking about things that make sense for the the teams I'll be managing. But yeah, I feel like doing lead code style questions. I mean, as a developer, I don't even think that's a good idea personally, but as an EM, I'm like, this really doesn't track. Um, but Microsoft did it. Uh, Google did it. Meta did it. So, uh, it seems to be pretty standard. Um, spoiler alert, I'll talk about AI partway through this. Um, because I I'm really interested to see if people that are on the stream have started experiencing different things. So, uh, really looking forward to anyone's perspectives they want to share. Greatly appreciated cuz I'm curious and not only if there's other people on the live stream that can benefit from that, but these go up on YouTube. They're recorded. So, anyone that's watching it after can really benefit as well. So, folks, I did share the newsletter article in the chat. Uh, if you can't click the chat or depending where you are, it's just at weekly.devleader.ca. It's an email newsletter. No, you don't have to subscribe to it. treat it like a blog post. I was away this weekend, so it didn't go out on Saturday. I traveled out to Eastern Washington with my wife. Um, she was supposed to compete in a CrossFit competition. She was unable to. She had to withdraw because she was still uh recovering from a you know non-emergency surgery. Uh her one of her best friends was supposed to compete the morning of she was too sick. Uh and then uh her boyfriend ended up competing and doing very well. Uh I think he got fifth overall. Um and he only competed because they were going to compete. So um in the end we got home and last night was like, "Oh no, I'm feeling this sickness coming on." So now I'm sick and trying to power through it. Uh Angelina on Instagram, hello. Welcome. I know you just joined the stream. If you have any questions you want to ask about uh software engineering, career stuff in general, please do ask. Uh I realize that if you're on Instagram, you can't see the chat the same way. So, um, before I start going through the topic from the the newsletter, I'm just going to read out what Jeremy has here. So, for context, folks, Jeremy was saying in the chat that he was at Microsoft um, throughout all of 2024, left of uh, March of 2025. So, he said he went into the interviews with no expectations. He had a recruiter call that went well. So, that's awesome. then asked if I'd want to do an automated thing, three automated problems and I did them in Python the job was C# which is uh I think my experience at least has been there seems to be a lot of flexibility with the languages. Uh I interview that way like I don't care what you use. Um interviews I've been in people generally say like pick a language and then like stick to it so it's not totally pseudo code. Um so Jeremy did them in Python even though the job was C. Uh I said apparently did very well. So went to uh to a a threehour block with three interviewers. Wow. Okay. Uh one was another software engineer level 64ish. So uh for context at Microsoft levels are uh a little weird because you'll have sort of a a band or a title and then numeric levels. So 5960 is your junior software developer. uh 61 62 is your uh sui 2 and then uh 63 64 is your senior 65 plus is your principal level and then I don't know where it switches to to partner and distinguished and uh you know supreme wizard kind of thing but um that's somewhere over 66 at some point. So um Jeremy saying one was another like seniorish and had uh he had lead code type questions for him the other two one was an engineering manager the other one was some other title that he forgets. Um those calls went well talk mostly about projects I built. So I'd be curious Jeremy I'm still reading your your comments here but oh projects I built systems I was design and what went into those decisions my leadership experience. I think that's really cool. That actually echoes um one of my interviews from Microsoft specifically because that's what Jeremy's talking about. I had a um a system design question. Usually these are framed in a way that's like let's build an Uber clone or a YouTube clone or a clone of some system you probably use as a service. And um like Jeremy was saying here um I ended up talking about projects and for the system sort of focus I actually talked about different things I built and for me I came from desktop development so I had never built distributed systems in my life and I was literally going into a role for it. Um, and so I got to answer like stuff I built from desktop software, which is pretty cool that they, you know, it's not like, oh, too bad you don't have that experience. It was like, nope, let's talk about the designs and the trade-offs. Jeremy says, uh, then I had a call with the hiring manager and he and I just had a geek out. Really talked about the team challenges, first 90 days would look like, some of my questions, had a good chat. Honestly, I like obviously probably lots of people do. I really like interviews like this, not only as a candidate, but like as an engineering manager, I feel like the closer I am to having a real casual conversation with someone, obviously workrelated, but still like not like grilling someone on like, you know, recite all of these facts. The closer I am to that, the better gauge I feel like I'm getting from someone. So, I think that's pretty cool. And then Jeremy says, "You got an offer after that," which is awesome. Um, I'm just checking in on Instagram. Thank you very much, Jeremy. Um, so he says L64 core substrate team. For folks that don't know, uh, Microsoft 365, the platform that all of the services are built on top of, that's called Substrate at Microsoft. Um, so directory capacity, and I only left because I wasn't really feeling uh, babysitting backup processes. Yeah, I mean, that's totally fair, right? Um, substrate is uh, different from Azure. So that's the Microsoft 365 side of the world and Azure is a different part on Instagram. Angelina, thank you so much. You're a web developer and a graphic designer. Uh, and you do have a question. So I am reading the chat. If you want to jump in and ask your question, I am very happy to try and answer. Um, I'm just going to type it in there. Happy to answer, Angelina. Um, unfortunately the chat is not shared between Instagram and everything else. Um Baron Bites, welcome. Um what's a level 67? Uh level 67 is uh either partner or still principal. I think it's still principal. Uh it's definitely above senior. 65 is the first level of principal at Microsoft. 66 is still principal. I don't know what 67 is. I think it might still be principal because partner might be 68. All I know is that's above where I'm at right now. And I don't actually know what comes next except the number. But um it is not mid, it's not senior, it's uh principal or above. I just can't recall. Um that's hopefully in my future at some point. But um I guess I haven't thought about the title part that far ahead. So hopefully that helps. Again, thank you so much, Jeremy. I think that's really helpful to see like a real experience of someone going through this. Um so Angelina's question on um on Instagram, it's a bit of a tangent. I do want to answer because I think it's a good question and I appreciate that people are asking questions. That's the whole point of these live streams. So, um, Angelina is asking, well, she restated, I'm a web developer and a graphic designer. Can you tell me like how to reach uh clients? So, Angelina, I think, um, I think this is really about like how do you how do you get in contact with individuals that need your service? Right. In my opinion, like I would love to tell you um the best way to do this as an expert and I need to be very transparent. This is probably one of my absolute weakest skills and I think conceptually I understand how to do this. I don't think that I have personally put in put it into practice effectively. And I think a lot of that is because I have been able to rely on, you know, like a nineto-ive job. So nothing's really forced me into it. But um I think the way to go is probably a two-pronged approach or at least two prongs. One is like to build up um your web presence like have your own website, make sure that you have a portfolio built up showcasing things that are awesome. Um the so that's kind of like a passive thing, right? You can put all that stuff online and if no one knows about you or knows to to go there or you haven't optimized like SEO and you're driving traffic organically to your site, um, no one will see it, right? This is the same case for anyone who's on this stream or watching the recording. You could literally have the best idea in the world and make a website and then if basically if search engines or you know LLMs aren't doing some type of indexing to drive traffic to your site and people aren't navigating to it, they'll just never see your services or your product. So I do think it's important to do that. Um but I would also say that if you just did that and sat back like you might feel kind of disappointed because you'd be like man I did all this work. Where are the where are the users? Where are the customers? So, I would say do that part for sure because as you start doing things to drive traffic to your site, then people can go, "Oh crap, like this seems like really awesome stuff. This this person seems like they'd be a great fit for building the things I'm interested in." So, I would probably do a combination of a couple things. One is posting on social media so that other people sort of in the space, you kind of get uh it's a it's still organic. It's like organic so uh social, so you can share out uh information, things that you're doing, and people can go, "Oh, that's a really cool example. I want to see more of this." Um, and then the other side of this is like the part that I'm personally like not great at is like reaching out to people. So, you see, especially if you have like local businesses, you know, go out like literally go around uh look at businesses, uh, check out their website, and you'll probably see a lot of local businesses either don't have a website or it's bad, right? I've seen there's videos online of people making websites for for local businesses and they go, "Hey, I built this for you if you're interested in it." Like basically, you can pay me and we'll make it a real thing. Um, but I would um look into more of like cold outreach and and contacting people. That is a whole skill set on its own. But I would do this combination of like build your portfolio up so you have a good landing page and things where people can see what you're up to. Post on social, share all the awesome stuff you're doing, right? More eyes, more impressions. It's helpful. And then third is then actually reach out to people. You could start with local businesses. You could reach out to people on LinkedIn, Twitter, and say, "Hey, like I notice you have this. Are you interested in uh website design?" So hopefully that helps. Angelina and I wish you success. Um, okay. Uh, I have a question on LinkedIn for system design. I always get confused what depth I should cover. Yes. Okay. Um, what are the general expectations from someone uh with two to three years of experience? Uh, Jeremy's chiming in here too. I'm just kind of skipping ahead. Um, whatever your experience is, I always try to extract info from the questions. Things that weren't disclosed. Yep. Assumptions. I'd otherwise hold to clear them up. then paint in broad strokes and I'll have feedback to direct into detail. Absolutely. I think this is really really solid advice from Jeremy. Um so let's let's kind of back up a little bit. Um in terms of like if people are interested in the newsletter content, it kind of covers the three major categories and yeah like I'm generalizing but I think most uh big tech interviews kind of slot into this um kind of thing. So you will have something like a coding question generally lead code style, right? So yeah, that's one category. Next is system design. So that's what's being asked about in the chat right now. So we'll go into that more detail. And then the third category is really around like behavioral interviews, um, projects, but stuff that's actually non-technical and focuses on like how you operate as a as an engineer or whatever the role is that you're doing. So Jeremy calls out that um it's really important for system design questions to actually get clarification in the beginning. This is um like if you're very new to like big tech style interviews or even um it doesn't have to just be big tech because I think this is a relatively common pattern. If you're getting asked a system design question, usually the flow of that kind of thing will be like kind of said at the beginning of the stream or a little bit earlier. Hey, you have um the system we want to build. It might be an Uber clone. It might be like build a social media feed. Could be we're going to build uh YouTube. We're like something that you're probably familiar with using. Or it could be like we're going to have um I don't know uh a service that's going to allow users to buy concert tickets, right? Like something that's probably kind of familiar in terms of what you've used, but they're they'll give you a very high level. And I think a lot of people as software developers like we have this mindset where we love solving problems, right? So what's the very first thing as someone's explaining this scenario to you? Immediately we go like okay like I know I'm going to need a database. I know I'm going to need like a web server and like probably need to have um you know some type of gateway and then we got to think about load balancing and like you immediately jump into like all of these pieces you want to put together and I get it and like it's very common because I think a lot of us think this way but I think that one of the things that's very tricky unless you practice this or you've been exposed to it or you've kind of seen the patterns is that as Jeremy said in the chat you really need to spend the first bit of time talking about functional requirements, non-functional requirements. You need to figure out what's in scope and what's out of scope. And most interviewers, like again, we're generalizing here, but most will actually expect that you do this. And part of that is also going to be doing estimations of things. So if they're like, "Hey, we're gonna I'm just making something up. we're going to have, you know, a a million daily active users and we're doing a, you know, a social media feed. So, like, okay, if you have million daily active users and we're talking primar like is this read heavy or is it right heavy? If you think about a social media feed, uh, or like a social media site, you're pro like generally you're probably consuming more from social media. Like for the average person, right, probably looks at more posts than they are submitting. uh depends on the person I guess but on average so you'd be expected to like talk about like what are your latency requirements availability um the scale when it comes to scale like okay how many users do we have like what's the average size of media are there upper and lower limits that we should talk about so there's like a lot of this like um a lot of this kind of thing that we need to focus on in the beginning okay and that's to really help clarify what system we're actually going to build because if someone was like look man there's 10 daily users and like it's actually just a prototype they're probably not going to do this in a system design interview but like if it's really just a small scale thing where availability is not really that important like whatever latency is not that important like you would change a lot of what you're building like you're not going to go to microservices and whatever else but that's probably not going to happen so there'd be something to talk about the constraints And then from there, as Jeremy was saying, once you have that clarified up front, then you can start to like get the feedback on that and walk through the different pieces that you want to start introducing into your system. So, um, okay, you need to be able to scale out because you needed to handle some type of, um, you know, uh, amount of daily users. um you need to have uh the way your data is stored. You need to make sure that there's uh redundancy, right? So like how are we going to do that? How do we make sure that um how does eventual consistency work? How did we uh if latency is super critical? How did we make sure that we're reducing that as much as possible? Maybe with caching, where does the cache live? Like what does that look like? So, it's crazy because there are so many different pieces that you can start to dive into and explain. And so, um I I feel like these types of questions can be I don't know, like if you're like me, like I I find them overwhelming almost because there's probably like a a million different things I want to focus on. And that's why it's really important as you're going clarifying, right? like, hey, okay, I would, you know, I would use a Q here because I need I'm trying to like optimize for this constraint. Here's how that would work. And um and then kind of pausing to make sure you can get feedback on it. Because if the interviewer is already like, hey, like um too much detail when you're talking to me about the table schema. Okay, great. Like move on from that. Sometimes they'll stop you and they'll say, great. I I understand that you're talking about storing stuff in the SQL database here. um how might you like like what do these records and the schema start to look like right like how would you like what do the tables look like for storing this and why right so um all of these are an opportunity to pause and kind of get that feedback see if the interviewer wants to steer the question um like I said for for myself and I'm sure this is the case for other people it can feel overwhelming because you're like no one's going to sit in 30 minutes to 60 minutes and literally go build Facebook or Uber or YouTube. Like it's silly, right? You can't even recite all of the pieces in the real system that fast, let alone try to elaborate on them. So, like you need to be able to break it down into smaller parts and talk about it. So, um definitely get that feedback as you're going through. Um hopefully that helps on on those types of questions. Um uh Baron I do see your your question around uh and sorry there's actually one before uh for internships um just related to sort of the system design stuff Brax is saying I just want to jump to that question how do architect interviews work is it just all system design um so this is a good question because the answer is probably not but um with roles and levels how much you focus on what parts of these things will probably uh change. So it's like the amount or the weight of them will change. So Bra, I don't know when you joined the stream at the beginning of the stream I was mentioning that even as an engineering manager I was asked like lead code style questions, system design questions and then behavioral interview questions. As an EM usually the coding questions are very light. Um so I might have five rounds of interviews. One of them is coding. Um, and maybe if I don't like pass that with flying colors or like, okay, at least this guy, you know, wasn't, you know, Nick's not a total idiot, but like he could have done better, so it's not like I'm going to totally fail the interview overall. Um, or maybe they said Nick did so bad he's clearly never coded a line of code in his life. Like, this guy's out. Fun fact, uh, almost every single interview, uh, where I I don't get an offer, it's literally because they were like, "We don't think you're technical enough." And I'm like, I don't know what to tell you, man. [laughter] I code like all day uh outside of work, so I just don't know what to tell you. Um I think I interview pretty badly when it comes to lead code and even system design. I get flustered, but Rex, to your point, um you'll likely still get, you know, at least one question around like um you know, coding, some type of lead code style thing. most likely um the especially for an architect, you might see more uh something more complex or something more involved. Uh you'll likely have a majority of your um focus on system design. And then I would really hope behavioral interviews. I don't think if you're getting interviewed and there's nothing behavioral, I don't I don't know what's happening in that interview, but feels off to me. So, there's going to be something like that. Um it's really important especially when you have you know a more senior role an architect role like you need to be able to work with others like other stakeholders. So, it's critical that as you're doing this kind of stuff, like you should be getting um like tested in your interview to make sure that you are a good candidate for that because if you're like, I can build anything and like no one likes to work with me and I'm terrible and I don't do well with feedback and I can't work with others because uh you know, I'm always butting heads with people and any feedback I've ever had in my life is basically we hate working with you. um you're probably not going to be a good candidate. Exaggerating a little bit, right? So, like I I think that it's really important to try and make sure that people interviewing spend time on this kind of stuff. Um Bra says, "Yeah, I'm trying to navigate switching to AI cloud architect, but I guess I should keep up the leos." I think it's important. Um I don't know uh Bracks um depending on your recruiter scenario or what else um you might be able to reach out to someone and say like hey can you walk me through like the interview format I'm trying to prepare. Um if you if you're not even at that point yet I would I would highly recommend like um spend time on lead code style stuff. One of the general pieces of advice from this newsletter article in particular is like think about these three categories of rounding yourself out. Okay, so for example, as an engineering manager, the behavioral style questions, this is like quite literally what I do every single day all day. I still practice them and I still practice them because I need to make sure that I don't ramble. I need to make sure that my stories are coherent. But if someone, you know, on the spot was like, "Can you tell me about a time you had to help an employee solve a conflict?" Or, "Can you tell me about a time where you had to, you know, manage someone's performance and they were successful in that or they weren't and you had to do something about it." I have examples of like that kind of stuff I can I can conjure up quickly, but I don't want to catch myself like you would see on these live streams where I'm I ramble a lot and I probably double or triple explain myself. I want to be a lot more prepared. Also, I mentioned I code all the time. I'm very confident like building software. I love to code. I think it's super fun, but I'm terrible at le code. I'm absolutely abysmal at it. It's because I don't do it. So, when I'm interviewing, I need to go make sure I spend a ton of time, even as an engineering manager, like brushing up on lead code. So, I personally um just want to recommend that out of those three categories, think about like where your strengths are and focus your efforts where your weaknesses are and then try to make sure that you're still covered across the board. Um, cool. Okay, I'm going to Yeah. Yeah. And then Jeremy is saying, I don't worry about lead code problems. I just practice the basics. trees, heaps, graph reversal algorithms. Um, don't worry about the specific leak code problems. Most of the time suboptimal solution is fine. It's expected your code uh be correct uh first. This is very true. Um, and for me, not disagreeing with Jeremy here on this advice in general. I think for me, the reason I practice the lead code specific problems is because they fluster me. So, um, it's more like to get started on the problem, I need to see a bunch of examples and just force myself into the mindset of getting going. And then I think once I do that, I feel more comfortable because as Jeremy is saying, like if you if you know the basics, like if you have those things, if you understand trees, heaps, graph reversal, algorithms, you're probably going to be pretty good. Um, I get caught up on really simple stuff and it's because I think I'm I'm mostly panicking and I don't really have a good reason to. It's just like this has always happened with exams and tests and that kind of stuff. So, I just I need to get more time doing it and then it helps me out personally. So, I think it's still very very good advice from Jeremy and I would recommend that for others as well. Um because I do agree if I if I were testing someone on a coding problem, I actually don't ask lead code style questions. I ask pretty simple like data structures and algorithms questions like hey let's go build like something like a tree or a heap or whatever. And it's really like I scale it up in terms of um how senior or junior you are um based on like okay if we change this requirement like how would your design change right like uh link list doubly link list like um all sorts of stuff but really just changing design constraints and um and not actually like some lead code questions are like kind of like tricks whereas Jeremy saying, "Yes, you'll go solve it. It's sub-optimal time." And I've I've been in interview panels where people be like, "Ah, no, we're going to pass on that developer because they didn't find like, you know, the trick that makes it like, you know, uh, constant runtime." And I'm like, I feel like that's the worst reason to like [laughter] to not hire someone because I couldn't find a trick. Um, so I'm very personally very sour about that kind of stuff, but that's my bias. Okay, going back up in the chat. to get an internship at Microsoft. What could be the level of DSA and other skill uh that matter like how to communicate with interviewer? I mean what to communicate with the interviewer? Um for internships and stuff like that, you'll probably um I've actually never been on the interview panels for interns, so I don't know what the process is like. Um I have been an intern. I've had interns. I've interviewed interns at uh startups. I have not interviewed interns at Microsoft. So I need to clarify that. Uh my expectation would be that as an intern for Microsoft, you're probably getting you know a couple of coding questions like these lead code style questions to walk through. Um I would say it's rarer that you will have expectations around like complicated system design and that's because as a junior developer you probably have not built systems like that. So does that mean that no we'll just ignore it? No. like we should have a conversation about that. But I could imagine if it was five interviews, and I don't know or think it is five interviews for interns to be honest. I just don't know. Um, if you had five, I'm going to make this up. If you had five, I might expect that you have like two coding questions, one system design, and two behavioral. Uh, I don't think you get that for an intern. And then the weight of those would be like mostly on the coding, very little on the system design, and then uh definitely some on the behavioral. But the behavioral part's even interesting because like it's hard to gauge that when you don't have a lot of experience. I might expect three interviews maybe if that and it would be like a coding, maybe a system design and behavioral. I could see that being collapsed into one or two where it's like a coding and behavioral. um those are probably the things I would focus on um to be honest, but I think all three are very relevant. So I think the best thing to do on that is there's uh for Microsoft specifically, there's got to be guides online for u internship interviews at Microsoft. Uh I realize I work there, but I I've not conducted the interviews. You could even ask co-pilot chatgpt and say like, "Hey, I'm planning to interview for Microsoft. what is the the typical format? Um, you know, search the internet for for this kind of information. Um, you'll see these three categories of things come up just perhaps in a different capacity or amount of weight placed on it. I need water because my voice is going. Um, Baron Bite says, "I have a behavioral web dev interview tomorrow." Perfect timing. Um, maybe share your two favorite behavioral questions you ask to determine candidate fit. Yeah, I don't know if I have two favorites. Um, I I like asking questions around um giving and receiving feedback. I like that. Um, but that can also be either replaced or augmented with like um working with others. And I'm being very very generic about this, but I like asking questions where it's like, tell me about a time when you were, you know, um, designing something or working on a project and, you know, someone else had a different opinion about the direction forward. And like basically I like hearing about how people have to resolve conflict of some capacity. And this depends and varies on their level, but the reality is I really really like seeing how people work together in a team. If someone's sitting there telling me like I push for my idea no matter what and I don't listen to people, okay, that's a sign. If someone's like, hey, you know, the someone else said something different, we'll just go with their stuff. You know, no questions asked. That's not really good either. So, how do they approach navigating those things? I like seeing that they're listening to other people, they're taking that perspective into account. Uh depending on the situation, do they need to escalate? Did they need a third party opinion? Um how do they react when they're talking through a scenario? If they went with someone else's choice, um was it like all their choice? Was it a hybrid? How did they react to that? Were they like, "Okay, fine. We'll take this person's approach and then it backfired the next week, so haha." Like I felt like I'll show you. You get all sorts of interesting things as people are talking through this kind of stuff, but I really like understanding how people collaborate with others. That's one. Um, time permitted in interviews. I really like asking about people's favorite projects. And usually at this point, it's because I've asked a lot of other clarifying things where I'm I have a rough idea of like how they look at projects, how they deal with feedback, manage up, um, conflict resolution, that kind of stuff. Um, I like talking about people's favorite projects because this is an opportunity where someone can talk to me about what they're really interested in and it's kind of like it's less of a like a a test to be like, "Oh, this person's going to pass or fail kind of thing." But, um, this is really good insight for me to figure out like when I say, "What's your favorite project?" and people like light up and they start talking about something. um I can ask a few more questions to figure out like this person's really really interested in X Y or Z that's the kind of stuff they're passionate about and like if that's kind of lined up with the role then in my mind I'm like at least this feels like it should be a good fit for them because just to make up an example if someone was like hey like the types of things I like solving are you know I have to go research it for you know for six months and like if it's you know if there's any hand so that it's been solved before, like I'm not going to be interested. If I'm like, "Okay, well, we're building CRUD apps," then like they might not be engaged. So, I really like making sure I can kind of have that as a takeaway, too. It's less of a test, though. Um, project related things I really like seeing. So, okay, like, and again, depends on people's seniority, but if you're more senior, okay, you're leading a project, cool. It starts to fall fall behind schedule. like talk to me about a time where that was happening or a failed project, right? Um I try to be careful with people when I ask about failures or things that seem kind of vulnerable. Um I always disclose what people look like. I don't ask trick questions. I'm not trying to set you up so that when you answer something I'm like, "Aha, I caught you." Like you told me that you failed and like that was the trick. You're not supposed to fail at anything. No. like I if you're comfortable talking to me about a time that a project didn't go as planned, like I want to hear about what you learned from that. So, um I like hearing about that kind of stuff because then I can see how people navigate different types of problems and then again lessons learned from that. So, um just to reiterate, I always tell people basically at the start of interviews, if I'm asking coding questions, I say there's no tricks. Same with my behavioral and system questions. Like, I don't put tricks in my questions. If you feel like you don't understand or perhaps I'm trying to trick you, please just ask for clarification because it's the last thing I want is someone to be like, I don't know what I'm supposed to say here. Like I don't want to test someone that way. It's not helpful. Um yeah, Jeremy saying at big tech companies, people do talk about their experiences interviewing at each of the big companies. So you can find them if you look. Yeah, absolutely. and sort of like that's why I really appreciate Jeremy jumping in. Um, you know, just to give you an example, I don't think Jeremy's experience when he was talking about his interviews is like totally different or something and unheard of, but you might read other things where you're like, "Hey, that seems like it was a pretty different experience." Try to find more, right? Try to read about this and see what's common and stands out. Every interview is going to be different. Unfortunately, there's like, you know, there's a lot of consistency, but there's also going to be times where you're like, that's a weird situation. How did that happen? You're getting like one person's perspective on it at a time. So, keep that in mind. Uh, Manassa, with the times changing with AI, do you think the way big tech companies are interviewing is going to change? Aha. So, um, this is touched on a little bit in the newsletter, uh, for folks on LinkedIn. I didn't publish it on LinkedIn yet, but it's at weekly.devleer.ca. Um I am realizing the time there's about 20 minutes left in the stream. So I will invite others to um if you have experience more recently with interviews changing because of AI if you're on the side of the interviewer or the interviewe please do feel free to share. Would love to hear from people in the chat. Um do I think that the way that companies interview is going to change? Um my answer is yes. I do think they will. I think we're starting to see some of it. Um I'm very hopeful we'll start to move away from like how we're gauging elite code style questions kind of thing. Um I'm personally hoping and I don't know how it's going to work. I I think the behavioral style interviews um I hope that we keep that portion because that's really like tell me what you're like to work as like to work with as a person. I don't think that we can replace that with AI, right? Like I I think I personally want to understand if I'm going to work with this person, what is that going to be like? Do they seem accountable? Do they seem like they want to learn? like are they eager to do this kind of stuff, right? Are they like I'm trying to focus on that and AI is like a tool you can use in your tool belt, but I don't think that fundamentally changes like your approach to to those types of things with system design with lead code style questions. I do think the landscape for uh interview questions will change. Uh I don't know all which companies are doing that right now. I'm pretty sure Meta has announced they're starting to do that or they're triing it. So in my mind, the reason like I I always say like I'm not a big fan of lead code style questions is like I don't feel like that's very applicable to translating into general software engineering. People have all sorts of arguments for like for or against this, right? I've heard some people say like it doesn't actually matter. Um, it just so happens that it's a good proxy for like good candidates. And like I don't know, I've never actually seen data on that. But that also to me seems like a kind of a bull crap answer. Like I don't care if it's a good proxy. Like I feel like we should be able to find something better. Um, like it's like we gave up and just stopped at le code or something. Um, but yeah, the biggest reason I don't like it is because it doesn't seem to me like it translates directly to the type of work that we often do as software developers. It's very um contrived, right? To be clear, I'm not saying that um I'm not saying there is nothing to be gained from those types of things. I just don't think it's the best translation to what we do. So, um, what I really like is things that are a closer proxy to what we are doing, which is why I do like behavioral style questions a lot, right? And then system design questions I also think are good. But I think based on the interviews I've been in where I'm getting system design questions, I sometimes still feel like I'm being tricked. Like it doesn't feel good. It feels like someone's trying to set me up and like I don't like that because that's also not how we build software. It's almost like I'm withholding a little bit of information from you and I'm hoping you get it and it's like if you know that I didn't ask that in the real world we would be talking about that like it's uh it's just very um there's still contrived parts but I do like system design better than like a lead code style question. So I like things that are closer representations and I think that if we are expecting more and more people to be leveraging AI in the workplace then I would absolutely hope that we expect to see some of that coming up in the interviews right I don't know when I don't know um I don't know exactly what this looks like but if there's an expectation it's like um programming languages at the beginning of the stream we were talking about like Jeremy was sharing his interview experience and said he programmed in Python in his interview, but the role is for C. Cool. Um, we use co-pilot predominantly, but you're going to solve this, you know, problem uh with uh whatever AI agent you want. And maybe we ask, you know, how do you approach like refactoring some code or how do you approach, you know, building out a feature? How do you approach building up a a spec to go build, you know, have an agent go build something out for you? And I wonder if the interviews are going to change more to like how do you apply these tools that you have to going to solve software engineering problems. Um, I don't know. Like I I think I'm kind of curious to see what that's going to be like personally. I just don't know. I don't know how people are going to gauge that. like what what does success look like there? How do you score someone? Um I'm not really sure, but I I'm I'm thinking things will move more in that direction. Uh so I'm very eager to see if this kind of stuff evolves. And for folks that are on the stream now, like please, you know, in the future, if uh if you're applying for something and you see this kind of stuff happening, like reach out, let me know. I'm I'm genuinely interested in seeing what it starts to look and shape like. Um, Alex Harris, can it uh can it be difficult to get external opinions if you want to hear what someone outside of your team thinks on an idea? Um, I might be misunderstanding, Alex. So, can it be difficult to get external opinions if want to hear what someone outside your team thinks of an idea? Can you um Alex, I want to try to answer this question uh properly for you. Can you elaborate or maybe um change how you've asked this a little bit for to be more specific? So, do you mean uh external from the team or external from the company? Um, and here what someone outside of your team thinks of an idea and for idea in this context, do you mean for like a code review for a design or can you just maybe be a little bit more specific for what you're hoping to have answered and I will try my best to to give it a shot. Um, Devin says, "Okay, uh, thanks for being here Devon. Appreciate you. Uh, we assume that A will be used uh for a take-home project and they do a follow-up meeting for them to walk us through the code and explain it, discuss decisions and trade-off. We pair with them. Um, oh, I wonder Devin, is there a message missing or maybe I missed the specific context because YouTube has a big delay, but we assume that AI will be used for our take-home project and do follow-up meeting for them to walk through. Um, oh, I see. Sorry, I'm misunderstanding it. So, you as the interviewers, you have a take-home project. You assume AI is going to be used, but then you do a follow-up meeting for them to walk through the code and explain it. I like that. I know some people are super against take-home. They're like, "Hey, it's just a company trying to get me to work. Like, they should pay me or I'm not going to do that." Dude, I would personally much rather do a take-home. Let me show you what I got because like doing, you know, some random thing in 30 to 60 minutes, you're not going to get the best of me. You give me a problem and set me free. Oh boy. Oh boy. Like that's where I'm that's for me how I'm going to shine. So I'm pretty biased. Like I would love that kind of thing because if I really give a crap, I'm going to let you know. Um Deon says, "Then we pair with them for an extra requirement." Nice. Okay. So they're expecting some AIS used. they're going to like um come back and kind of see like how this person walks or then they're going to pair up and go through stuff together and they can use AI at that point, but they still need to understand or show that they understand what's being generated. I mean, that's great. That to me sounds like it is probably quite involved. No, you're all good, Devon. Thank you. I I had to do a double take on the on it, but I I I think I get it. Um it sounds very involved and I can imagine that some people would be like no that's too much work but like I don't know man like interviewing is really important [laughter] like you know doing a good job giving people the opportunity because I think that's the part that's missing too is that you know you can say we're going to interview people we're going to set the bar high and like I get it but if you're not giving people a good opportunity to like show you how they genuinely will be to work with what point is the bar? So, I I like that process a lot. I totally get why some people would be like, "Nope, too much work, too much time. Um, you know, I don't have time to do that. I'm already taking time off work to interview. You screw that kind of thing." But I would like that. Um, Deon says, "I still don't uh quite know how to deal with someone reading AI answers off their screen." Yeah. Um, this is the thing like I don't know the right way to like air quotes police that but um it's tricky because like depending on how people are doing it in what context it's almost like at what point are you thinking [laughter] because if it's just like I know that someone's asked me a question I'm just going to ask it to AI like what do we need you for right like if you're just repeating my question to AI to go answer it like I don't actually need you. Um so I would like some thought and some understanding and some analysis put in using AI I'm totally like hey that's great like use it but if you're not proving to me that you have any idea what's going on then like I don't have any confidence in your ability. So, um, Deon says, "The usage is involved." Yeah, we might work with this uh with this person for years. Yeah, we owe it to ourselves and then Yeah, I think that's a great point. We owe it to ourselves and to them to give them our full attention. 100% agreed and I get it. It's tricky because depending on the size of a company and the teams and stuff, don't get me wrong, I know that it can be very involved to interview. I can remember being at a startup, you know, being one of the hiring managers interviewing for interns for full-time people. You know, we scaled from, I think I was like employee seven or so to like 250. Like there's a lot of scaling over eight years. And um it's it's hard because it's a lot of time interviewing. But for folks that have not been part of like that sort of that loop or that life cycle of bringing people into a team, it is it is so impactful in a bad way to get a bad person brought on. like it can absolutely devastate a team and then it's a lot of wasted time and money and you know people's uh well-being potentially. So I personally think that it's better to go slow and just do a good job. People might disagree with that, but um if you're if you're going the opposite way, actually in both cases, I would say like you have to be ready to like unfortunately to fire fast. Like if someone's very bad, you you have to do something about it quickly. It's just that I would hope that you change your hiring process to not be in a position where you're like, "Oh, we made a mistake again." Like if you keep making the same bad bad hiring mistakes, like maybe your hiring is busted. Um, yeah, I agree with what you were saying in the comments there, Devon. If somebody is properly synthesizing what they're reading, putting in their own words, probably understand the answer and just needed a reminder. Yeah. And like I would do this even with a Google search, right? Like it's okay. So I think that that totally checks out for me. Um, Alex has an updated um question here. Okay, so some clarification external from the team but inside the company. So here's an example. For instance, if the team wanted more thoughts on the direction or design path they were considering or if they were having trouble deciding on which area to go with. Sure. Okay. So your Alex your question is like okay I'm in a company maybe it's a big tech company for example and um the team is trying to decide on something and they're maybe at a crossroads right um this can look all sorts of different ways. Um if the team has enough confidence and context uh to make that decision within the team they would probably just do so. So they would probably come together maybe on a design dock or something else and they would go through the pros and cons of the different approaches and that could be you know two three four multiple approaches writing down like if we go this path what are the pros what are the cons right um it's a really interesting conversation because when you actually discuss these things um you will realize that not everyone places the same weight on the things. So, for example, you might have four options to pick from, right? And everyone has agreed on the exact same pros and cons for all four options, and you have different people that are voting for each one. How can that be the case? It's the same sets of pros and cons, right? But how people weigh those things could look different. So, it's a really good opportunity to be like, hey, like if we go with option A, yes, that's giving us, you know, X, Y, and Z. I get it. um but we don't value X, Y, and Z as much as A, B, and C over here. So like do can we talk about that? So you can kind of see where like your disagreements come up. A lot of the time this kind of thing can be um can and is sorted out within a team. There are definitely scenarios where people have um you know, say a partner team where someone's like, "Hey, I actually know this other team over here. You know, they worked on something like this last month, last year, blah blah blah." So, what might be good is if we're kind of at a crossroads or you're coming up with this design right now, it might be a really good idea to go talk with so and so from that team because instead of you trying to come up with it from scratch, go get some ideas from them. My nose is falling apart. Sorry. Um uh and that way you're going to build things not necessarily from scratch, right? You might end up coming up with a design where you're like, "Look, I see what they did and it's just not applicable here." You might say, "I see what they did. This part's very applicable. This other part's not." Maybe what they have is like a direct drop in for the thing you need. So, I do think that it's a really good thing to keep in mind. Uh especially if you're at bigger and bigger companies, the odds that you are coming up with something for the very first time is pretty low. great example of this. Um, just to exaggerate it, right? It's no surprise Microsoft does a lot of work with AI. We have co-pilot. It's a big thing we push, of course. Um, you can imagine even if you don't know what's happening at Microsoft internally, just from seeing things online, if you wanted to go build some type of, you know, product or service with AI, the most common integration we see is chat. you want to put chat into something. Okay, so one of the most common things that we see get built at Microsoft, I don't have stats on this, this is just my anecdote, is that we will see people build chat into something or build a chatbot. Okay, so if you are trying to build something like this, how much of that is repeat that someone else has already done? If so, why are you doing that learning as well? If that's just because in isolation you're trying to learn and grow and understand. Okay. But at some point that starts having very diminishing returns for developers of a company. So like I'm trying to say like exaggerating with Microsoft because it's so huge and we have such a big focus on AI. If you had every single person try to go say I'm going to go build a chatbot. Probably not super helpful, right? we probably don't need like hundreds of thousands of chatbots. So, um or at least going through the learning curve and like the design of doing it. So, like there are absolutely opportunities to go learn from how other people are doing this. Um it's one of the the circles of impact we have at Microsoft just for you know people might not know the the terms and the phrasing. Um thanks Devin. I appreciate you being here. Um, one of the circles of impact we have is building on the work of others. So that means like there is literally one of our core things that we care about is not just building everything from scratch. So Alex, I hope that helps answer. I think one of the trickiest parts is like the discoverability of this kind of thing, but I think there's certainly opportunities to go talk with different teams about what you're building, getting their perspective. Um, in Microsoft 365, we have architectural reviews. So, you get people from very different teams that are literally coming together to participate in an architecture review that that you've put together, someone else on your team has put together to talk about this stuff. like literally to force that to happen which is really cool. Um I have found sitting in those conversations some of the most like it's super interesting because you can talk about it within your team and you're like okay we all you might have disagreements in your team but like we get there and like okay we got it and then you go to these architectural reviews and you're like how did we not think of that? like that is such such an interesting entirely different perspective to bring in. Um so there's a lot of value in in that kind of cross-pollination. So thanks for the question Alex. I hope that helps. Um [snorts] I'm just going back in the chat. Uh Simony from Twitch says find code like interviews are meant to filter people of a certain age. I mean asking someone who did 25 years experience how to code is an insult in and of itself. Yeah, it does feel that way. It's like unfortunately more of a standard process and to me it just doesn't fit very well. But I don't I I don't think anyone's going to change my mind about lead code unless we change what we're doing with it. But uh it doesn't feel very good. Um Jeremy says, "Architectural reviews are stressful." Yeah, you don't know how people are going to talk to you. Yeah, it may be questions you've never heard before, etc. Yeah, and this just two-part on that, right? So, like Jeremy says, you don't know how people are going to talk to you. The next part he says is uh maybe questions you've never heard. But I like thinking about this two separate ways because as Jeremy's saying, it may be questions you've never heard. So, you're like, I haven't had to think about the answer to this. And I would say a lot of the time in those conversations, people aren't there to like be like, aha, I caught you. Like, you're a dummy. Um, but it's like, hey, if you don't know the answer, great. like [laughter] you should probably follow up on that so that you can have it answered. But the other thing that Jeremy's saying is you don't know how people are going to talk to you. And this is super important. Um a lot of content I try to talk about on social media, YouTube, whatever it happens to be is like is soft skills, communication. [snorts] And when you're working in a team, you might you might work with people and you're like, "Yeah, I know this person's a little bit rough around the edges, but like I know how to work with them." and you get by, that's okay. There might be some people like where you're like, "Ah, it's not my favorite experience because they're rough around the edges, but I know that about them. I know they're well-intentioned. I have to kind of think about that when I work with them." And you do. You make progress. You're a team. It's good. It can be really difficult when you're put into a setting and you have people that have a lot of experience, right? They're very technical and you don't have a good working relationship with them. Not to say it's bad, but you have not built up the working relationship with them. You could have someone that's very to the point, right? I've worked with PE, this is going to sound ridiculous. Some of you might know what I mean by this. I have worked with people, they talk in complete full sentences, [snorts] proper punctuation, periods at the end. And when you read it, sometimes you go, "Is this person mad?" Like, we read in a lot to the communication. So, you might be working with people that just communicate in different ways and you're not used to it simply because you don't work with them. So, you can be very caught off guard in these types of meetings where someone could be totally awesome. They're coming across in a way that you don't really know and they're asking you a question you don't have the answer to and you're like, "Oh, like this is the worst." and people are watching me and I don't know what to say and now I feel stupid like it's no one's intention but my point of saying this is like practicing working with other people is it's huge like soft skills are a very important part um yeah and Jeremy saying that that's the feeling you get uh oh never heard of that better research this just to gut check myself 100% so again the intention in those forums is not to make people feel stupid and be like aha I found something that you never would have thought of and you must be dumb. It's like, hey, this is something that I think is important. I don't see it called out here. I'm not saying that you didn't look at it, but I don't see it called out here. Could we talk about this? And if you don't have the answer, it's probably good to follow up on. Okay, time check. It is 8:00 p.m. my time. So, I'm going to sign off here. Um, wanted to say thanks to folks to quickly go through a couple things. I will do the the old screen sharing. So, this is my newsletter. I I'm really bad with thumbnails for those of you that um somehow don't know. Um yeah, I'm very bad at them. So, this is a nice chat GPT one, but this is the newsletter. I'm just going to put a link to the chat. Again, like I said, this is on Substack. It's an email newsletter. Um you don't have to sign up for the email. While I absolutely understand that getting more stuff in your inbox maybe is a pain in the butt. Totally cool. Supposed to go out every Saturday. Um this weekend I was traveling and I'm sick if it's not obvious. So um was a little delayed. Apologies for that. But you can see um you know this this topic is about fang interviews. Um this came from a topic on code commute. So, if you have not seen my channel, Code Commute, it is a vlog channel. Let's go back to talking here. Um, it's a vlog channel and I basically take questions that you want answered. I take them anonymously in comments to videos and stuff like that and I make vlog entries so that I can give you a video response to the topic. Um, it is out of all the social media that I create, my favorite because it's the closest to like real conversations. It's basically like this, but there's no interactive chat. So, um, if you're interested in having questions answered and you don't want to wait till the next live stream, you can go to codeccommute.com. There is a contact form there. You can go submit something anonymously. You can message me on any platform you want, leave a comment on a video, whatever you'd like to do, and I'm happy to go make a video. Try my best. Um, my main channel on YouTube is called Dev Leader. that is primarily AI and C programming. Uh especially with so much focus on AI now, it makes a lot of sense for me to show you how I'm using tools to build things, but I build stuff in C primarily. So most of my tutorials are using C. Um and then I will talk about Brandos very briefly. So Brand Ghost is what I build on the side. I'm not even going to push courses, right? Let me pull up Brand Ghost. Um, and I'm especially excited today because um, on for Brand Ghost, we actually uh partnered with Monty Mater and she's a influencer. She's uh, awesome. She is very multiaceted. So, she talks about all sorts of different things. Um, but we partnered up so that we can work with her and her team to help uh, with her social media consistency and publishing and that sort of thing. So, uh, we announced that today. Um, all of us on the Brand Ghost team are super super excited about that. Um, and if you're not familiar, Brand Ghost is the platform that I build for posting content to social media. Yes, I know. Uh, especially with AI. Everyone's like, "Hey, I can go build a social media scheduleuler." Yes, you absolutely can. Um, there's lots of people that build tools that are also like violating terms of service and stuff. So, we just make sure that with whatever we're building, it's um absolutely in line with the terms of services or platforms. And the whole goal is really to help people be consistent with their social media. So, we can help you cross post, schedule, reuse content, get past your writer's block, that kind of stuff. Um but yeah, I use that for all of my social media. So if you're interacting with me on LinkedIn, Twitter, Tik Tok, YouTube, Instagram, Facebook, wherever, uh it's posted through um through brand ghost. The exception Substack, it's because Substack doesn't have an API. I've been trying. They haven't been listening. They haven't fixed my [clears throat] live stream tech support issue still. It's why for everyone else, I'm talking down the side of my screen for you on Substack. I'm talking to you. Um but I have to stream from my phone again. So, Substack's really disappointing me, but I would love if they gave us an API. Uh, but yeah, that's brand ghost. That's what I work on outside of work. And, um, it's a nice kind of synergy for me creating content and then building a platform on the side as well. So, with all that said, thank you so much for being here. I do the live streams every Monday, 700 p.m. Pacific. So, same time next week. Would love to see you there. In the meantime, if you are looking for similar types of content, code.com has vlog style entries on topics like we talked about today. Love to see you there. Or check out my tutorials on Dev Leader. So, see you next week. Have an awesome one. Don't work too hard. Make sure you have some fun along the way. See you.