Soft Skills Engineering - Episode 447: Overleveled at FAANG and accidental draft feedback

Episode Date: February 10, 2025

In this episode, Dave and Jamison answer these questions: I am a mid level engineer overleveled as a senior engineer in a FAANG company. I got super lucky landing this high paying remote job, but dang… I did underestimate the expectations for my senior level. I had no FAANG experience before, just working at startups, flat hierarchies, just doing the heavy lifting coding. Now it is all about impact and multiplying impact across the team. I am told I should do less IC work and more leading of projects and owning initiatives. Can you give me some general advice on what actions I can take to get from the mid-level to senior-level? I am not really sure, what taking ownership really means in practice… These just seem like empty phrases to me without a meaning… I have had a bit of time, while running a 40 minute build, so I looked into open pull requests. One PR caught my eye and I started to read through it and left a comment with a suggestion for a small change. All in all sounds good probably, but the caveat to this is, that the PR was marked as Draft. I was thinking that it would be useful for the author of the PR to already get some suggestions during development, but the response got me thinking. The author passive aggressively mentioned that the PR is in Draft and that there is more work to do. Am I the jerk for commenting on a draft PR? Second question, what other things should I pay attention to in code reviews to not be a jerk?

it takes more than constantly upgrading homebrew because you can't remember the difference between brew update and brew upgrade to be a great engineer this is soft skills engineering episode 447 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers who can't remember how not to spend the next 45 minutes watching your terminal be useless i think any package management system becomes popular enough that everyone hates how slow it is and how bloated it is like that's a that's a marker of success if you build this excellent incredible beautifully abstracted technically perfect like a shiny diamond package manager system and you make it really easy to consume dependencies then bam suddenly

people add a ton of dependencies and then your ecosystem is bloated and you're a bad person and your package manager is bad yeah i also don't remember the difference between brew update and brew upgrade but i do know that both of them are slow and we'll do a bunch of stuff oh boy i remember rust got a for a while uh cargo the the dependency manager package management thing for rust was a big point of pride and now there's some backlash about rust where everything installs a million packages and yeah yeah kind of the original node sin yep was there a thing before node that people got mad at for installing a bunch of packages a programming language or environment or something i don't know before node i was just static linking every single library on

earth into my c++ binaries yeah i would just yeah yeah i would i would manage packages by copying the text onto my computer and then saving it there i mean go kind of they do the same thing discourages yeah same thing as static linking that's what i mean well yes but for a while they didn't have a an official way to manage third-party dependencies and their solution was like clone the repo yourself and yeah yeah anyways that's not what this show is about at all. Let's get out of here. Something else. I want to talk to you about WorkOS, who is sponsoring this episode.

They have launched a ton of very useful stuff that you should know about, and we will tell you about it during this episode. All right. Shall I thank our patrons? Yes. Okay, I think we have one one-time shout-out to Pastel Anxious, and a bunch of weekly shout-outs

to those folks that are generating... generating. That's how you mix generous and donate into one word. It's generate. Wow. They're generating happiness in Dave's soul. Yes. Oh, my goodness.

They're generating such a high level of contribution that we shout them out every week. They are. An anonymous anemone analyzed an alarming anomaly in an amateur animatronic anatomy. That was incredible. Oh, yeah. Holy cow. Flawless. That was my first take.

Wow. Two fish in a tank. One says to the other, hey, mate, do you know how to drive that thing? oh we haven't had to quit your job for a while you guys feeling okay alexander kuznetsov chris morton nick molyneux michael young.dev attribute error none type object has no attribute to string javier gonzalez chewy dot dot david jameson's new lovely unpaid intern ted timbrel and now a moment of silence for victims of recent events become a senior engineer.com is a newsletter you should read unsalted french fries are morally objectionable

dan from drone deploy chase w norton never is not just a crater on mars flamingo emoji i like chicken i like liver miyamix miyamix please deliver trash panda get status kyle boss can't see dodds nevar is not just a planet in the vulcan system jenny kim the stochastic parrot helicone.ai best observability tool for ai red panda is best panda java is just discounted c sharp with worst documentation jonathan kings and i beautiful functional user documentation Two-time shout out to Angelical Cathor, WilliamAngel.net has cookies, and Brayden Gaines, John Grant, Brittany Ellick, Joe Grossberg. Every Monday, whether I hear soft skills engineering, I think, I'm going to change my username for next week. Then all of a sudden, it.

