StreamSparkAI

speaker 1: We will say no to people, even if their coding and system design is good.
speaker 2: This guy was a principal engineer at Amazon. He conducted thousands of interviews while he was there. And last month, I went to his studio to ask him teach me everything he knows about interviewing in big tech. He also shared a ton of unexpected stories. Holson leads from his promotion to principal engineer at Amazon. How many people are expected to be cut in Amazon?
speaker 1: Typically, what I can say is the pips stands more performance improvement plan. And then what about the worst energy hub? Yeah, I don't want to name names or anything, but .
speaker 2: I know that you came from a liberal arts background. Your major going into college was actually English, right? Yeah, it was creative .
speaker 1: writing and English literature.
speaker 2: So can you tell us a little bit about you getting into Amazon without a cs major? Yeah.
speaker 1: I think just getting in as a liberal arts major may a bit disingenuous. Both of my parents were electrical engineers, and so I've always had a computer around the house, and I used to program that computer. I still remember my first one. It was an ibm xeight hundred 88 with 640k of ram, no hard disk, two 500 quarter inch floppy disk, so that it's a floppy disk that's actually floppy, not the hard one that you probably don't even remember. And so you know I've always been been coding and since a really Young age. In high school, I did the computer science ap tests. My sophomore year, I did the ab tewhich was in Pascal way back when Pascal is a programming language. And my junior year it was in C++. And I did the bc test. And so I knew about the concepts of big o algorithms and data structures, how to write programs. You know, I still remember making like a Tetris clone when I was in high school. So, you know, the fact that I broke in without a computer science degree, if you just said the part about the English degree, like I said, it's a bit disingenuous. And so I went to school. I got a liberal arts degree. I did get a minor in math and applied math, and I took some computer science courses. You know, when I got out of school, I was looking for work, and it was around 2005, 2006. I still remember the story. I went to and talked to my writing professor in one of my senior year seminars at uw, and I was like, professor Bosworth, if like, what type of job should I get? I want to be a writer. And he said he put his hand on my shoulder and he was like, Steve, there's no job called writer. It's like, not yet. There is a job called waiter. And so you just have to find a way to sort of support yourself while you apply your craft, right? And so just finding some sort of way to eke by while you get some experience under your belt. I wasn't really turned on by that. And so I decided to revisit these skills that I had picked up in high school.
speaker 2: And before that, I see. So I mean, to me then, it is disingenuous to say that as if you came from zero skill, but your resume came from zero, is my understanding right? Because if you look, if I was a big tech recruiter and I was looking through stacker resumes and English major comes along, you probably would not stand out when it comes to the job market. So what is the thing that you did that got you into Amazon? It was .
speaker 1: through networking. So somebody that I did ap computer science with worked at Amazon. He went to University of	Washington and got a proper computer science degree and was a software developer at Amazon. And so they needed some support engineers, and it was a contract position. And so I basically was like, can you get me an interview at the company? And I was just, I was not worried about a coding interview because of my prior experience, but also you know I think with support engineers there writing scripts and maintaining systems. And so I got through on that interview. And I was a Green badge contractor for about nine months before I transitioned a full time.
speaker 2: What's Green badge mean? Just temp. Yeah.
speaker 1: it's a temp. It's a Amazon term.
speaker 2: Yeah.
speaker 1: So the blue badge would be full time. And then Green badges, a contractor, yellow is like a vendor or got something .
speaker 2: like maybe today's environment is like a bit more intense where people want to get into big tech and Amazon's big name at this point. But also your resume, although it was not cs, the thing that got you in was that you knew someone and they gave you like a referral. And that made a big difference that at least got you the interview. And then you had the skills because you were you had been doing cs for a while.
speaker 1: Yeah. I think the way to think about it, if you know when when I guide people trying to get a job, it takes two things. It takes you know some amount of opportunity and it takes some amount of study. And so you don't know when the opportunity is going to pop up. You don't know if your Uncle Daniel from church you know will talk to somebody that knows about a job opening. You don't know when that's going to land. It's very unevenly distributed. Where do these opportunities come from? But I think over time, they will come and rear their heads or make themselves available. I think the other side of it is the preparedness, right? So up leveling yourself, gaining knowledge, gaining skills that needs to occur. You can't just have the opportunity and then not have the skills, right? And so those two things need to marry. And so you know, I think back then it was much more difficult to gain the knowledge that was necessary to get into big tech today. You know, you see all of these cottage industries around, interview prep, getting ready for the coding interview. None of that stuff existed when I was trying to get in. And so I think it would actually be harder back then to get your foot into the door and tech from a non traditional background than it is today. Now I won't say that it's necessarily easy today, but at least in my mind, I think it was more difficult for me.
speaker 2: Yeah I remember when we worked on that post together, you said there wasn't even the idea of like lists of leak code questions and things, and you were just collecting interview questions to prepare.
speaker 1: Yeah. So when I was a support engineer and like you know they made me blue badge, so full time employee, but I just, I wanted to be an sde so bad. And so all I for the audiences.
speaker 2: software development engineer.
speaker 1: And so I wanted to be a software developer so bad, I just cornered everybody. I just became a collector of questions. I was like, what do you ask during interviews? And I was like, don't tell me the answer. I'm going go and figure it out. And so, you know, just did it the old fashioned way, just firing up an ide and you know you don't have all these battery of test cases that get run like you know with leak code and stuff now. And so you know generating your own test cases, you know that's that's a way to sort of uplevel yourself. So I feel like I did it in a just in a time where you know we weren't so resource rich.
speaker 2: So I imagine that probably lowered the average performance of an interview. We and maybe because you had some extraordinary process of like collecting questions that you might have been like you know very outstanding when it comes to everyone because ultimately, interview prep is a little bit competitive. You need to be better than the .
speaker 1: other people to get in. Yes and no. I think of the distribution of demand for software developers is skewed. I just especially today, I don't think there's a ton of demand for junior folks. I think there's a extraordinary amount of demand for senior and above. The reality is that seniors come from mid level in juniors. And so I think the pipeline is a bit busted right now. I don't necessarily think of a ton of competition at the upper end. I do think that there is a lot at the lower end, but the competition doesn't exist at the interview stage. I think the competition exists at the pre qualification and selection phase. And so if you're able to catch the attention of a recruiter, say you know somebody that works at the company or you're able to go really deep in a particular area and stand out, maybe you built an app, has some amount of customers, that's where the competition is. Like you need to stand out on the selection side by the time you get to the interview. Like it's just a matter of clearing the bar there. And so the dimension of competition is not at .
speaker 2: the coding level. I don't think why do you think that most interview prep advice is garbage?
speaker 1: I think that most interview prep is non optimal. And so you know there's there's a hyper focus on the coding interview. There's a hyper focus now on system design. But I think really people forget. So they they turn it into a test. And in some sense, it is. If you can't code, then they know they won't want you. If you can't design a system and you're a senior, like you know it's not gonna to work out. Like if we put you in a role, it's nice you're going to be that 5% that leave, right? We don't want to do that. And so the big overarching framework is the people on the other side of the table are trying to figure out whether they want to work with you, whether you're going to be a good fit for the culture. But people think about it in terms of a test. And so it's much more like a date than it is like at the sat, right? And but the prep industry, the interview prep industry, it's much easier to think about it and present it as a test, right? And so I wish people would just embed this. You know some things like, Hey, behavioral interviews have an outsized impact on whether they're gonna to hire you and what level you're gonna to come in at. So instead of say spending 80% of your time on coding or maybe let's say 60% on coding and then 35% on system design and like the 5% is like the donate to charity pie slice, like maybe it's much more like 40%, 40%, 20%, right? Because that behavioral side, I think, is really where the match is made, where and where behavioral .
speaker 2: is the 20%. I was a bar razor trainer.
speaker 1: and I trained thousands of people at Amazon on how to conduct interviews, assess talent and then level people. Before the training was, you know, now it's a set of videos, but it used to be live training. So I trained many people on his. And what I used to say, and I'll say it right now is so the functional parts of the interview, the coding interview, the system design interview, those things are the ante, right? So they're are the small blind and big blind. So I'll use a poker analogy that are the small blind and big blind of getting into a company. And the behavioral part of the interview, that's the poker part of poker, right? That's like, do you have a good hand you know trying to beat the other hand of the other person? And so if you thought about the coding part and the system design part as necessary but not sufficient, like that's the thing that I wish people understood, right? We will say no to people that have poor behavioral answers. Poor, not in the sense that they don't have the experience that it needs is just we can recognize from far away that it's not going to be a good fit for the company. We'll say no to .
speaker 2: those people even if their coding and system design is good. You're saying at Amazon, it's like the functional parts like coding system that's like PaaS no, PaaS, yes. But once you PaaS it, your leveling and the I guess the color behind how good you are is the behavioral yes, I see. Okay. So then what should people do to kind of prevent from being down leveled because their behavioral is bad?
speaker 1: I think that they should spend some time on what I call packaging. So if you can package your experience and sort of communicate that packaging to your interviewer, I think that's just optimal for both sides, right? So you are packaging your experience. You're communicating to them what you're all about, how you operate, what things you've done in the past. And you can make that a good story. You can not it doesn't have to be entertaining, but it can be efficient. And you can, you know, if you are able to effectively articulate yourself and communicate it to your interviewer. I think now we're talking about empathy. Now we're talking about things like, this is the fundamental question for interviews is like, do I want na work with this person? That's the question that this whole song and dance for the interview process is trying to figure out, do I want to work with this person or not? And I think spending some time on the behavioral side is about trying to help the interviewer answer that question. So you are just, you're really trying to act like yourself and not, you know, it's not necessarily you want to put your best foot forward. You don't want to lie. Obviously, you don't want to misrepresent yourself. But I really think that you know, just being able to talk about who you are, what you're about and your experience, like that's the important part. That's the missing part from all of this cottage like interview prep that's going on on the Internet. That's the big thing that's missing.
speaker 2: Could you give me an example of packaging? Like what maybe you could package your as if you were going to sell yourself back and go back to tech?
speaker 1: Yeah. You know, so just even something like tell me about yourself, right? I think people kind of gloss over that and they kind of run on sentence their way through it. And you know I think if I were to answer your question like that, it would just be like, Hey, you know my name is Steve Quynn. I you know I have a passion for back end distributed systems. I really love to work on customer facing products. I'm a sports fan. You know I used to work at Amazon tickets and prime video sports. You know I really love like building teams and really know taking an organization's engineering culture and up leveling it at that level. Like those those are some of my passions, right? I didn't prep for that. That was kind of an interview off the cuff. But you know hopefully you got a sense of you know who I am and what I'm about and the level that I operate. One thing that I like to say is that the stories you tell, they sort of betray your level. The way that you communicate with people, they betray your level, right? And so if you have stories that are sde one stories, right, entry level stories, but you're trying to get a senior role, that that incongruity is the thing that's going to lead to the down .
speaker 2: leveling. Yeah, that makes sense. Like the last thing that you said there was up leveling teams. You're almost speaking to like a like a staff or hirubric where you know it's not like you said, Oh, I like to clean .
speaker 1: up the code or Yeah, I love refactoring code. It's like, I do. Yeah, but that's not how I'm going to describe myself. Yeah, right. And so I'm trying to turn this into a video of some sort, but I want to do a thing where I just talk with somebody for five minutes and I try to figure out whether they're senior or mid or staff or whatever they are.
speaker 2: Oh, that be interesting.
speaker 1: Like applying Yeah, Yeah. Like you don't know and you just Yeah and maybe I'm you know, maybe I'm overconfident, but I just I feel like if I talk to a junior entry level person, I would know that they're a junior entry level person. They just they just just the way that they Carry themselves, the things that they talk about you know now maybe on the you know if they're a strong senior engineer, you know are they going to be able to PaaS as a principal? Yeah, there's some there's some places where I you know I might struggle, but I think I'm really calibrated in .
speaker 2: terms of level. So that's for the interview stage. What about before you get the interview? Right now, it's a really competitive job market.
speaker 1: Do you have any advice for people to stand out? You have to be an outlier in some regard. And so being an outlier may mean, Oh, I have a contact that can give me a referral to a big tech company. I think that if you just if you cold dmmed some folks on a team that had an opening and it was, you know, you didn't like spam them, it didn't look like like an autodm sort of thing or a script. You didn't sound like AI, and you were just like, Hey, my name' S Ryan. I noticed you work on this team and you have some openings. Like, can you tell me what it's like on your team? Like what are the sort of things that you do on a day to day basis? And then also, you know, I'm a University student. I'm about to graduate in three months. Like how can I position myself optimally in order to get this job? I ran a poll on my discord and 90% of people said that if somebody did that and they were genuine about it, that they would interact with him and that they would actually extend a referral if they asked, right? And so that's an easy way to be an outlier in networking. You know I think about a lot. You know there's this networking stuff where it's just like, Hey, you know strengthen your your networking, go up and talk to people. There's this and it's American style too. So it's like everybody thinks it's fake and surface level, but that's not what I'm talking about, right? Like you should do those things, but like really like networking is about making some sort of connection. And so if you're able to connect with people, they're in a spot to help you if you can provide value to them, right? I think that's one way to be an outlier. I think if you're if you're new and you're willing to pick up skills, Hey, what's the skill that I should pick up so that I'm much more attractive to big tech or to getting a job? I think that most people should go deep instead of going broad. You know, theybe like, Oh, I'm gonna na, you know I'm doing a react tutorial and I'm gonna to learn rusts. And then there's a machine learning Python thing with PyTorch, and they go breadth and there's no cohesion there. It's like mobile app development and machine learning Yeah you can make them sort of you know connect to each other, but in some sense, it's contrived and there's just so much to learn. And so I give the general guidance. It's just like, okay, well, what's the thing that interests you in a framework or a language that you are you know like you already know? Like how deep can you go in a particular, you know, in a thing that you already have some familiarity with?
speaker 2: 2025? Is there a top programming language that yourecommend for someone to go deep in?
speaker 1: The cheeky answer is, English is the top programming language in 2025. What do you mean by that? We had talked about it a little bit before, but the ability to communicate yourself, the ability to package your experience and tell a good story, I think that's the thing. That's that's the high leverage activity in terms of languages. You know, dude, I've been I've been programming. You know I've done assembly in basic in Pascal and c and c plus like I learned c in 1990, right? Like languages are they come and they go. Like I consider myself a Pearl expert like that that's no longer useful, right? And so like the language itself, I think in a sense is immaterial. I think this is where I think you know your personal curiosity. Like it's totally fine to pick up something that you know you have an affinity towards. I think it's also totally fine to be like, Hey, look at all of these jobs in Java. I don't think Java is going away, or at least jvm based languages. And so I think it's totally okay to be like, well, I'm going to become an expert in Java. That's not very sexy right now but that's a totally fine reason. So however you get there, my advice is just just go deep, right? People will be like, okay, cool. Well I'm gonna to do a Java tutorial and then I think an example of going deep is just being like, Oh, what's going on in this virtual machine? What are virtual machines, right? It what does it mean to tune a garbage collector? Now we can get into a debate about whether you're gonna to shoot yourself in the foot with you know trying to tweak your Java garbage collection. But if you are willing to pop the hood on that and then sort of like take a look at what's going on in there, that's the sort of thing that nobody can stop you, right? Like you can just try to go deep. Steve said to go deep. So I'm going as deep as I can till you get to the ones in the zeros that are flowing through on that bus.
speaker 2: right? Like that is the thing that is rare. Last thing on this topic of you know breaking in recently, Zach, he had this quote. He said on an interview that the capabilities of AI in this year will be able to produce mid level engineer code already. Do you think that junior engineers are screwed then because of that?
speaker 1: I think it's super interesting. Maybe you should tell me you're the one that works at meta, right? But I'll say this, folks, at the CEO level, you know they're very high performing. Their job is to look into the future, but they tend to make predictions that are they're not exaggerated, but they tend to make things like the timeline for which things happen. They tend to undershoot that and then they tend to overshoot inability. But the idea is that the vision exists and you work towards it. The fact that he says he equivocates or at least he's hedging, he's saying mid level engineers later this year. If that was actually already there, he would have said senior staff level engineers or ten x engineers by tomorrow. The fact that he's pushing that out makes me think that the actual implement, like the rollout of a mid level AI bot within meta is a little it's a little further away because his job is to move the goalposts just a little further than where we're at. And so I have a little bit of doubt there. Now if you want to talk about you know AI taking over some tasks, yes, absolutely they should. You know I think when I was coming up as a mid and senior Oh, code generation, look at these annotations. We can put lomboach in our code. You don't have to write getters and setters. There were there was, you know, I have a lot of familiarity with Java. Java is a very verbose language. Oh, look, the ide can help me refactor some code. The ide can write some boilerplate for me. Yes, absolutely. We should be leveraging tools to make us more efficient. But at this point, I think of AI help as an amplifier. If you just go through the different levels, if you're a non coder, I think that you can go from zero to one very easily, right? So we're getting to the point with products like replet, where a non coder could conceivably become a product manager and build like a mobile app, soup to nuts from beginning to end. But I have my doubts that if the app doesn't work exactly the way that it's intended or they're like, Hey, scale this thing to meta scale. Like I don't think an AI is gonna to be able to do that. So I think very comfortably we'll be able to go from zero to one, but I don't think that it will go from like one to many. And I think a one x engineer is going to definitely turn into a ten x engineer today with the help of AI. But do I see a zero to ten x engineer jump like later this year?
speaker 2: I don't see it. Ok. So then I guess moving into you being at Amazon, you went you went into Amazon, you converted to an sd, then you climbed all the way to prinple at Amazon, which I know that last jump is also very notoriously difficult. So you went from sd one to sd two, sd three. And then principal, could you walk me through the high level? Maybe just tell me, you know what was the main thing that made the difference at each level and you know just like a very concise high level.
speaker 1: Yeah Yeah I was able to get you know to from support engineer sd one, 23 around 33 and a half years something like that. You know at sone, I think it's the real focus is on some amount of independence. So just understanding where you fit inside of the software development life cycle, getting to the point where you can take tasks and see them all the way through. So you've gained a little bit of trust there and you don't have to be handheld. I think that's the critical piece for junior level or sd one. I think I just want to add a caveat there, which is that doesn't mean you know everything and that doesn't mean that you don't ask questions. It's just that you're much more comfortable asking a question if you're stuck, you're much more comfortable surfacing an issue. There's are some folks that have this idea that at sd one or at any level that you are completely self contained. So self contained is not the same thing as being independent.
speaker 2: One of the common words I hear for that first promo is like doing things independently without guidance. Some people interpret that as, I'm not going to ask for help and I got to do it all myself, which is obviously not right. But you need to know how to unblock yourself.
speaker 1: So make sense. And it's also insidious in the sense that it's it's not just not right so that it will hold you back for longer, but actually turns into a performance issue if you're hiding the fact that you're you not able to perform or you don't know anything, if you're hiding progress because you're unsure about yourself and you sort of beat yourself up that you should know this thing and you know suppose you have a task and it should take two weeks and then you're like, Hey, everything's on track, everything's on track. And then the Thursday before you're like, I've been blocked this whole time. That's a performance issue, right? And so you know there's there's a difference between, Oh, it's just gonna na take you longer to get there to something that's actually detrimental to get to the next level. I think for sd two, the word that pops into my head the most is ownership. And so know you are an active participant in the software development life cycle. You're much more of a steward of, say, your team's code base. And I just sort of think about it like, you know, Hey, you're littering, don't litter here. Like and then maybe picking up some of the trash, that trash being tech debt, not actual trash in the code. You know, being able to get you know now you're able to leverage this independence and to start to make a contribution to the teams 's code base that's a little bit larger, right? So basically, every step up with sde is kind of an argument that you deserve more scope. And so the scope of an sde two or midlevel engineer is, you know, at the team level, right? You understand your team's code base. You know, you understand its weaknesses, its strengths. You can start to, you know make suggestions about where it's going to be. At Amazon, we have an operational culture and so you're on call. You know how things break. You might have some ideas about how to fix some of these things. So it's a very meat and potatoes sort of roll. And this is what .
speaker 2: you need to go from. Two, two, three. Yeah, I'm just talking about two.
speaker 1: Oh, this is table stakes for you. I think it's expectations for at least this is my conception, right? Right? And there's an eternal debate at Amazon about whether the St two or mid level role is a terminal position or not. Can you retire as an sde two? The level granularity at Amazon is such that I think stwo is a very wide band. So I think at the upper levels of sde two, a lot of those folks are senior engineers at other companies even within big tech, not just, you know Oh, they're a senior engineer at a smaller company or a startup. I think they're you're pretty strong as an sde two at Amazon just because the granularity for levels at Amazon is so terrible. And so I tend to bias towards like, Yeah, actually at sde two, that could be a terminal level right now. I don't advise that people think of it as a terminal level, but it's just a reflection of how much scope I think in sde two at Amazon can actually deliver against.
speaker 2: So there isn't an up and out policy. Like if you were a manager at Amazon and you had someone that says, Hey, I wanna just stay at you know sd two, is that okay? Or would they get fired in Amazon's culture eventually?
speaker 1: So and it might have changed. You know, it's been it's been close to a year since I've been gone. So I say we a lot as though I still work there, I'm still trying to train myself. I don't work at Amazon. So it's definitely up and out at sde one Yeah and so if you've been at sde one for more than two years, you know it's it's kind of like is there something needs to go formal like you know .
speaker 2: 24 months and then they start managing out or it's a feel thing. I believe it's it's a strong.
speaker 1: it's a progressively stronger guidance the longer that you've been there, but it's not a 20, 36 months and then you're out sort of thing. Yeah. Yeah. I think for sd two, it's a much more interesting conversation. I think that will depend on where the upper management you know for that particular individual, where they land on whether stwo is a terminal level or not. And so if you happen to get a manager that's basically like, no, you've been there for ten years, you should be a three. If you happen to to get that person, then I think it might be might be bad news for you.
speaker 2: And you know with the recent news about meta, a lot of people are likening or they're worried that meta would turn into Amazon because amaamazon's famous for a culture of intense performance and cutting people who aren't making it. Yeah from your time at Amazon, I'm kind of curious. Maybe you can give us the the juicy details, like how many people are expected to be cut in Amazon typically, like because you were there for so many years? Is it you know some percentage per year, or is it up to the manager's discretion?
speaker 1: How does that work? What I can say, so I won't give an exact number. What I can say is that guidance, you know suppose it was five or 6% you know for an organization that that number used to be a recommendation. It would be kind of a soft one. Hey, we need to manage out x percent of folks over the course of a year. I think in the past couple of years, that has turned into a much more, it's turned from guidance to much more of a mandate. I think, coupled with the fact that up until recently they weren't doing backfilils for folks, there was this sort of like, Hey, keep on running because this thing's chasing you right from the back. I don't think that was necessarily healthy. And you know if I were, to be quite honest, I consider myself a high performer. And so if you're a high performer, you don't have to think about that stuff. And you know as much as I'd like to be empathetic about it, and you know I've been around some of these decisions and meetings and stuff like that, if you're down, it's hard for me to speak about what it's actually like to feel like your job may be at stake, right? And so you know I think a lot of what I would tell you is is just kind of cold and numbers based, but there are real people here, right? If you you know getting fired from a job is. You know that's that's a very, this a highly emotional, psychological thing, right? So I just want to make sure that I bring that up. Maybe I'll say this and this this is sort of how I guided other folks and other managers when they're asking me, Hey, do, how do I think about this? The way to think about it is 5%. Suppose that was the number, right? So that's one in 20 people, right? And so just take a population of 20 people, and I think there's a distribution there. And the people on the left hand side of that distribution in regular years where there are backfills, I think that I think that they're not having a good time with Amazon's culture, right? They're not thriving almost by definition, right? We're just going to say, Hey, everything on the left hand side is people aren't having a great time. And so I think it's almost a relief that there's a way to sort of like leave a situation like that. What's the alternative? They stay. And somebody that's not having a great time in Amazon's culture, which you know it doesn't have a great reputation, part of me is like, Oh, that's kind of nice that you know it's kind of a blessing in disguise, right, that we would move them out now without backfilils. That's where I start to get a little uncomfortable because in basically any other year that they would be at Amazon, they would be totally fine. And I think even people you know that are sort of left shifted, but in that main part of the distribution, I think they're great. And so that's where I start to go. Like this not this is not something that I really agree with.
speaker 2: You're saying because it starts to cannibalize people who are they're doing good, but now we're forced to .
speaker 1: drink people .
speaker 2: that were good. So suppose .
speaker 1: you had a 6% amount of folks that were let go, and that was a hard thing. And so you did all of the very tough work to identify those folks and have them move out. And now you need to do 6% of those folks that remain, and then you need to do 6% of those folks that remain. And so it's not 18%. You know, don't I can't do that math, but now we're starting to talk about people that are very close to the mid point. They're operating at a high level. And then any other year, theybe totally fine, but now they're not. And so, you know, I have colleagues that were let go recently, and this just kind of blows my mind that would they would be let go. And so I think the most amount of impact will come from folks that say middle management where, okay, well, there's four middle managers within the suorg right here. The bottom percent, 6% of going make sense when you're talking about four people or eight people, right? And so I was very surprised by some of the people that were let go recently.
speaker 2: So you said when in the past, I guess as a principal engineer, once you get higher up, you were privy to some of the conversations where people are being discussed, if they're getting managed out, what happens in those conversations? How does high level ic like you participate?
speaker 1: Yeah. You start getting pulled in when you're a senior engineer and you definitely get pulled in when you're l seven or above. Those meetings are terrible, right? They're like three days long and you're locked up in a room and you're just sitting there talking about people and people. You start to lose the humanity. You just start to think of them in terms of know the measurables right? And the feedback from other folks. I won't go into the specific process, but what I will say is it's not a linear algorithm. I think in a perfect world, you would just go through everybody in the org and then you would have equal amount of time to talk about them and their strengths and their weaknesses. Typically, you just talk about the edges, and that's not a reflection of you know the people that are making the decisions and whether that's poor or not. It's just it's the math. There are just too many people. And so the conversation tends to go to either side. And Yeah, it's it's just it's not my favorite time of year.
speaker 2: No, definitely. It sounds, especially if they cut out some low performers and then the next iteration is like people where you objectively look at them, go, Oh, they're solid, but we need to fork over some .
speaker 1: more people. Now, if you want na talk about meta, I think meta is on a hiring spree. I'm if I'm not mistaken, I think you know if if your fearless leader is saying, Hey, low performers are leaving, and let's say at a five Percent Number, I think that's the number that's been floated around. I just have a sense that those folks are probably not having a good time at meadow right now, right? Is that everybody? No. But I would say that the vast majority of folks there, if you're talking about one in 20 people, 20 random people at meta, there's probably somebody that's struggling, especially when you start multiplying that out across a large population. So because the inflow is much larger than the outflow.
speaker 2: I wouldn't be too worried. Sounds like across big tech, there's this increased intensity. And historically, Amazon has been the one that's always had this level of increased intensity or at least this process of like let's manage out the low performers quickly and let's just factor that into our processes. Given that you've been in a lot of those performance conversations, do you have any advice for the people who are on the border where you know if this is a how we're going to be operating in the future, people who are kind of just meeting expectations, what is the things that protects you in those conversations that they could do for this coming year to be safe?
speaker 1: I think it's just that if you meet expectations, if you solidly meet expectations, if everybody across the organization met expectations, I don't think you have a 5% stack ranking like removing folks from the system, right? And so you know I don't think that people that are I bristle a bit at the low performer label. I just I just again, I think of it as like the culture is not working out. There is a mismatch between me and the ambient environment at any particular company. I don't think it's a low performform. You know how hard it is to get an offer at meta? Like you are not a low performer. Yeah, right. You you have to be driven. There is a song in dance that you need to that you need to perform under pressure in front of somebody. Like you go and take a Lee code hard and you have to go look at some, you know, you have to code it in front of some sde that's like got a bad expression on their face. Like you are more than qualified, your smart as hell. And now you're working at a company and maybe you thought it was something different than what it actually was. What I would say is I don't think these low performers, these so called low performers, they should try to become high performers, right? I think by focusing on trying to be a high performer or focusing on trying to get to the next level, there's usually a reason why you're considered, you're labeled that way. And so try to figure out what is that dimension that you're being judged and measured against that's holding you back for meeting expectations, because I think you need to crawl before you walk, before you run. What is that thing that they're judging you on? And then I think you should be real with your manager and you should say, Hey, I just wanted to check in and my meeting expectations. And if I'm not, then like let's do a preemptive plan, right? So pip Stanmore performance improvement plan, can you do a pre pip? Can you proactively put together a plan to get you to a spot where you're going to be safe? I that's what I would recommend. Just be proactive about growth to get back to the median.
speaker 2: Asking a manager for a proactive.
speaker 1: I would maybe not use those words.
speaker 2: It's hilarious. Okay, so it sounds like I mean, obviously meet expectations.
speaker 1: work with your manager. Well, I don't think it's obvious. I don't I actually, if you if you took a survey of software developers and you asked them, have you used these words with your manager? Suppose you're my manager. Hey, Ryan, you know I just started here at meta. I just wanted to get a sense of what your expectations of me. What are those? Have you explicitly asked about expectations with your manager? I think like 25% of people have actually done that. I think most people are trying to guess at what those expectations are. And so I think that would be my first bit of advice is just like straight up ask what expectations are and then ask if you're meeting them or not, right?
speaker 2: That would go so far, definitely. Yeah, that makes a lot of sense. I think most people, all right, I don't know if it's being shy or what, but I feel like most isdon't directly talk to their manager and say, I want this or you know how do I meet expectations? How do I get promoted? Kind of just do the work and do it well and hopefully things go go well. Well.
speaker 1: obviously there's going to be an answer. Yeah. And so it's like, Hey, Ryan, Ryan, what's your expectation of me and am I meeting it? It's like, no, Steve, you are not meeting expectations and it's starting to become a problem. Even that is a better situation than not knowing. Oh Yeah, for sure. Right? And so there's a mutual friend of ours, Rahul Pandy from tarot. Yeah, Yeah I stole this saying from him and I don't know if he stole it from somebody else at worked at meta, but it's basically like bad news that's delivered early is just news, right? Bad news that's delivered late is terrible news. Yeah. So you know so if you are asking about expectations and it's early in your career, it's early in cycle, you know and they're like, Hey, this is a problem. Well, now you surface the issue and you have a fighting chance of actually addressing it if you are like, Hey, what's up with my expectations? Oh, it's really bad. And it's December, right? So the month's preceding performance review you over, you're not in a good spot. Yeah, right. And so I just encourage people to deliver. Try to find as much bad news as early as possible .
speaker 2: for your principal promo. I think a lot of it comes down to having the opportunity and then delivering. But it's interesting to dig into how you got the opportunity to even deliver on principal scope. So kind of curious, can you tell the story .
speaker 1: about how you got that? So I was reorback into prime video. And so the previous team to that was a team that I cared deeply about. It was called Amazon tickets. We sold. Tickets like tickemaster built a bunch of really awesome tech, filed a ton of patents, I love music. I love going to live shows. And so I was like, Oh, this is great. They spun that business down and they Reorg that whole team into prime video. And basically the 30 or 40 devs that were in that organization, they kind of just scattered into the wind, right? And I was, I had a bad taste in my mouth. And so I was and I didn't want na talk to any other teams. So I was basically like, okay, well, what do I have here? What they had was a team that was focused on delivering live sports on the prime video platform. And I'm a big sports fan as well. And so I was like, okay, well, this is interesting. And then I looked around and I was like, Oh, there's a bunch of principal engineers here. Okay, so cool. I can learn about what's going on there. And there was this really big need that was there, the catalog work. And you know, I just made a decision about whether I wanted to pick it up or not, right? And I decided to, it was just, in reality, much larger than any other project that I had ever done. I wouldn't say it landed on my lap. It was a combination of staying and then sort of saying, okay, well, if I stay, I need to do this.
speaker 2: I see. So it's some scope that principal engineers were aware of, needed to be done was particularly difficult. It was it was just sitting there for someone to take it on. You took the initiative, say, all right, I'm going to take it and stay on this team.
speaker 1: And then you delivered on it. Yeah, it's you know the way that the principles were organized back then. It's changed now. But essentially the principals were assigned to different areas, say like playback or clients or catalog or wherever they were. And the work that needs to be done was in the gaps between those orgs. So it had to be an end to end solution. And so even though the ththe main thrust of the work was in these sort of centralized services, and so that's why you know nobody none of the other principles had done it because they were kind of they were doing all of this other stuff that was necessary for us to deliver.
speaker 2: Okay. So that that makes a lot of sense too, because I imagine also if you delivered on that, so each principle to each, I guess, central vertical and you're delivering some glue work. If you did that job really well, not only is the scope huge, but also these principal engineers are you know they're going to have context on your work and speak to your packet and be champions for you. So I'm sure that was helpful too. A lot of people, they say getting to principal Amazon is so difficult, people don't even recommend doing it. You know there's all this job hop advice. So what is the thing that usually blocks people from going from senior to principal .
speaker 1: at Amazon? There's a lot of reasons. I think just to back up a little bit, I am of the impression that Amazon just skipped the level, so they should just insert a staff level. They could do that right now. Basically they would say, okay, well everybody, this principal will call you principals, shove staff in there and then just say, Hey, for you know for the really high performing sde three s, we're just gonna to move you there preemptively. And that would be so great. But I think the big problem is that you're essentially jumping two levels for that particular promotion. And so the big thing that's holding them back is that you need to jump two levels, right? So there's basically double the amount of criteria to get to that next level. And I think it's kind of impossible to exhibit all of the moving two criteria for principal in a year. So if you think you're ready, Hey, I'm a senior engineer. I've been doing really well. I'm gonna na make a big push. I think it's like it's because the job is so different, because now you're influencing multiple teams, it's very difficult to find the opportunity and then also be able to perform at a level where people would consider you for the next level, twelve, 18 months. And so what ends up happening for you know the failure mode that I see the most is they think they're ready. They will make a push, they will get a rejection, and they will get some amount of feedback. And then what theydo is theyjust go back to their strengths and then theycontinue to work on their, they might, like address one or two of these pieces of feedback, but it just takes so long to close one of these cycles. And so a lot of people give up. I know so many folks that, you know, went to meta and thrior. They went to Google. Absolutely thriving right now. Senior staff, ea you know principal at Google, which is you know two levels past staff and one level above senior staff. They're doing awesome. It just couldn't make that jump right from sde three to principal. And so it turns into this thing where I think there's this two year sliding window of where you kind of have to pack in basically a new job. You have to basically be doing two jobs because there's an anti pattern where you just stop doing all of the things that you need to do for sde three and you just focus on the principal level stuff and then performance review time comes around and then they're like, you're actually low performance at sde three, even though you're a high performer doing principal level things.
speaker 2: How 's is that possible? Like what are those two jobs and how they so different?
speaker 1: Well, the reason it's possible is because performance and promotion are decoupled two different processes.
speaker 2: What's the performance process?
speaker 1: Amazon performance process is yearly and then know every six months there's a smaller version of that. And then the promotion process is depends on the level. So it could be quarterly or it could be every six months. So they might line up generally. But the idea is that there's not a dependency on one with the other. And so if you're trying to make a big push for promotion and you're doing all this prinple stuff and then you know then it's so here's here's a big example. Senior engineers need to code, right? That's a very important thing that they do. And principals are also expected to code, but not as large of a contribution generally, like direct contribution is not rare, but it just that needs to be balanced with their other obligations. So they might be a sponsor of a project or they might be acting as a backstop, or they might be acting as a catalyst or an evangelist or a particular initiative. And so you know those roles, they are pan team, right? So it's cross functional teams. There might be product teams. There might be five Dev teams. These Dev teams maybe be spanning multiple organizations. You might act like a tpm. I was accused of that in one of my promotion assessments. It's kind of hard to figure out whether Steve's an sde or a tpm kind of took events se to that. I'm like, are you kidding me, dude? And and you know one of them came back like, Hey, you need to code more. And I'm like, I have checked in so many lines of code. And so, okay, well, had there's some sporadic you know six months where I didn't code a lot. It's like I didn't get any credit for time served.
speaker 2: I see. Okay. So they looked at the code delivered in those six months when you're were going for principle. They looked at it, not a lot of code. And so they said, okay, we're blocking you because you're not doing the senior job. Yeah but principle was good because you were doing all the cross functional.
speaker 1: Yeah. And so then it so then it's like, okay, well, now I'll go code, right? And theybe like, Oh, it's been you know, it's been a long time since he's been on call. He's not in the day to day operations for an individual team. It's like I've bit I was there for 18 years. I have been on call longer than like time on call longer than most people's careers at Amazon by far. I've probably been on call like four years contiguously. And so you get feedback like that and you're just like this. Like I'm battling the process now, right? And so to be quite honest, I was promoted in 2020 and I thought I was ready at 2016. So you know I was promoted to senior in 2012. So it took eight years to get there.
speaker 2: I thought I was there in 2016, four years. And you went for promo every year and they gave you like .
speaker 1: this tpm feedback or other. Yeah, there was there were a number of obstacles, but you know they changed the process three times during that four year span. I just to be honest, I probably hadn't generated enough evidence that I was operating at that level. That's not to say that I didn't have the ability, but you need to generate this tangible evidence that goes into your packet. So I wasn't quite there yet. You need the support of your manager. And so there was a number of reasons why I wasn't able to get there, but a lot of it was just battling the process itself. I don't think I necessarily up leveled myself. I think I just became an expert in the process of getting promoted.
speaker 2: And so what did you learn from becoming an expert of that promo process for senior two?
speaker 1: Yeah. You know, I think about it. And is that a useful skill? Yeah, I think so. I think it's useful for people that are in Amazon. I learned a couple of things. So the big ones are don't wait to start. I think a lot of people postpone themselves. And so they're like, Oh well, after this big project lands, that's when I'll get my packet together. But the project landing may not be the thing that you would be rejected for. And so I'm a big proponent of being kind of impatient and putting your packet in early and then getting that actual feedback about where the gaps are. So that's one failure pattern. I think the other is you know you do get some amount of credit for strengin your promo packet. And so suppose your strengths are you know he's a great communicator, very data driven. He does a lot of you know he's a strength. There's a strength with interviewing. Great coder, cool feedback. Oh well, he's not scaling through others. He could be a better mentor. He doesn't communicate upward very well to directors or vps. So let's work on that. You don't really have to put so much emphasis on the strengths, just make sure that they don't regress and turn into problems. But I think you can just focus on the delta because that's what the promo panel is gonna to do when you're you know we try to make the promo packet sticky to a particular set of individuals. And so it's like, okay, well, Ryan you know rejected, you get the big red staampers thing on a piece of paper and you know six months later, it's like, Oh, Ryan, he's not promoted yet, okay. Like let's dig in again with humans, just like the talent review process, you're going to look at the delta, you're going to look at the outliers, right? And so you're going to be like, okay, well, what changed, right? And just like let's look at the the evidence that's there. And so if you're able to really focus in on the areas for growth, the places where there aren't as many data points, then I think you'll be pretty successful when you get that packet back.
speaker 2: You're saying there's the strengths and then there's things that blocked it in. You're saying strengths, they're good. Don't you don't need to worry about those. Just focus on the .
speaker 1: weaknesses and closing those gaps. I would just say prioritize Yeah the weaknesses and gaps and you just, I think about it like you're in a kitchen with a lot of pots and pans everywhere. It's like your strengths, you can put that on the back burner, right? But you know this this risotto, like you're gonna sit here and make sure that the risotto is good, right? It's like it's like you're adding broth. You just can't.
speaker 2: you have to make sure that you got that right. And so you said you were at Amazon for 18 years. Amazon's culture is very specific. They have the leadership principles. It's its own Yeah culture. What's your favorite parts of Amazon culture? And then we'll also talk about the worst parts too.
speaker 1: the worst parts in it. You know I think there's some amount of Stockholm syndrome for me being there for so long. I'm drinking the cool laid. You know I still say I we .
speaker 2: even though it's been a .
speaker 1: while since I were, what's your favorite cool Lathen? Well, I just the big thing is customer obsession. Yeah. I think especially when Bezos was there, nobody ever gave lip service to the customer experience that was the highest priority from interns to vps. You were always going to be doing the right thing if you had the customer in mind. Absolutely. 100%. And I just, I think that's a great north start. And so you know I think you chase profits or you focus on competitors or you know there's a lot of other trappings that are there, you might optimize for the wrong thing, right? If you optimize for short term next quarter profits, it's going to bite you in the long run. If you optimize for you know if you're just sort of chasing, that's another problem, right? And so if you if you actually work backward from the customer, you know Jeff Bezos has that saying they're like, Hey, long term profits and and customers, those are the same thing. There's no difference there. I think that's wonderful. Another thing that I absolutely I think is a superpower for Amazon is their writing culture. You know I think the ability to write a six page doc that was accelerated by the fact that I have a writing degree. And so I didn't realize that I had the precursor to a superpower when I joined. I was worried about learning Java, or learning how to deploy to prod man. I wish people would have a college class to figure out how to like send an email or to be clear about like the work that's in front of them. And so what comes with a wonderful writing culture as a wonderful reading culture? Like we literally will spend the first 30 minutes of a meeting reading the document and then we will have a discussion afterwards. There's no, this never works. It's like, Oh, I sent you the document. So after you've read the document, we're all going to get in there. No, nobody does that, right? Like they should. It's like a best intention sort of thing, right? But the fact that you're forced to read it at the same time and everybody is just sort of fast forwarded to the same place and then you can have a discussion like that's actually super powerful.
speaker 2: So if someone was onboarding to Amazon, they really want na make sure they hit the ground running and plug into the culture. Would you say that's one of the most .
speaker 1: important things? Yeah. They if they are curious about how we know we're doing right by the customer, Yeah, I think that's if you have a curiosity about that, do you will do really well the writing culture. I think that's just the medium by which we express our ideas. That's learnable. That's something that I wouldn't necessarily focus on. Before you joined, you said you're .
speaker 2: drinking the cool labut. There's got to be something that you don't like about Amazon culture. What would be the number one thing?
speaker 1: I don't mind. What's that?
speaker 2: I remember this was like a joke among my friends and I Amazon. There's no leadership principles, right? And a list of eleven or twelve things that Yeah everyone's kind of basing everything off of. And there's one there that was just like the recurring inside joke among our friend group, which was frugality. Basically, anything, anytime something was crappy or cheap or whatever, we would just say, Oh, frugality. So you know no free food. No, there were some other things to like. A hardware wasn't particularly good or .
speaker 1: Yeah you know I think free food, that's a perk if a company doesn't provide you food like that doesn't mean it's a bad company. So it's great on the upside, but I don't think there's it says very much on the other side. I do think you know frugality, we have a term called being frupid where you are so frugal that it's kind of stupid. I had to beg, borrow and plead for hardware. Like I'm trying trying to get a MacBook pro with like some ram so that it doesn't like the fan doesn't overheat when I'm running, like building my code. It's like if you're going to hire you know tens of thousands of software developers, you won't like get them a computer that works. Now, I'm not saying like I need the top of the line thing. I just I just need a, I'm a software developer. Give me, you know, give me a computer that works. You know, when intern season would come and then the interns would leave and then the vultures would come to try to steal the monitors, right? And so it's just like you know, it just it just reminds me like Oliver Twist, like you know it's like more please, it's like you just want a little bit more gruel.
speaker 2: Yeah. One thing that I wanted to dig into, and I guess this is switching to another topic, is in your time at Amazon, you had 17 managers over 18 years. So you've seen a lot when it comes to managers. What was it that made your best manager the best manager out of 17? I think I had .
speaker 1: more than 17 managers actually, really? Yeah, okay. I think it was in the 20s. Last time I tracked, I took a screenshot of my phone tool. You know I think a lot about this. You know sometimes people would complain about a mico manager, but there's a class of of folks that kind of like a micromanager, like they kind of need to be led. They kind of need things broken down for them. I do think that a lot of what makes a good manager is personal. The ones that I resonated with, they tended to be principles based, right? So not just the leadership principle stuff, but like the way that they operated, they sort of reasoned through. You think of these principles as axioms, and so you fix certain things, and those things have implications. And so the best managers, I think they fix customer obsession. They fixed things that I value, like sort of thinking ahead in the future. So they were maybe willing to entertain some you know some stuff that in the short term, like a hack, but it was always within the context of like what should we do? What's the right thing to do in the future? Okay. So like let's made a trade off for that instead of you know maybe some managers that I didn't like are folks that are maybe two delivery oriented, right? So it's just a constant death March. It's about delivery. It's about near term delivery. So folks that kind of thought it a little bit ahead in the future and were maybe not so constrained by what we had in front of us.
speaker 2: I see. And then what about the worst energy you had out of 20 something managers?
speaker 1: Yeah, I don't want na name names or anything, but you know sometimes they think about, how did we get here, right? And so like we live in a moment right now. And so I'm talking to you. And so I can see it. You know a year ago he was here, and a year before that he was here. And like I can kind of see the progression of how you get from you know maybe a University student at ucla to where you are right now. Like that progression makes sense. I think some people that I worked with, you're like, how did you get here? Like it's it's sort of like the Silicon Valley thing. If we get the name of the guy that Yeah, Yeah it had to have been some sort of big head scenario where you know he fell up, right? Luck happened and everything just sort of landed in their lap. So you know, I think the worst managers I had would be a combination of like, not my style, right? So again, you know micrmanager, one person is a really caring and engaged manager to another person. And then just a little bit of like wtf, like how did you get here? I thought that the whole performance and promotion process and the hiring process was supposed to filter a certain set of folks out.
speaker 2: And here we are at the end of each interview, I like to go over just general reflections of people kind of looking over the career, what are the things that you learned and various other things. One thing that I'm curious about, because you were at Amazon for 18 years, and in this industry that is extraordinary, people already call me fossil for being at veta for greater than four or five years. So you know what kept you at Amazon so long?
speaker 1: I think that you know we had talked about the number of managers that I had reported to. I had many careers, many, many careers at Amazon, right? So I worked on the first kindle and I worked on the precursor to prime video before I went back to prime video and I worked on in payments. So you know, I think the fact that Amazon does so many different things has allowed me to work on a variety of different things. You know, didn't feel like I've been on one team. It's not like I worked in the accounting department for 25 years and they handed me a gold watch, right? And so you know there's a vp, and I think he's still a vp in advertising. Paul Cotis, he told me one day, he said, I've never switched teams. Wow, right? Like Amazon just kind of you know refactored itself around him until he was vp of ads, right? And so great guy. And so you know I don't think it's to that extreme, but you know I had a wide variety of experiences there. And so it doesn't feel like 1:18 year contiguous sort of experience. So it sounds .
speaker 2: like you were still challenged learning. I think when I was at Amazon for my short stint, it was difficult for me to not have wandering eyes because there were these other hot companies, recruiters who were messaging me. And you know, I was just seeing that, Oh, maybe I can get more somewhere else.
speaker 1: Did you ever consider leaving Amazon? Yeah, Yeah, absolutely. I think, you know, especially early career, it makes a lot of sense to jump companies. You know, everybody hears the common advice is like, Hey, you want to maximize your total comp, you should be job hopping. I think that works until you get to the equivalent of senior. After that, I think you know you're an outlier here. But I think after that, it makes sense to put roots down the levels at the highest levels. I don't think you're going to find a lot of distinguished engineers or principal engineers or senior staff engineers that haven't been on the team like the jump, the thing that got them to that level. I think what you'll find is that you know there was like five years, you know at least like at least three, but more like five or so where they really stayed out in the same team on the same problem, right? And so you know I think if you want to min max it, what I would say is you know japop every two years till you get to mid, maybe a little bit before, and then go to you and then try to put roots down if you want to become a high level tech ic, see, for me, I think that because I was able to go to different teams and you know, because I don't have that computer science background, I think staying put made a ton of sense because I feel like I didn't there was so much to learn, right? You know, there so many, there was so much code that you had access to. There were all of these wiki, you know, these internal videos. And so I felt like I could still grow in the ways that I wanted to by staying at Amazon.
speaker 2: I remember even when I was at Amazon, the stock was climbing like crazy. Did you have any years where you were just super overcompensated? And if so, how much were you making in that year?
speaker 1: So here's the thing. I would, you know I was basically divesting and then putting money into other investments. And I wouldn't say that I missed a lot of like the Amazon's climb because a lot of it was sort of invested, right? I don't know. I think 2020 or something like that, I probably got like an extra 350k that I didn't deserve, you know just from the market returns and extra rsus that were given to me when I left. So 2024, you know on the vesting schedule that I was on, I would have made 750k, which is not a lot compared to like the upper end of the salary ranges, but quite a bit just sort of objectively as a number to make in the us at this point in time. I decided around I think 2018 or 2:19 to maybe like not divest my Amazon shares because it was always like you're dumb. Like you shouldn't put all of your eggs in one basket. But every time I sold stock, just if you just look at the stock price, it was just it was just the wrong move, right? And so I was like, I'm done, I'm done. I'm not gonna na keep every single little bit, but I'm gonna to keep some. And so that turned .
speaker 2: out to be okay. You said extra equity. Did does Amazon have a for high performers like a discretionary equity or additional equity?
speaker 1: Not that I know of. I think compensation is largely kind of like refreshers then Yeah, Yeah, it's at the discretion of managers. And so you know one of my one of my best managers, he was basically like Yolo, Yolo. He was like, I'm out. And so he hooked me up you know and left me go. But it's not like these insane like million dollar things that I ever got.
speaker 2: How big of a difference to that?
speaker 1: It was that 350 delta as Oh Yeah, it's just like that was four years or well, no, it was it was just sort of all at once. He just here's .
speaker 2: 350. Okay, that's pretty good. Yeah, Yeah, it was it was the equivalent .
speaker 1: of that was he was basically on his way out and he gave it to me and then he left and then that appreciated essentially the next year like immediately. So that's amazing. It wasn't it wasn't like here's he didn't write me a check. It was just a combination of the of sort of getting an outsized performance bonus and the stock price just doing really well. Okay. So over the .
speaker 2: course of your career, 18 years at Amazon, one thing that I'm curious is what was .
speaker 1: your biggest regret? Yeah, certain teams, I think just just reading the writing on the wall and making a sober decision about whether to stay or whether to leave, I think there is a lot of inertia. I think your default mode is to just stay put for some amount of time, and I don't know if that's useful.
speaker 2: The I guess the career regret is noticing when you're in a bad situation or a bad team and just taking the initiative to change that situation.
speaker 1: just leave. The regret is just did you make it a decision or not? Did you take in all of the considerations and then said, okay, I am going to continue to stay? It's the deferral of a decision. And so the default becomes just staying put. That's the regret is just like just turn it into an explicit decision.
speaker 2: And the last question I like to ask and ask everyone this question is if you could go back to you or you just graduated college, you're right about to enter the industry. You could tell yourself something, what would be the .
speaker 1: thing that you want to tell yourself? Maybe saying something around people pleasing, right, you know in the culture that I was raised in, and you know there are these tracks that you get on and it's like, okay, we'll do well in school and then go get a job and then go get married. And like you know, you have this feeling of being ahead or behind, so that relative comparison, but then also after you do a thing, after you make some sort of achievement, you're kind of looking for to someone else for validation. And I don't know if my younger self would have like listened to be quite honest with you, but you know just if I could somehow learn this lesson that like the person that you really need to please is yourself like just just being like, are you doing what you want to do or are you doing it because that's the expectation of somebody else? Are you climbing the ladder because you want to get to the top or are you climbing the ladder because the ladder was put in front of you? Just examining that?
speaker 2: That makes sense. Cool. Well, thanks so much for your time, Steve. I really enjoyed the conversation. And Yeah, I guess now would be the time if we if you wanna shout out anything that you're working on.
speaker 1: I have my YouTube channel. It's called a life engineered, so go and subscribe to that. I have a weekly newsletter that gets sent out. So you know, it takes a long time to make a YouTube video. And so, you know, if you want more for me, the newsletter is there. And then if you want to chat and just join my discord, awesome.
speaker 2: Cool. All right. Well, thanks so much for your time, Steve. Really appreciate it. Absolutely.