YouTube Deep Summary

in a perfect world every company would have the same leveling systems sadly this isn't the case there's a very real risk that companies see your potential but extend an offer to you at a lower level it sucks and it forces you into an uncomfortable position accepting the offer even if it's more money at a better company might feel like you're groveling at the feet of their bad judgment it's just better to come in at the right level than to battle for a promotion just to get where you should be in this video i'll share with you the reasons why this happens and show you how to avoid it meta here i'm a principal engineer and i've conducted more than 800 technical interviews for amazon during my 15 years at the company i'm a bar raiser and i train other amazonians how to conduct technical interviews and how to run debriefs while i work at amazon these videos express my own opinion and the contents of the video do not contain amazon confidential information i've run hundreds of debriefs for engineering loops this video will focus on technical interviews but the concepts are also useful when you're describing yourself to potential new teams talking with recruiters during performance review time or when you're making a stab for promotion pretty useful stuff companies are trying to fill a specific need when they decide to interview you hiring somebody at too high of a level has disastrous long-term consequences it takes a long time to fix the problems of getting someone's level wrong and it usually will end poorly like in termination it also takes time and resources that no team has to spare on top of being very uncomfortable for all parties involved so that's why companies employ down leveling it's an easy way to hedge against risk if there's any ambiguity during the interview about what level you're currently operating at if you feel like you've been down leveled there are two cases to consider it very well may be that they got it right remember levels at a company are relative you need to be open with the possibility that they made a correct determination of your level at their company perhaps you were the cto of a failed startup with three engineers and they gave you an offer of senior developer at a mid-sized company you can scream all day that you're being demoted from the c-suite but in reality you aren't being demoted you can use sites like levels that fyi or glassdoor to get a sense of levels across companies years of relevant experience and expectations when applying to companies sometimes levels at one company straddle two at another it's okay to be ambitious if you're being realistic be wary of sites like blind for this sort of research there are a lot of stories where people brag that they receive de facto promotions by moving companies people say a lot of things when their words can't be traced back to their identities sometimes it's true sometimes it isn't the key here is to be honest with yourself after doing your research while it might be nice to get a title you don't deserve you'll be in a world of pain if you can't meet next level expectations your goal should always be to write level yourself at the new company the second case is that they just got it wrong you actually operate at a higher level and for some reason they just don't see it interviews consist of functional questions and behavioral questions if you bomb them no offer will be extended if you do really well on both an offer will be extended at the level you applied for down leveling happens in these two quadrants if you had a barely passing set of coding but you did really well in behavioral questions or you did really well in coding and design but you didn't do a good job relating your experience this is the down level zone in both of these cases the behavioral part of the interview is where the opportunity is a strong behavioral interview component will ensure that you don't get down level if you did really well in the coding and design portions of the interview and it can save an interview loop if you just did mediocre on the functional parts humans are narrative animals during the interview your job is to convey to the interviewer that you have what it takes to fill the need they have think about trying to describe a good friend to someone that hasn't met them oh my buddy meta yeah he's he's good he's smart kind of funny a little quirky you know good stories for interviews really just have one shape and form bad stories can be bad for many reasons but the most common is that you're trying to tell the interviewer how good you are when you should be focusing on showing them how good you are metta that guy he's been in amazon for 15 years so he's either tough as nails or really stupid i don't know how he does it he's got this demanding job just had a kid and he still has time to make these quirky youtube videos classic meta star stands for situation task action results and it's the classic way folks are trained to develop stories for interviews you describe the situation you were in what your task or mission was the actions you took and the result turns out it's a terrible algorithm for generating stories the problem is that it's too focused on what happened rather than developing the character you remember the point of these questions is to determine that there's a good match between you and what the company needs the proper story the interviewer becomes invested in you what you should do instead is to use the simplest of the story shapes kurt vonnegut calls the story shape man and a whole but it doesn't have to involve a man nor does it have to involve a whole basically you start by anchoring the story on your status and responsibilities on a team by using terms from the job description after you have established this context you layer in conflict challenges and obstacles you want to lay it on thick here many layers make it much more satisfying when you finally overcome and achieve success don't overthink it an effective story has a general u-shape the magnitude of the use signals to the interviewer everything they need to know about your level where the use starts and ends tells the interviewer what level you operated at and what type of impact to expect if you were to join how far the u dips tells the interviewer what the size of the problems are that you can deal with so it turns out star is useful don't use it as a story generator you star as a linter on your story to make sure that it has a point in other words you start after you've crafted your story to make sure the story has substance hey uh meta is it yeah cool can you hear me yeah i can hear you yeah i can hear you cool um great thanks for taking the time to interview with us um can you tell me about a time you made your team's processes software or system simpler uh okay yeah um my team and i inherited some software from another team since it made sense for our team to own it instead of their team since our team provides a lot of the data for the flagship feature of our product turns out it was really buggy and was adding a lot of operational burden to the team and on top of that it had a dependency on a library that represented a pretty large security risk that was going to take a long time to migrate away from yeah once we found the library though uh corporate policy was that we immediately migrate away from it this was really bad since we had a big launch coming up soon i thought it'd be best to deprecate the service so i worked with all of the clients of the service to move them off of it and our existing software it was a ton of work but the service now is decommissioned and we don't get paged in the middle of the night as much as we used to uh the system architecture is is so much simpler now and we know how our data is being used downstream um can you tell me about a time you made your team's processes software or system simpler cool yeah i was the team lead on a team of eight sdes that was responsible for several mission critical data plane services for our flagship product i was responsible for not just the system components or the features that my team owned but really the team's architecture i spoke with an adjacent team and we decided that it made more sense if our team took ownership of some software they owned because it aligned with the charter of our team much more than it did theirs turns out it was pretty buggy but that wasn't a big deal after i squashed the bugs and added unit tests and integration tests the big issues started cropping up later it started paging our on-call engineers late at night people would just restart the process and go back to sleep but when it was my on-call i dug into the issue and it turns out we depend on sus4j yeah sus4j its usage is not allowed in the company and we were on the hook for migrating off of it immediately we estimated that it would take about a month of dev effort which we didn't have because of an immovable deadline two months away i decided that the only reasonable course of action was to decommission the service it wasn't going to be easy but it wasn't going to be so bad because the original reason i decided that the team should inherit this service was because it was so similar to the services we already had but we didn't know who was using the legacy service cool so uh what did you do so um we turned pass-through mode on uh through the service configuration which requires clients to identify themselves at request time it didn't like stop them from you know getting at the data that they needed just sort of identified them i analyzed the logs and created a spreadsheet to track and it turns out we have like 27 teams that use this service i set up meetings with some of them and it turns out most of them could get what they needed from other services that we owned so i created a campaign to deprecate the service we split the clients up amongst my team members and i went to our vp to get an exception for you know not removing sus4j for a couple of months we let the client teams know that the service was going to be shut off in three months and that we would provide support to them to move to our existing endpoints and you know by sort of by analyzing their use cases this was disruptive to our schedule but it didn't blow up our project there was one team though that really pushed back on us we didn't have any apis that could help them and they escalated up the management chain after our big launch i was able to work with them to design and deliver the functionality that they needed it was kind of painful though because we didn't have bandwidth to work with them while we were heads down trying to launch even after we gave them what they needed relations between our team are a bit strained today i think on balance it came to a positive outcome though pretty happy with the way that the architecture looks afterwards the magnitude of both sides of the u and the depth of challenge you faced needs to be commensurate with the level you're targeting if the challenges contained within your story are small potatoes then you risk a down level conversation same goes for the sides how do you know it's big enough because they are part of your roles duties and responsibilities at the level you're targeting the key is that you make it easy for the interviewer to make a relative judgment on your level by anchoring them with your status and demonstrating that you can rise to the challenges appropriate to that level and more importantly that you have perspective on what it takes to operate effectively at that level if all of your stories make you sound like a junior engineer solving junior engineer problems you're not going to get a senior engineer offer just because you're using the same story shape doesn't mean that you can't make it your own you can make it funny self-deprecating dramatic it's all up to you constraining the story shape doesn't constrain your voice or make it inauthentic okay let's talk about making stuff up don't do it there may be a chance that you get away with it but more than likely you won't be able to answer all of the follow-up questions if these stories don't come from lived experience you had 123 girlfriends during college yes can you show me some pictures of them no are you being serious yes do you remember any of their names i don't remember that must have been a crazy time it was a crazy time if there's a suspicion you're telling tall tales the most likely outcome is no offer you can make a story easier to understand by simplifying some details or reordering the elements in the story to make it flow better but don't risk undermining your credibility by lying just takes a little suspicion you might be tempted to tell someone else's story since you were close to the action but you're unlikely to withstand the follow-up questions because there's too big of a gap between the hypothetical and the actual you can watch a bunch of youtube videos about someone giving good advice that doesn't mean you give good advice you may be tempted to describe some villains in your story since hey you're the hero right don't do it if you describe too much of a bad guy the interviewer may conclude that you were the actual villain keep it professional and if there was some wrong done to you make sure you don't describe it as evil this is especially important if you're answering questions about working with a difficult co-worker finally when you conclude your story you want to make sure that you never describe a perfect success life is too messy for everybody to live happily ever after you want the ending on balance to be positive it really speaks to your perspective and adds realism if everything is wrapped up in too nice of a bow at the end suspicion about the story's authenticity is bound to creep in let's wrap up levels are relative at different companies map your experiences and work to your target company and by using sites like levels at fyi or glassdoor get a sense of what expectations are at each of their levels you can try to get a promotion with a move but it's in your best interest to come in at the right level when down leveling happens it's usually because of answers on behavioral portions of the interviews because if you did poorly on the tech parts they wouldn't extend an offer humans are narrative animals use the story shape that every human understands because levels are relative start by anchoring your story on your status and responsibilities on your team and the job description at your target company later on challenges commensurate with the type of problems people at this level are likely to encounter describe an imperfect but still positive success don't describe villains you star to make sure that your story has substance and isn't fluff but don't use it as a way to write your stories don't lie in an attempt to make yourself look better it's too much work to keep your story straight and you risk damaging your credibility it's better to spend your energy on being a badass rather than concocting a story about how much of a badass you are if you found this content helpful please hit the like button and consider subscribing i try to make videos that would have been helpful to a younger version of myself but i'm getting so old that i forget what that was like so leave a comment on what you'd like to see in upcoming videos you won't be a great storyteller immediately after watching this video but i think that once you start thinking in these terms you'll start seeing yourself as a character in a larger epic and your day-to-day actions as part of a broader narrative at times it may feel artificial devoid of authenticity but there's something innately human about the way we connect with others via stories thanks for watching [Music]