And lastly, Cody Sale. There was some great discussion in the soft skills engineering Slack community this week about how exactly are some of these words spelled. And my favorite one was that people don't hear Kent C. Dodds. They hear Kent C. Dots. Huh. I can't see dots. Maybe he can't. Yeah.

Thank you so much. We appreciate you and we appreciate the levity and joy you bring to our life and the way that you financially support the show also. It makes us keep going. That and the questions and our insatiable hunger to dominate the podcasting universe, which we'll crush under our thumbs yes no we don't have slowly we just like doing this dave do you want to read our wait no no i want to read our first question i also want you to this is from a listener named beth jesus who says i am a mid-level engineer over leveled as a senior

engineer in a fang company i got super lucky landing this high-paying remote job but dang i did underestimate the expectations for my senior level i had no fang experience before just working at startups flat hierarchies just doing the heavy lifting coding now it is all about impact and multiplying impact across the team i'm told i should do less ic work and more leading of projects and owning initiatives can you give me some general advice on what actions i can take to get from mid-level to senior level i am not really sure what taking ownership really means in practice these just seem like empty phrases to me without a meaning with a name like beth jesus i wonder which fang company we're talking about here could be any of them yeah i mean just just be coincidence

oh boy well i was in this position for a while except just bump it up one level where i was getting pressure to promote up to the next level and i got a lot of i would call it like unhelpfully ambiguous guidance from managers telling me how to do things like take more ownership but not actually saying how to move up to the next level it was hard demonstrate more stick with it to itivism yes oh boy dave you need to embody our leadership principles yes i did at a higher level yes okay that's exactly how it felt like what do you want me to do and really the bottom line answer was i want you to get promoted because i look so good when my people get promoted yeah yeah but they wanted to pretend it was some kind of really mysterious and impactful coaching

strategy where they give you advice that seems like it makes no sense but really you discover inside of yourself the answer and then you realize ah the advice triggered it yes it was thanks to your advice to show more ownership that led me on a journey of self-discovery they learned this from the zen masters yes i never was enlightened though i just eventually left wait i was enlightened now i see wait a minute this is all nonsense oh boy i'll tell you what though getting over leveled at a fan company what a rare treat almost everyone i know actually i'll tell you what when i was at a fang company i tried to get about seven people jobs there two of them got jobs five of them got

rejected flat out and the two that did get jobs both got down leveled in the interview process sometimes they pride themselves on that too it's like a a status thing like oh man you you you are this level at some other place but here at at fang corporation number seven we hold ourselves to a higher standard yeah and our our staff software engineers are your distinguished mega ultra principal engineers yes our junior interns are your principal engineers over there at whatever the n stands for in fang yeah oh but it is a rare treat i mean the question asker plainly acknowledges it that i'm making a great money remote job that's surprising actually that that's even possible nowadays based on what i've been hearing so that's like two two big lucky

rolls of the dice here a you got an overleveled job at a fan company and b it's remote so i don't know like just enjoy it well i guess you can't enjoy it too easily though you'll get fired probably if you underperform in your level yeah i mean that is the downside if they feel like they aren't meeting the expectations sounds like they're not which makes sense if if you're coming from a startup, I think part of the change is going from doing excellent work on something someone else asked you to do, like producing the output they asked you to produce, to helping decide what the output should be. Maybe this is the same general vague nonsense phrases, but like say you just crush code, right? You get a giant list of tickets, you churn through them, you build

great abstractions technically excellent you you complete the features on time and under budget i think that feels like doing a really good job and it sounds like at this fan company they're saying yes yeah do all that but you also have to do other stuff too like stick to itisms yeah well i think the other stuff is more like you're working above the level of abstraction of individual tickets like you are trying to achieve some broader outcome and some contributions to that outcome might be do the tickets write the code but some of it might be like write the tickets or make the design doc or remind people here's what we're building and and here's how important it is and i don't know there's there's like a shift from writing code to achieve the outcome

