[00:09] we're finally live here uh and sorry about that apparently you have to hit go live on three separate screens in order for this to actually work so um Welcome to our our very first Q&A for hello interview for you guys who don't know
[00:23] Preparing People for software engineering interviews and we're posting a lot of stuff on this channel in particular we have deep Dives on core Technologies and things that you need to know system design walkthroughs
[00:38] interviews q&as and more so if you like stuff like this uh please subscribe um figure let's give you guys some intros real quick just so you know who you're you're hearing from and and then we'll dive into some of the questions so I'm
[00:52] Stefan been working in tech for about 15 years now my longest stins were at Amazon and at meta faceb where I was a senior manager for Applied ml teams uh I've conducted almost 2,000 interviews at this stage I've hired a few hundred
[01:08] people uh so I'm very familiar with the hiring processes of of uh companies big and small I'm also one of the co-founders of hello interview so really happy to be talking with you today Evan you mind giv us giving us a quick intro
[01:21] yeah of course everybody excited to be chatting with you today I'm Evan I'm the other co-founder of hello interview most recently I was a staff engineer at meta I was there for five years conducted many hundreds of interviews uh love to
[01:34] my face if you've been following the channel as with Stephen so excited to answer those questions today awesome thanks Evan and just for General context on hello interview our mission is really just to help people
[01:48] get prepared for Tech interviews if you go in and see the site we've got a lot of free content available system design breakdowns AI tools we also provide mock interview services where you can connect with real live Fang interviewers to get
[02:03] hopefully nail that interview we've literally had hundreds of people uh get jobs at this stage uh with some help from us and a lot of hard work U really proud of of that and you know we'd love to have you check it out just some quick
[02:18] going to be taking questions both from the comments in the chat uh as well as any questions that were pre-submitted to us so if you've got a question please go ahead and and kick it over and the chat we'd love to address it uh note that we
[02:32] we're going to favor those questions that are more General and more interesting for the entire audience so if you've got something that's specific only to you and you're the only person who's going to be interested in it uh we
[02:44] may not have time to cover it uh there's going to be a little bit of latency in the setup unfortunately it looks like YouTube puts about 10 seconds on top of make a gaff and you're responding to it sorry we don't see you for about 10
[02:57] sorry we don't see you for about 10 seconds uh but uh we'll we'll get there and finally both Evan and I are going to try to take turns uh reading different questions and and going through this uh so uh you'll hear a little bit from both
[03:09] of us but if you want to direct your question at one of us or or the other uh feel free and and we'll try to accommodate so I guess to get started we got a question uh on one of the comments which I thought was perfect for you Evan
[03:23] and it was about how to prepare for staff engineering positions do you want to give us some insights on that yeah of course so first I'm going to interpret this as the staff engineering interviews I'll speak maybe a little bit
[03:36] have questions generally about a staff engineering role maybe they can put some can get to that but the first thing is this a really good question because resources are targeting mid-level or senior candidates there's not a lot of
[03:51] resources online for staff and so the important thing with staff is that you emphasize depth relative to bread so this is the trade-off if you're a mid-level candidate we say that maybe you do 80% bread and you go to about 20%
[04:05] you're staff then you're closer to that 50 60% depth and that 40 50% breadth and do is of course you need to have that foundation and so read your Alex Shu
[04:18] books read all of the resources online the grings whatever you need to do in you want to understand where are the places where you can go deep in an interviewer that you have the tech technical excellence and the technical
[04:31] depth to exceed as a staff candidate or as a staff engineer within the company can do this the first and most obvious is of course with experience ideally engineer somewhere or you've been executing at a high level as a senior
[04:45] leverage that hands-on experience in your interview to show off the places somebody else so for example if you've been working at Amazon you've been working on Dynam DB and you introduce dynamodb during your interview then this
[04:59] is a place where you're naturally going to go deeper you're going to talk about challenges that you've had working with dynamodb in the past the introduction of Dax uh things of this nature maybe Dynamo DB streams coming off Etc now a
[05:14] lot of people don't have that hands-on experience and they don't have the Hands-On depth this is natural actually it's more common I think Than People expect most staff candidates actually might even not have this hands-on
[05:26] experience and so the good news is it can be learned and a couple of resources designing data intensive applications that's the number one that you'll hear recommended all over the place fantastic book highly recommend you read that the
[05:38] others are some of the most popular kind of engineering blogs The Meta blog is a great blogs these are worth reading you'll understand the challenges that the engineers at these companies the staff engineers at these companies have
[05:51] faced when designing these large scale scale systems white papers as well the these are good things to read They're going to get your debth and then just lastly tactically what I would suggest is that you Zone in on a
[06:04] couple key Technologies and so maybe this is redis for caching maybe you're going to choose Kafka for streams and message cues Dynamo DB for for uh persistent storage and choose those three four whatever it may be and go
[06:18] really have the depth to show off in the interview in those particular places and that should hopefully be uh be enough to stand out as a staff candidate I thought there was a great question in the chat I think a niche asked how does meta
[06:33] evaluate a five versus a six for the same design problem we have any insights on that Evan yeah so I can talk to how I obvious thing that I just mentioned was death but actually the key distinction
[06:47] between senior and staff that I find is in the Simplicity of the design so that maybe I won't be able to do now but you can kind of Imagine a parabola and on the Y AIS you have the complexity of the candidate solution and on the xaxis
[07:03] you have their seniority and so kind of on the left of this graph you have not a engineers and the mid-level engineers they don't have a lot of complexity because they haven't learned a lot yet in the middle of this parab you have
[07:16] engineer they just learned all of these and places that they shouldn't be they talk about scaling in places where they don't make sense and then towards the right of that Parabola you end up having
[07:28] your staff and princip candidates for which they understand the complex with these Technologies and understand the difficulties in maintaining that more complex solution and they understand why a simpler solution is
[07:40] actually more elegant and better positioned to solve the given problem and so they're able to kind of subtly articulate that and it's what I find to be kind of the largest defining characteristic between senior and staff
[07:53] candidates awesome yeah I I wanted to behavioral side Evan's told you a lot about the system design but uh both the system design and the behavioral tend to be defining characteristics of a staff
[08:07] candidate and typically for these behavioral interviews the important aspects to cover are leadership uh a lot of people hear a question in a behavioral interview and they want to just answer it so somebody asked you
[08:20] what was the last conflict I had and it's about code styling with a you know mid-level engineer not a good answer so it's really good idea to make sure that behavioral interviews and what you're typically trying to cover there are the
[08:37] kind of fundamental behaviors that you're expecting uh of a you know a senior uh engineer who's leading teams probably on the 8 to2 engineer scale uh those are the types of responses that
[08:49] are going to be most important uh for landing that staff role yeah super important appreciate that you're right I was answering this thinking only about system design but Behavioral so incredibly important so we have another
[09:02] question that was submitted prior we'll get to that and Stephan I'll direct this towards you this is from The Karate Kid so it reads in a company like mea where formal structure doesn't really exist what role does the hiring manager of
[09:14] course you were a hiring manager at meta play for their team and the organization at large yeah I I think this maybe just a question about meta internals and I think for a lot of people they hear
[09:26] doesn't have a lot of formal structure and they think it's just chaos uh it's not you know there are teams they have responsibilities managers are in charge their team are growing that they're achieving their business objectives now
[09:42] there is a ton of bottoms up autonomy that is given to individuals on those team um if you are a senior or a staff level engineer you're kind of deciding what you're going to do and for managers part of the responsibility there is to
[09:58] sure people have relevant context building effective collaborations with nearby teams and then also making sure involved with the problem sometimes that's getting more people involved
[10:11] sometimes that's even getting less so when you think about hiring uh in this environment managers are typically thinking about a you know what is my space what does my scope typically require do I need more seniority do I
[10:24] need people with certain specialist skills or uh who are capable of operating in certain situations um and then you know how do I bring them onto the team in a sustainable way the worst case scenario for uh a manager would be
[10:38] to be perfect for the next six months but then ultimately isn't going to have anything to do so there's a really uh interesting balance there but I think generally speaking um there is a culture shock that you should expect coming from
[10:51] a more structured company say like in Amazon into meta I know I went through that uh but it's not uh nearly as different as as you might expect it it just takes them getting used to so Stephan we got a question here in
[11:05] the chat uh maybe if you want to answer it and I can jump in and add anything that maybe you miss but somebody asks 35 minutes for a staff system design questions that you haven't seen before what's the best
[11:18] strategy oh this is a a great question um I would say that when when I'm working with staff candidates most of the time what they do is they jump straight into a question and try to move as quickly as they can and I think the
[11:34] urgency is really important but those initial few minutes that you have both really understand the constraints of the problem are also the time when you should be identifying what's the Crux what's the most important aspect in any
[11:49] system design question in particular you're going to have something that's the interviewer is kind of hinting at it might be proximity surge it might be some really high rthr put it might be something else but
[12:02] that's typically where you want to go deep and it's really important that you identify that and you focus most of your time and effort so like a mistake that I frequently see from staff candidates is they read a lot of material online they
[12:15] read these books and they want to go through all of the steps of system design and they want to tell me about how load balancers work well I know how load balancers work I know you know how load balancers work let's use the time
[12:30] as effectively as possible to demonstrate your unique specialist knowledge as opposed to kind of wrote things that I would expect from any senior engineer in the group so the key here is you know generally speaking you
[12:44] do have a very short amount of time but the the most important thing is that you use it effectively um Evan would love to hear your experience on this yeah no I the main thing and the way that I typically respond to this question is
[12:58] it's all about staying focused and so often day after day I see candidates just provided they put down an API Gateway and they want to explain to me the role of the API Gateway in the system and that's not interesting I want
[13:13] Yelp I want to get into proximity search and so you need to be able to lead the conversation in those directions and make sure that you're going deep in the thing that I'll add here is just that Frameworks make a huge difference so on
[13:27] design interviews there's other Frameworks online but by following these Frameworks the idea is that you have a linear structure for which each kind of section of the framework is building upon the previous section and the goal
[13:42] of these Frameworks is for you to be able to linearly build up your thinking such that you can start with something simple and evolve it into a more complex simple and evolve it into a more complex design in the appropriate amount of
[13:56] time awesome uh we got another question keep on the right track I might have interrupted you there we had a bit of a a skip um we had another question that came in about how
[14:10] to handle uh if you're bombing interviews Midway through I I think the the the Crux of this one is um an interview is really stressful and sometimes people are like halfway in and they realize it's not going well and the
[14:25] question is is there anything that you can do to kind of uh Salvage the remaining time that you have available love to hear if you've got any thoughts or tips for this Evan yeah so this is this is really
[14:37] tough um the reality is that like the number stay calm because your other interviews could end up going really really well and then you want to make sure that this one is just salvageable enough that it
[14:52] interviews and potentially you end up with a follow-up interview in order to and so the first thing that I would do is take a step back take a deep breath calm yourself down you know the anxiety is Raising you're feeling stressed
[15:06] that's natural pause re-evaluate and then get the interviewer more involved not sure the direction that you should go in or where you should focus and so trick you and in fact they feel uncomfortable when you're bombing it to
[15:21] you know you're not going to get into the company so be it that's worst case time then to just have a conversation between you and the interviewer let them interesting turn on your problem solving brain and work through the problem uh
[15:37] and I think that's ultimately really all you can do Stephan do you have an additional perspective on that I mean the only thing that I would add is sometimes that recognition that things aren't going well can be pretty useful
[15:49] I've worked with where you know about 15 minutes and they're way off track and even going to get to the end of the problem and they go hey this is not working I'm actually going to take a step back and and reconsider and they
[16:04] functionally start the interview over now of course you're not going to repeat all the sections but um you know they basically had taken that moment to to recalibrate and in some cases I've given higher decisions for these people first
[16:17] a creek like not everybody is perfect the first time through I think that's crazy from an interviewer perspective to make that assumption and then secondly their ability to kind of retrace their steps and then move forward uh was
[16:30] actually kind of a a great way to demonstrate you know their uh their level of expertise and experience so actually Rel go ahead I was just gonna say related we had a question coming from Lulu which
[16:45] have a good perspective on this they want to know more about the Deb debrief maybe they did well or they feel like they did well on the system design interview how are things tabulated internally to
[17:01] decision awesome question and I think this really varies Company by company and almost any company is going to have some sort of deliberation that happens after the fact I I think a lot of folks are under the impression that every Loop
[17:15] needs to be all hes and the reality is actually these all higher Loops are very uncommon uh in most companies you're going to have some new higher aspects of your loops and so there's a a couple things to kind keep in mind one is
[17:31] usually the debrief the discussion gets into more specifics it's not just a binary did they pass or did they fail each of these interviews it's what signals did we get from them are they great at problem solving but they
[17:44] screwed up some of their code quality okay are they you know really strong leaders but it seems like they're not as good as mentorship like these are much more specific and the worst case scenario for candidates in these
[17:56] debriefs is you've got corroborating evidence so in the behavioral your and then also they got some weaker signal in the system design those are usually things that uh will cause a candidate to get passed on the other
[18:12] thing that a debrief is going to consider is the risk and this can vary team on team this can vary company on company but usually hiring managers and and you know ultimately the interviewers who are debriefing are going to frame
[18:26] this from the perspective of what's the worst that could happen almost every and you know the company's going to need to eat it the real question is is it tolerable is the downside that bad and a frequent thing that I hear from hiring
[18:42] committee meetings at meta is this candidate wasn't perfect here but look I've got a team with really strong Engineers on that and I'm ready to set up mentorship so that they can be
[18:54] successful out of the gate that's usually the cause for a higher decision so I would say don't stress out about you know individually each of your Loops whether they're you know higher or not try to give your your kind of best
[19:07] performance across the board uh but try to eliminate those places where you might have kind of contradictory signal from from different interviews um in the best case scenario each of your interviews might have problems but they
[19:23] don't sum up to something that looks uh a bit more risky and then also I would say this is generally not going to be actionable advice you know a lot of dissect their interview after the fact and they try to figure out how exactly
[19:38] this is going to go through a sequence of decision makers to a higher no higher decision when the reality is you don't have any control over that you only have control over the inputs so I'm talking to a lot of people where I'm saying this
[19:51] is the best you've done you you you know you've you've given it your all you just uncomfortable messaging for a lot of people people but sometimes after the interview that literally is the best thing it it is mostly an emotional
[20:08] so go ahead no worries I just gonna laugh blurry so apologies people this gigabit connection isn't working so well also stepan's audio cutting out for other people you say in the
[20:37] is probably one that that you've got a good pers probably one that would be appropriate for you Evan and it's you know how do
[20:49] you tackle a question that's dissimilar to anything that you've seen before uh this one came in from Sundar and I think the idea is you can prepare a lot you can memorize a lot of questions but what if you get something that you just don't
[21:03] know a lot about what do you do yeah so this question is pretty similar to the one that we had a bit earlier for questions that you haven't seen before what's the best strategy or maybe since I talked a lot about system design in
[21:15] that one I'll I'll recap that and then uh I'll kind of specify maybe for different interview types like coding so first for system design the most up front it's a system you haven't seen before then you're going to want to
[21:27] order to understand the scope of the problem that's going to be really in too much detail you're going to follow that framework to build up your Solution linearly that's going to be important now with coding I think uh you
[21:43] which is that people practice so many point where many candidates nowadays have done 300 500 600 whatever it is lead code questions and so they're fantastic at those 3 to 600 but if you
[21:57] you're shocked and you're on your heels and you stumble and I see this so so so regularly and the key here is how quickly can you flip your brain from what we call pattern matching mode to problem solving mode so you're going to
[22:11] for have I seen this before does it match something that I've seen before and at a certain point after you know 30 seconds you should give up on that path for you to turn on your problem solving brain which is a very distinct switch in
[22:25] and now you need to go step by step build up from first principles just like have a clear understanding of the problem and then break it down start with an easy solution that's not optimal and then optimize after you have that
[22:39] easy solution already on the board ah this is awesome Evan and I I think that for a lot of people this kind of memorization trap is a really easy one to get into um I I think it it's a comfort for people if they've seen every
[22:55] encountered it before then they can recall it back but what I find in a lot of cases at least in mock interviews is that people who are really good at this memorization often times struggle to recall in the the actual question and in
[23:10] many cases they have difficulty pivoting outside of the question that they've seen before and so while it's really good to prepare I I'm a very strong advocate of preparation be careful that it doesn't degrade into just the simple
[23:25] recall exercise because the most important thing is like what Evan says solving that's ultimately what your interviewer is going to be assessing and so it's entirely possible and this is incredibly frustrating as a candidate
[23:40] for you to have the correct answer but not be able to demonstrate any of that insitu uh problem solving and then get a Noire decision and then you're going what the heck happened and that's usually what happened uh so yeah try to
[23:56] get out of that uh memorization trap because it it will sync you so we had we had two questions one that came in Prior following your
[24:12] in the chat is can we have deep Dives on DBS what usage patterns for SQL and no SQL respectively I know that you had a killer LinkedIn post about this recently there and if people aren't following Stefan on LinkedIn go go find them oh no
[24:27] got good stuff I'm not sure about that it was a hot hot take so I I got a few emails about that correcting me on on some of its deficiencies but um I I will some of its deficiencies but um I I will say this um a lot of people prematurely
[24:41] jump into what is just like an arbitrary comparison of database Technologies so system and they think that the first thing they need to do is compare and thing they need to do is compare and contrast SQL and nosql databases and I I
[24:55] don't think this is the right approach number one it opens up you to a whole Litany of questions that you probably don't want to answer and secondly it's not obviously relevant to the problem at hand if you've got a good idea of what
[25:10] solution that you want to use then it's probably a good idea to justify that trade-offs that you're taking into consideration but don't over fixate on this comparison at least out of the gate it's entirely possible that your
[25:25] interviewer is going to want more detail and they'll follow up with you for sure but I wouldn't actually recommend that you go and volunteer to go and be the the perfect uh person who's comparing database Technologies almost no one is
[25:38] and it's not a generally good strategy uh for the interview another thing that I would say is the contextual relevance is actually really important so as you're you're choosing a database technology being able to explain like
[25:54] what parts of the problem are an input to your choice is helpful something that I very commonly hear from candidates is oh I've got relational data AO I need to use a relational database um
[26:08] no that's that's not necessarily true so like as a great example graph databases uh are are perfectly suited for relational data uh it's a different style of query it's a a different style of problem but this is the type of thing
[26:24] where you not having a really good uh graph on the problem itself is going to lead you to make somewhat faulty uh technology choices so get really deep
[26:36] into the problem uh bring up the the context that's necessary don't do anything that's going to surface unnecessarily uh gaps in your knowledge and try to move quickly toward the Practical aspects you've got to solve a
[26:51] problem so don't spend 5 minutes telling me about you know some big debate about me about you know some big debate about SQL or versus no SQL now um one thing on this and this is just a trap and it's a really unfortunate one is that this is
[27:03] often times like a pet interest for many interviewers some are fascinated with distributed systems and love their nosql databases others are very Simplicity bias this would be me and want to use relational databases to their full
[27:19] extent because we want to minimize the technology service area you won't know your interviewer's bias before the interview starts but you will be able to read it based on how they respond to uh your your discussion so try to take as
[27:33] much of the non-verbal language that your interviewer is communicating to you as well as things that they're explicitly telling you or asking you as an indication for kind of what camps are they sitting in uh the worst case
[27:46] scenario is you just happen to be at odds with the preferences of your interviewer but you've got actually really deep technical knowledge this or senior uh levels as opposed to staff plus where
[28:00] people have kind of seen everything and if you can ascertain that in your if you can ascertain that in your interview you can make much better
[28:13] questions here it looks like we've got another one on the chat um says what data on The Meta side do you have to determine what sort of questions uh to ask uh do you see a a pattern asking these questions results in more failing
[28:28] or passing of candidates this this actually is uh kind of the uh how the sausage is made of the interviewing process Evan do you got got any insights the internet character I'm been trying
[28:42] these gigabit connections can keep up but something's going on the flickering as it pertains to this question so here's what happens on the inside there is a question bank and that question bank is like recommended but not
[28:55] mandatory to use and so when you like the most commonly asked questions that design questions that you always see being talked about as always being asked these are probably from the question bank and so most new interviewers in
[29:08] this question bank because there's a bunch of discussion in it from other could be answered and what good Solutions are and bad Solutions may be there are of course tons of interviewers there are lots of interviewers at big
[29:23] there are a lot of interviewers who won't choose something out of that question Bank they'll choose something that's maybe relevant to their team uh or something that they just want to ask about and then as it pertains to kind of
[29:36] of questions and pass and fail I think the reality is of course yes like some questions especially in that 20% made up 20% I just mentioned where candidates are not choosing or
[29:49] out of the the question bank there's probably a higher likelihood that some candidates would struggle with them more now recruiters are supposed to try to normalize for this they see statistics per interviewer so they see things like
[30:04] candidates disproportionately relative to other interviewers and as a result we'll maybe kind of consider that when doing the overall decision um so the companies try their best to debias along this Dimension but it's certainly not
[30:18] perfect and I think from a candidate's perspective there's not much that you can do other than of course use your resources online in order to familiarize if anything you should know those going in at least uh within some some reasonal
[30:32] reasonable degree of understanding and then beyond that be ready to be be nimble I want to add a couple dynamics that are just kind of interesting to that are just kind of interesting to this so generally speaking um most times
[30:46] the common questions are not like a deliberate decision from companies it's just an artifact of the fact that um interviewers tend to Shadow one another and so they share their favorite questions and so it's more of a social
[31:02] is really unfortunate because some companies and like my favorite is open AI have a very narrow set of questions that they end up asking candidates and
[31:14] against their interests and I think internally people generally know about this they just haven't fixed it yet and so you know I would love to elevate the interview game for companies but for now that's kind of of the reason that things
[31:28] exist like they do now there is kind of this common notion amongst candidates or amongst Engineers that there's probably like these perfect questions that surely with data must align with some terminal objective and there's two things wrong
[31:42] with this line of thinking the first is if you somehow had an interview question long-term performance well they probably that would be a way better indicator of whether they should pay you more or
[31:56] invest more in your career or whatever it it doesn't exist it there are no signals that are quite that strong the other side of this that that's kind of interesting is the ground is always shifting not only are the interviewer
[32:09] populations moving but the questions become invogue or out of Vogue the topics become more or less relevant so this entire game is is very Dynamic and you know my objective as an engineer is not necessarily to be the optimal game
[32:25] player I want to be the best engineer possible and I think over a long enough time Horizon that's probably the best you can do now it doesn't mean that you need to be kind of closing your eyes and going to this process naively there's a
[32:39] bunch of things that you can do to prepare but they do have diminishing returns so people expecting that you know you'll be able to memorize exactly the question you'll get in the interview or that the rubric on which you're going
[32:51] to be gred is going to be perfectly precise and repeatable uh it's just not realistic unfortunately so I think for the folks that we're working with we want them to be uh you know idealistic in that the optimal strategy for this
[33:06] game at least the majority of it is just to be a better engineer but realistic in that the process has its holes and you can be more effective in your preparation um by at least acknowledging and understanding uh those
[33:21] holes so we have another good one here I think which came in Prior on one of the posts uh it reads I've got a team match call scheduled tomorrow for meta em recommendations on how to handle those calls tops dues and don'ts and just
[33:37] call out stepan did a great interview with Christian who is an engineering channel and they talk at length I think interview so David in particular and other folks who are interested in that
[33:50] check that out as well but Stephan thoughts here yeah good call out I think Christian actually gave some great advice in that interview it's it's about mid Midway through 3/4s of the way through um team match and this is
[34:03] typically something that meta or Google would do and really the the setup is think you're a good fit for the company they don't know which team that is going to be a most appropriate is probably best thought of as like a weird kind of
[34:18] third round of interviews now the companies don't want this to be the case but they will actually pull your offer if you don't find a team now this doesn't happen very often I don't mean to unnecessarily stress people out but
[34:30] it's important that you know that that happens on occasion so that you don't go in thinking this is purely for you know your um you know best fit it's just not um the hiring managers in those situations are trying to figure out do
[34:45] the strengths that you have align with what I need on the team and so in the best case scenario what you're doing in those sessions is you are explaining motivated by and what are you really good at um and then understanding from
[35:01] the hiring manager what are their challenges and how might you fit in the best matches are going to be ones where those things align now you can kind of those things align now you can kind of force those things to be wrong in in two
[35:14] things that you should try not to do in team match interviews one is to be over prescriptive the reality is that the work is never going to be perfect you need to choose something that's going to be helpful um for for you that you're
[35:29] might have some warts or things that you're not excited about yet but for a lot of people they go join a team you know I had no had no idea how to do time series forecasting before I worked on it at Amazon and it turned out to be
[35:43] incredibly exciting so take a bit of a risk um the other thing that people will do is flip the opposite direction and try to make themselves as generic or uh kind of complimentary to any team as possible and this is almost certainly a
[35:58] mistake because hiring managers sniffed this out if you're you know Target telling them that you're excited about anything but you really don't have any obvious indications to why they're going to be deeply skeptical of this and the
[36:11] reason is because they have to deal with the ramifications of this down the road whining about how you hate the work that's their problem to work through with you and so they really are incentivized to try to find as much as
[36:25] possible a a match between what they're offering and uh what you're looking for uh as early as you can so I would say this um you know be a team player make who's really going to work with them think strategically think about the
[36:40] longterm of the team think about what they're trying to accomplish start to tease with it so that the hiring manager knows that you're taking it seriously be that you do really well especially things that you do better than you know
[36:54] many other engineers and then also those things that you really want to work on but be really flexible uh because in general a you do need to make a choice appetite for you to go into this team match process but also there's a lot
[37:09] about this where you will find a team you will adapt you'll actually probably uh learn to love a domain as long as it satisfies some base level requirements hiring manager about what those are for you I think you're going to have a good
[37:24] you I think you're going to have a good time so those would be my suggestions looks like we've got some more in chat um I'd love to go through some of these um product architecture uh product infra
[37:36] should we go discussing user interactions and apis in product infra versus SD interview maybe a separate uh video doing a well-known system design question like ticket Mas I think we
[37:50] question like ticket Mas I think we might have lost it no worries please start from the beginning Ticket Master
[38:09] oh it looks like it's back but it's just a lot delayed says back back all right a lot delayed says back back all right are we back yeah all right we are we are
[38:21] back let me uh I I think it cut out right before you were about to get into right before you were about to get into the meat of it Evan so um the question was how deep should we go in discussing user user interactions and apis in the
[38:35] product infra versus uh system design interview and from the chat we have that interview and from the chat we have that you are in HD now so welcome to uh the 2020s nice I didn't change anything but shout out technology um okay let's see
[38:51] answer the question again after talking to ourselves for how many minutes there um so the question yeah the difference between product infr infrastructure or that's where I wanted to start it so the first thing is we have a great blog on
[39:03] the website people should go check that out it details the differences it shows that's the first place that I would start but my highle summary is that people overthink the differences they are largely the same and the fact is
[39:17] and uncertainty about the difference between the two so many interviewers interview and basically ask a question that they would ask in a system design interview for better or worse but you should be prepared for that so the only
[39:31] that in a product architecture interview you're largely guaranteed to be asked a application the design Ticket Master Uber Yelp Dropbox these sorts of things whereas in system design you could get a question about a user facing application
[39:46] but you could also get a question that's focused on like a singular component or is zoomed in aspect of a system like design mcache or you know design a what you should be prepared for but in the case where you're asked a question
[40:00] about a user- facing application in either a product architecture or a system design interview our example here is Ticket Master the reality is you can largely deliver the exact same interview and pass both of them the YouTube video
[40:12] somewhat of a blend things like the virtual waiting queue are great product product architecture interview but are also fantastic in a system design interview when we talk about uh you know
[40:25] interview when we talk about uh you know scaling the the the real time nature of uh the seat map that's more naturally maybe system design but also a fantastic thing to talk about in product architecture so don't overthink the
[40:37] difference they're largely the same thing the last thing I'll leave you with is ask your interviewer if you're unsure as it pertains to the apis in particular I'm going to sketch out my simple end points would you like me to go into more
[40:50] this enough and they'll tell you and this goes for any question like this your interviewer or and just try to get a pulse on what they're looking a pulse on what they're looking for perfect yeah um I'm going to go to
[41:03] the chat with another question actually first to comment to aspiring uh we we desperately want Jordan to to come so go ahead and tag him in the comments constantly in touch with that guy but uh yeah I I think he's he's actually you
[41:18] know very preoccupied with making as much content for his channel as possible so I'm not sure if he wants to make videos for us but we would love to have him um we had a question in the chat would love to know more about thriving
[41:30] would love to know more about thriving as an L6 this was from rashme um so you touch on this a little bit in an interview that I did uh with Jordan but
[41:42] one of the most important facets of being an effective staff or principal level engineer is understanding your systems deeply building trust with the organization and then using those two
[41:55] things in order to take big bet and kind of go for it I I think a lot of people of go for it I I think a lot of people get these out of order um so you might join say meta or Amazon or Google at a high level and you think oh my gosh the
[42:09] around me are delivering these immense things I've got to swing for the fences and the biggest problem with that is they're all probably pretty skeptical although they're willing to give you the
[42:21] benefit of the doubt so you can prove yourself and if you go swing for the fences without that benefit of trust beneath you you're you're going to fail and so most often the easiest way for you to get started is to pick up the lwh
[42:34] hanging stuff go join the on call go take on the the tasks that nobody wanted to pick up build some documentation for uh your system not only will this help to enable you to to build some rapport with the rest of the engineers in the
[42:48] team but it'll give you that depth of knowledge that's going to be necessary for those bigger swings now you can't stay there forever you need to gradually ramp up and you know ultimately this is a negotiation with your manager because
[43:00] you want to make sure that their expectations are are met as well but eventually you want to start taking those bigger bets and it's a huge mistake for staff and principal level Engineers to kind of Silo themselves off
[43:14] with two or three Engineers that are their favorites and build stuff that they love that may not provide kind of the incremental value or leverage to the overall organization so if I were to describe the ideal kind of set up for a
[43:28] staff level engineer it's a ramp that starts at the ground level that helps you to build trust with the organization but that quickly moves up more toward what you might expect uh to deliver at that level and you need to have the
[43:42] support of the people around you don't forget that your job is probably as much wetwear as it is software or Hardware in these roles and so you need to make sure and that they're strong one one thing that I'll add to
[43:56] that the relationships are so important and what goes hands inand with it is as you're growing in seniority widening your aperture so you're going to start as a mid-level engineer and you just have visibility to what's happening on
[44:08] your comfort zone and make suggestions to how things could improve in your team stretching yourself and then as you're a senior engineer you have full context to your scope and maybe now you're starting to make some suggestions to how things
[44:23] should change or evolve in some of the sister teams and then eventually as grow to staff engineer now your apertures widen a significant bit significant bit connections that stepan was just mentioning in order to understand what's
[44:35] happening in the teams and in some cases the organizations around you in order to propose solutions that are more overarching and as a result more overarching and as a result more impactful yeah good comments we got one
[44:49] would be great for you Evan it was from Min no the question is how to deal with tough interviewers I I might frame these as bad interviewers but tough interviewers who expect specific answers and will not let you move forward with
[45:04] other areas in uh the system design how can you deal with honestly non non-trivial proportions of the interviewer
[45:18] um so the first thing that comes to mind is that there's a careful balance of like politely educating you want to work with your interviewer and understand and empathize with the situation that they're in many interviewers have a lot
[45:31] of stressed out especially if they're new to doing this and that they're you might be saying things that they're not even familiar with they're rapidly Googling at the same time and they might have a narrow perspective on a solution
[45:45] simply because they don't have exposure to more this is at least one possibility and so one option for you particularly if you feel confident that the direction that you're going in is appropriate is that you can try to politely and I
[45:57] emphasize politely educate here so for example if uh you know your interviewer is going deep on what happens if Kafka goes down then maybe you just lightly educate that actually at least in a managed context the idea that Kafka goes
[46:10] down isn't very reasonable like it's built from the ground up with durability as a as a core principle and core emphasis and that's not a question that love to talk about what happens for example if a consumer goes down which is
[46:24] considerations I was designing this system and so you can sort of reor system and so you can sort of reor reorient them uh appropriately now if they have something in mind then you have to be a little judicious and maybe
[46:38] answer that they're looking for you have to maybe swallow your pride in that instance go down that direction in order to satisfy them because ultimately there is a bit of a game here as much as I hate to say it and you're trying to
[46:51] impress them in order to get the job so it's a tough trade-off I wish I had a better answer than that try to year if you realize that you can't then accommodate they're ultimately the one in in in control that's probably all you
[47:03] can do I this is part of the reason why I think a lot of people interview at multiple companies because in some cases it's the luck of the draw whether a performance or whether the person on the other end I I will say that
[47:17] interviewing especially for new interviewers can be such an ego trip and chance to I don't know try to assert their their value uh this was a very common thing at Amazon in particular uh I don't
[47:33] know why but a lot of my interviewer peers would interview googlers or people from Facebook at the time and they were very critical like if you looked at this objectively uh they they were probably holding the bar a lot higher for these
[47:48] engineers and I think part of this was this implicit comparison like they work at a different company if my bar isn't higher then am I not a better engineer and at the time I was a bar raiser so I needed to go and challenge uh these
[48:02] interviewers to really understand what was beneath it but I I think if you understand that as much as the interview process can be anxiety-provoking for you as a candidate there is this sort of weird psychological crisis that your
[48:16] interviewer is sometimes going through which is trying to deal with am I good enough and a lot of the times what Evan just said is you know being respectful and appreciating their suggestions and rolling with them can be the easiest way
[48:31] to turn that kind of fight ORF flight from a bad interviewer into a conversation amongst peers uh in my interviewer interviews uh I I like to treat it like a game and and let my interviewer know that you know
[48:45] this is an exercise for me and you know I'd love to work with you on this together this can be fun and that takes us both out of this mode where I have to actually there's you know know hundreds of thousands of dollars in the line and
[48:59] where they're performing somehow in their assessment of me um so that may be a trick that you're able to employ uh in your sessions uh another thing there
[49:11] your spot on something Christian talked about in your interview with him is that if the interview was really off the interviewer was really pushing on guys were just out of sync for any reason you should feel encouraged to
[49:25] bring this up to your recruiter there's no harm in doing so you can mention to in the interview and explain what they were and it may result in a follow-up interview you may find that the interviewer felt similarly um and this
[49:38] can kind of bode well for your chances there's no harm in doing it yeah incentivized to try to get you through the door that's usually how their um their performance is is measured I think we've got time for one more question but
[49:55] um you know wanted to to say thanks to everyone for showing up and and staying with us for this hour uh would love any comments if you if you got anything out change if you'd like to see us do this
[50:07] again um that would be super helpful um go check out the content on our site we answer a lot of these questions and and more with both our guide and our blog and you know if there are things that we are actually not answering sufficiently
[50:21] uh these are great things for us to actually go and address with incremental guides so add the comments we love to read them we respond to to as many of them as we can um and would love to go from there um Evan I think there was one
[50:35] got one from the chat that I think's going to be great for you so the Crux of the question is how do you navigate an org which has a lot of bureaucracy or long running processes and reviews when
[50:47] you're really just trying to get in the case of this question something simple case of this question something simple done this is a a great question probably probably spend an hour on uh so it's it's appropriate for the last two
[51:00] minutes um I I think you know everyone is going to exist in a degree of organizational dysfunction and that that's just life organizations are are imperfect the the thing that you need to understand is why do those processes why
[51:17] do those reviews why does that bureaucracy exist and then who has the bureaucracy exist and then who has the power to override them so as an example you absolutely hate your Sprint planning process you do a bunch of estimations
[51:31] and you think that this is a huge waste of time you could gripe around it about team and they're going to get frustrated with you eventually because they're living with the same thing uh together
[51:43] you could talk to your manager and you know they might tell you hey this is how we do things at this company um the more important thing for you to figure out is why are you doing that in the first place and depending upon the company
[51:56] that you're at one of the reasons might be well your product team is on your manager's ass all the time about deadlines and how they can hit them your team hasn't delivered successfully in the past and as a result they're going
[52:08] follow up with you know everyone on the team for weeks up until uh that deadline and so the important thing in that case if you want to make a change to the bureaucracy or the process is to address
[52:21] the thing that's causing it which in this case is probably an underperformance on on your team um that can be a tough pill to swallow and to be frank you know not every organizational problem can be solved at your level or
[52:35] by you in some cases you do need to make the decision can I influence this is this something that you know I really want to go to war about or should I go find another team or another space but if you truly do want to to make changes
[52:49] or or in order to to influence this the key thing is really understanding what's keeping uh this constru or this process in place and how can I start to eliminate that constraint uh that's the trick don't try to address the the thing
[53:04] never is going to be the thing that you change first um I could talk about this for ages maybe we'll save this for for another Q&A uh but for all of the engineers who are stuck in crappy organizations uh salute I feel sorry for
[53:19] you um yeah it's it's part of the the luck of the drawn software and different teams in companies that hopefully you will move through and you know the trick is just to keep moving in the right direction you'll get better at
[53:33] environments but you'll also find especially as your skills improve that you get a better voice and choice uh of the environments that that you uh are going to be in so yeah um again I wanted to thank
[53:47] everyone for the time this has been a lot of fun I I hope you found this comments if there's anything else that you'd like to see or if you'd like to see this again uh we'd love your feedback but if not the recording should
[53:59] hopefully be barrowing any technical difficulties available on our channel uh we'd love you to have you as a subscriber and uh check out our website hello interview.com uh if you've got uh an interview com on coming up uh there's
[54:12] great material there for preparing for system design behavioral coding manager interviews uh we got you covered so with that Evan thanks for for joining me and uh we'll talk to you all a little bit later bye everyone one