someone asked you to achieve to like defining the outcomes and then doing whatever is most effective at achieving those outcomes. It's a good way to put it. And I've got, I've got bad news for Beth Chazos here because if, if indeed this company is Amazon and you've been hired into a senior role, a senior level, you will not be graded just by meeting expectations at the senior level. You have to exceed them because the way they do hiring there is they only hire you into a level if they, during the interview process, qualify you as better than 50% of people at the company at that level. So they already expect you to be performing in the top half of all senior engineers at the company. So this probably makes you feel worse, but I'm

sorry. The expectations are- Thanks for the help, Dave. Like double high. So all this is to say is do everything Jameson said with extreme urgency, because they're going to expect you to do it really well. Another way to have impact, so yeah, like leading projects and owning initiatives, that's pretty visible. Another way to be impactful is help a bunch of other people. That is sometimes less visible, and it's a common complaint to say, I feel like I do a lot of supporting work to help other engineers be more effective, and that's not recognized. so there's a there's a trade-off with focusing on that but it might be maybe it's more natural for you to do that and you kind of need to rely on like people seeing that and reporting it for it to be visible because it's much fuzzier than than like ah the apollo initiative every company forever will always have something called the apollo initiative so there's at least one where

you are like ah yes beth jesus delivered on the apollo initiative so you're saying choose a high profile name that will stick yeah and then do a project with that name yeah something with no ominous connotations like icarus or prometheus or pompeii or his box or yeah agamemnon surely he had a good ending to his life right one of those famous happy endings to greek stories oh yeah classic classic greek happy what's the opposite of tragedy yeah i know i'm trying to think of the word i don't know idyllic blissful ending i don't know well what do you think well i think that when a company like amazon says they want you to take more ownership what they mean is they want you to impact other teams and benefit them and i'm trying to put this in concrete terms that you can do but

get to know the teams that are adjacent to you dependent on you or to which you depend on and try to find some way to make your collective lives better improve a process fix a bad api do something that will make that other team say oh i'm really glad that you fixed that thing or did that thing and if you can accrue a few of those that'll really bode well for you i remember one time i was a dependency on another team so we provided a platform level functionality that i don't know maybe a dozen other teams depended on to do their jobs and someone reported an issue and i did a really deep dive into figuring out what had gone wrong to make that issue happen and i figured it out and i wrote like a one or two pager doc about it and then i just shared that

with the team. And it was a really well-written doc because it was like, you know, clear problem statement. Here's what happened. You know, you know, those postmortem docs like the Jamison loves that are really clear and succinct. And it kind of makes the author look kind of super heroic because it's like, oh yeah, look at all these awesome stuff you figured out and how clear cut it is and how straightforward the fix is. And I have tons of confidence in you and the solution. It's great. It was one of those docs and it made the other team's manager actually so happy that he wrote a glowing review about me to my manager and he kind of cc'd a bunch of high profile people and i was like oh i thought i was just doing my job because we had a bug in our system and you

depended on it and it was broken but the way that that other manager viewed it was that i was taking ownership and did something to benefit their team and i was like oh great now i have a little bit of a glimpse into what ownership is i like that example because it is focused on helping i could see a perverse definition of ownership being like you influence other teams to do stuff that you say and then you get into all these games of like trying to convince them that your project is important and they should work on it but it's a lot easier to make their lives better in some way than it is to say like everyone jump on board my thing yeah i swear it'll be good for you i once had lunch with a director at amazon and he really opened my eyes about what they mean when they say

take ownership. And so I'll say this to specifically help this listener, Beth, Beth Jesus, if that really is your name, which I'm pretty sure it is, but it's, I think it's actually a really good principle for everyone, whether you work at Amazon or not. But this person said to me, ownership, most people don't understand what it means. And I'm like, what are you talking about? It's a simple word. It just means you own something and you, you know, you take good care of it. And he's like, no, but at a company like Amazon, what it means is that you don't just do your job narrowly focusing on the duties you've been assigned, but you think about and act in the best interest of the entire company, even if it means that your and your team's immediate priorities

have to take a backseat. And I realized, yes, that's what is really meant here. And I think when a company like a fan company is trying to push you to level up, what they're trying to say is take a bigger view and increase your sphere of responsibility to do more good. And to take this all the way to the extreme, imagine the CEO of the company. Every part of that company ultimately is responsible or the CEO is responsible for. And so you think to yourself, is there ever a point where a CEO would say, that's not my job? Not really, because ultimately anything that goes wrong is going to roll up to the CEO and it's going to be like, yeah, it's your job to make sure that doesn't go wrong. Now, is it your job to actually swing the hammer on the bathroom stall

hinge that needs to be fixed? No, like it's not your job to swing the hammer, but it sure is your job to make sure that hammer gets swung right and that everything gets repaired correctly. And so same is true of a software engineer. You've got your little widget that you're responsible for. And at a fang company, undoubtedly, it's a small little thing that feels inconsequential. But when you raise your sights to your neighboring teams and try to make things better for everyone, that's what they mean by take ownership. And that honestly, that's what it means to go to senior level as well. I love that. That's great advice. Oh, look at that. It's worth what you paid for it. And that director's name, Beth Jezos. Exactly. He was way over level.

All right. Have we answered the question? I have one more thing to say on this. A really easy thing to do at your team level, because the thing is moving from mid to senior sometimes just means doing things that only impact your immediate team, but the whole team and not just you. And one really easy way to do that is to improve your processes. Probably your deployment pipeline could be faster or more reliable or less. Maybe there's some flakiness that fails sometimes. Maybe you've got a framework or a pattern you're using in your code that's not as good and you could propose a replacement.

Things like that. These are all at the senior level and we'll get your credit. All right. Now we've answered it. Now I'm done. I've answered. Good job. You helped.

Thank you. Jameson, we've been talking about WorkOS a lot. And they have added some very useful stuff to their product. Now, WorkOS is not just for adding SSO to your app. It's so much more. They've launched some cool stuff, and we will tell you about it. WorkOS lets you not reinvent permissioning with their new fine-grained authorization system, which is based on a Google system white paper thing called Zanzibar.

Very fun word to say. Yes. I've actually built some fine-grained auth systems myself, and they had a way more boring name. And also, I had to maintain all the code myself. Yes. Also, check out WorkOS's radar feature, which can block bad signups from your app. So things like bots, fraud, and impossible travel, like someone using a VPN or proxy to trick your signup system, they can detect all of that for you and help you avoid fraudulent

signups. They launched an entitlements feature that integrates with Stripe, so your app can automatically give access to accounts that have paid for new features. I've also built one of these myself, and it can be a huge pain in the butt. So nice to put that on someone else. Yes, totally. To me, the coolest feature they launched is a B2B app starter kit for Next.js. WorkOS will actually help get your Next.js app essentially from zero to one super fast. They provide authentication, billing, user management, audit logs, and a ton more.

And I got to say, if there's an easier way to start a B2B SaaS app than WorkOS, I can't think of it. Do not forget the Passkey support. It's effortless for you to add Passkey support and your users will love it. Check out WorkOS.com and try out all these amazing new features. Dave, do you want to read our next question? Yes. This comes from an anonymous listener who says, I have had a bit of time while running a 40-minute build, so I looked into open pull requests. One PR caught my eye and I started to read through it and left a comment with a suggestion for a small change. All in all, sounds good probably, but the caveat to this is that PR was marked as draft. P.S. I've done this before too, on accident. I was thinking that it would be useful for the

author of the PR to already get some suggestions during development, but the response got me thinking. That author passively, aggressively mentioned that the PR is in draft and that there is more work to do. Am I the jerk for commenting on a draft PR? Second question, what other things should I pay attention to in code reviews to not be a jerk? Second one is hard. I'm going to skip that. Am I the jerk for commenting on a draft PR? I don't think so. The caveat to this is cultural expectations very wildly. And it is possible that your company has a culture that draft PRs have this sacred meaning of you just get to kind of squint at it and be in awe of its majesty and get hyped for what's coming, but don't actually look at it and get feedback. That sounds weird

though. So I think it's most likely that most cultures have an expectation that drafts are drafts you know you know how you write a rough draft of something and famously you yell at everybody who gives you feedback on it like hey i didn't write this for feedback i wrote it for for what glory i yeah i don't know like that's literally the point of a draft right you do it for feedback well in the case of a pr draft you do it for backup i think you're like oh crap this is getting too big and it's still on my computer i gotta get it out of here yeah i want to get it out of here yeah it's possible there is a thing that can happen where someone has kind of a vision of where they want to go and maybe your comment was like well have you thought about security of

this yet and they're like well yeah it's not done yet of course i didn't do the part i hate which is security right for some reason and i definitely wasn't going to ignore it and hope it got through the final pr review yeah so maybe they're maybe they're feeling a little defensive about it but I don't think it's wrong to comment on a PR. Usually if a draft PR appears, I would expect the PR creator to give some context around it and say, hey, here's this idea I'm exploring

and sort of outline expectations for how they want people to engage with it. Maybe the expectations are like, it's hot garbage, so ignore it. I don't know. You can look at it if you want, but know that it is a mess and I'm getting to it. or maybe they're saying, I'm trying out this new pattern and I want feedback because

it would be a big change. And what do you think? That's a good point. Yeah, that's a good point. I don't know. Draft could mean, it could be a signal to say, I don't intend to merge this as is, so don't worry about it, but feel free to give feedback. But it could also mean, I'm just backing up my work in progress. Please don't comment on it because the whole thing is going to change. Maybe we need a new flag in GitHub. I think that exists already and is called a branch just push your branch up don't make a draft don't make a pr out of it yeah i don't know it's a good point or maybe it's like i'm still writing the i'm still writing the pr description field so everything will make sense after you read that beautiful markdown that i'm

typing the markdown is a draft though don't comment on the markdown draft before it is done i've done a comment that's even dumber on a pr if you'd like that are my little story so i'm uh currently a CTO. And so I don't read nearly every PR that my team produces because there's like 20 engineers, so I can't do it all. But I do occasionally read some for areas that I'm particularly interested in or that I know. And one time I left just a really stupid comment. And you got to remember, when you're the CTO and you leave a stupid comment, it's like 10x stupider than anyone else, I'm afraid. That's how I feel anyway. So I was commenting on some code that I did not realize was actually inside of a unit test. And I was like, Hey, for this to

be more robust and handle a wide, you know, a wider variety of user input, you might want to consider this other function instead of this regular expression you're using. And, and then later he was like, Oh, okay, I guess I can change that. Like, you know, cause that, this is why it's so much worse for a CTO to make a bad comment. He was like, Oh yeah, sure. I can change that. Then later I realized, Oh my gosh, it was a unit test. There is no user input. There's just like three strings it has to handle and they're all written right there like three lines above so don't worry about this robust you know input handling so i don't know what what's worse commenting on a draft or commenting on code that you didn't realize is not actually production code

yeah low context comments can often be worse than nothing i have yeah i have damaged things by swooping in and saying i'm so busy but oh i want to look at this thing and i'll glance through it and squint and here's my knee-jerk reaction and it's just like so wrong and missing important details and etc yep hmm what is the worst pr thing i've done i don't know i can't remember any giant sins one time i was uh i was running a few teams and there was a project i was excited about so i went and reviewed a pr and i saw it was just it was hanging out in limbo for a while and i squinted at it and was like yeah i don't know it seems good hit approve it got merged and later on another engineer on the team pulled me aside and said very kindly hey please don't do that that had

some bugs in it you didn't know the requirements like you didn't yeah you really had no business approving that in a kind way i mean i'm shortening it here but their their concern was justified i was just like code yeah good let's let's ship it let's move forward that's awesome keep going and And the way I expressed that was by saying, approve, and then it got merged, and then they had to clean it up afterwards. I'm just imagining the hour of time that that coworker spent writing that message to you to make sure it wasn't hurtful and diplomatically perfect. Yeah. I would like to think I am easy to give feedback to, but no one can erase power structures. Exactly.

I was just thinking, if my boss had done that, I'd be like, okay, I got to say this just right. yeah i gotta figure hang on i gotta figure this out let alone the time to actually like clean up the technical impact right yeah yeah redirecting oh yeah i got my hand justifiably slapped and i either reviewed carefully for real or did not review after that which i think are both improvements and with that story that doesn't help you question is answered yeah so your conclusion is not a jerk not a jerk no i don't think so i think if anything there's a misunderstanding here they did not explain what they're expecting and i don't know it's kind of on them if they don't want feedback then don't throw up a pr fair if you want to be like super cautious about not being

a jerk and you and you also want to comment on a draft pr all you have to say is i know this is draft and a lot of it might change but i just happen to read it and here's a couple of comments for what they're worth and then throw it out yeah now you could kind of soften it and say hey out like maybe maybe you're you're thinking about this already but here's the thing i noticed exactly there you go instant non-jerk move what other things should i pay attention to in code reviews to not be a jerk that's a long list yeah i've got one you need to read the room in terms of the business impact of the change and the business pressure around the change versus your like technical nitpicks yes some people who pride themselves on giving extensive

feedback on prs and they are they can always find stuff and i think that's a whole other issue that i i have feelings about but sometimes there's a thing that has to get done right away and it is not the time to nitpick over variable naming conventions or or like yeah it's got to work but like oh you should have used a switch statement instead of an if else or meanwhile prod is burning down yeah prod is on fire there's this release that has to go out and this is blocking it like now is not the time yeah you hold those things in your heart and and let them build up resentment that explodes in a future code review right exactly it's just that is the time it's like resentment debt it'll get paid back eventually yeah i can think of one one thing

you could do to not be a jerk there's probably a thousand more but something that really gets to me is when people make performance claims in your PR without proof. I remember I had someone say, Dave, you need to reorder the two expressions in your if statement so that it will be faster because this one... Yeah, it'll short circuit the evaluation. And I was like, okay. And I thought to myself, now you've put me in a real pickle because I'm pretty sure you're wrong. You haven't provided any evidence. And now I have to go and provide evidence to debunk your claim. So what did I do? Yeah. This is the old, it takes an order of magnitude more effort to refute BS than to spout it. Yes. Oh, maybe more, maybe more than one order of magnitude. Anyway, sure enough,

I went offline, I wrote a bunch of stupid Java code and I timed it with the art, the expressions in different orders. And actually my way was faster. And so now what am I supposed to do? Now I got to reply to the comment and say, actually, you're wrong. The way I did it was faster. And by the way, in this situation, speed does not matter. Like the difference is even if it was 10 times slower than the way you think, you know, than it is, it still wouldn't matter. This is part of a workflow that takes 10 minutes. And this is a parallel job that takes a 10th of a second. And we're talking about maybe making it take half of a 10th of a second. Yeah, performance is tricky because you either have to be a world class expert to spot things ahead of time, or you

have to have something that's slow and then go back and make it faster i feel like but i agree that my micro benchmark shows this is a problem is not compelling yeah all right well did we rid the world of pr jerk behavior with those two simple comments we reduced the amount of it i think good enough by an unmeasurable amount a positive impact that's all i'm looking for yes directional not magnitudes yes all right have we answered the question i think yes i think so we definitely gave an answer to which question you will be the judge sometimes we do turn a question into a different question that we wish it was because it was more fun to answer maybe we did it this time maybe not yeah what can people do if they want their own questions answered go over to softskills.audio

and click the ask a question button where you can fill out our handy dandy little form thank you to everyone who does that each week. Your questions flow in like water to my body that keeps my soul hydrated. Dave has an IV hooked up to his arm full of ground up pieces of paper from the Excel spreadsheet he's printed out. It's very unhealthy, which is why most of our budget for the podcast goes into medical treatments. That's right. He has to be on dialysis to filter out all the Bits of paper floating around in his blood. But it wouldn't be possible without you. Thank you, listeners.

Thank you for providing all that paper. Yes. All right, thanks for listening. We'll catch you next week.