WHO CARES About All These Numbers On Resumes?! (Hint: YOU Should)

Transcript is auto-generated and may contain errors.

Hey folks, I'm headed to CrossFit. We're going to Reddit for the topic today. This one is about résumés. And the author says, "What the heck is up with all of these numbers on résumés?" and go on to ask about why is there so much advice floating around on Reddit and other places where um you know the recommendation for resumes is that when you're writing stuff you should be saying you know increased sales or made something go from X to Y or some percentage change like why is that? um and sort of start to make the the claim that like clearly this must be a joke or must be wrong, right? Because like there's no company ever that tracks like metrics for like everything that you're doing, right? So like why the heck is this advice? So I wanted to talk about this because I think it's uh I think it's important.

Um, I think that the unfortunately the top voted comment really does not uh help. Um, the top voted comment is something along the lines of like that's because 90% of of uh, you know, thing people recommending how to write your resume say that like it causes an improve. They're basically poking fun. I can't remember how it's worded, but poking fun uh about the whole thing and using numbers to kind of do so. So, the um I want to start by saying the reality is if you have written a resume and it doesn't use numbers or anything and it works really well for you, hell yeah, keep doing whatever you're doing. If you got something that's not broken, don't fix it. I'm not here to tell you otherwise. Totally cool, right? I mean it genuinely too. Like if you have something that you're like, "Hey, I follow this pattern has worked every single time I go to apply for jobs." Hell yeah, use that.

That's great. But um for everyone else who doesn't have something that's working for them, uh the reason that having numbers and stuff on your resume is to help illustrate the impact. And that might sound obvious, but um the unfortunate reality is that uh to make a sweeping generalization here, software engineers are generally not good at communicating that the impact that they're having to non-technical people. And when I say non-technical people, I mean non-technical for the domain that you're working in specifically. Okay? So, I don't just mean someone that doesn't code or something like that because odds are that people reviewing your resume, at least some of them will write code, right? Like whether it's a hiring manager or some of the other uh you know engineers on the team that are going to be kind of doing interviews and stuff with you. Odds are someone someone's writing code.

So I don't mean non-technical in the sense that like you know it's only people uh from HR that maybe have never written code or something like that. I just mean that if you're like hey I worked on some proprietary banking software and I go to talk about the proprietary banking software. A lot of the time people are wildly inequipped to communicate their impact properly. And um just to give you an example if I could literally I'm the hardest part about what I'm about to do is try to make this stuff up on the spot especially with names but it's like okay I work at company uh you know banking company A you know great banking company and we have this proprietary software called uh I don't know uh platform X okay so platform X is our proprietary banking software and I led the migration uh

platform X's uh processing engine that we call uh engine engine C and um we migrated engine C over to the new uh the new engine that we have that's uh engine C squared and um and it uses uh .NET core instead of net framework and um to you or to me in this case who's making up this ridiculously random scenario um I might in my head be like man that was a three-year project and I had to go work with every single other team in the company that touches code and I led that and it was you know the biggest accomplishment I've had in my career here. The problem is if you're not communicating that kind of stuff in a way that other people are going to understand on the resume, then you miss out on a ridiculous opportunity.

Because in an interview, you might be able to go into the detail and say those extra things I just said, but like if you haven't made that stand out on the resume to begin with, you might not even have the opportunity in the interview. So how we try and do this is by talking or you know communicating in a way that other people can understand the impact without having to know all of the details. Right. So for example, I just talked about a migration from .NET Framework to .NET Core. If you're not a .NET developer, don't worry about it. Just moving moving between sort of like a different framework versions that have a a really big stepping stone kind of thing. And um the way that we want to try to accomplish this is to to try and not use the proprietary things because people will not get them.

Like you can refer to them, but like that can't be you can't make the assumption that people just know what those things are. So if we start talking about the scale or quantifying things, then people can start to have a better understanding. And even if you think back to what I just said, if not, you can rewind it probably depending on how you're watching this. But when I added in the extra details after and I was like the things that I know as the person who did this really big migration is like I know that it took me years. I know that I had to go work with every other team. I know that like the scale of this, but that's something that you should try to talk about in your resume so that you don't have to like hope that you get to talk about it in the interview.

You try to convey it up front. So, I'm going to be terrible at trying to do this on the fly. I'm just trying to be transparent with you. But, um, in this example, you could say like, yeah, I led a a migration from .NET Framework to net core. And so now think about what the impact of that was and the scale of this was working with the 37 teams across the organization to lead them through that migration and that resulted in some services and you could have the number if you know it. um you know some services like uh so seven of the 37 teams had services that saw um you know uh 62.5% performance or like throughput gains on average. Um like you don't have to know as the person who is hearing that or reading that you don't have to know anything about the proprietary banking software to understand the impact of that.

Even better is like uh for uh for demonstrating the impact of things is like the what's a good way to say this? I think depending on some things having like performance as metrics can be really valuable. So like I was just giving an example of uh you know throughput increases right and you could do like memory savings. Um, an extension of that, I shouldn't have said even better, but an extension of that is like when there's cost savings involved, right? Like that's an interesting thing to try and anchor to. Uh, or something that's going to be like a userfacing metric is also really helpful. Um some reasons for that are of course like a lot of companies hopefully a lot of companies hopefully are uh very customer ccentric right you'll even see like in some big tech companies they have that in some of their

their values directly oh boy and um you know there's hopefully hopefully that most of the places that say that they're customercentric actually are and not just, you know, slapping it slapping it in their list of values to, you know, say, "Yeah, hell yeah, we're doing it." Uh, and then not care. But if they do genuinely care, when you can demonstrate impact that was basically geared at uh, you know, use like end user impact, customer impact. That's going to help not only for having something that's quantifiable to represent impact in general, but the fact that it's going to be for the end user, the customer means that you're also demonstrating that people yourself in this case are thinking about the end user. We're not just like, hey, I made the code a thousand times faster and like, oh, well, what part of the code is that? And it's like, I don't know, this tool that I run myself on my desktop and no one else uses it.

And it's like, well, why are we spending time on that? like I don't know it was fun but I have quantifiable impact like that's not it's not the same but if you're able to demonstrate that in the context of especially your users I think that that can be extra helpful so it's not like this kind of stuff this kind of advice it's really difficult to give people like universal advice because I can't say that like you know if you do this it will automatically work and um I would never make the claim that like other ways cannot work because it will only take literally one person who didn't have quantifiable impact to say look at my resume I didn't do that it worked therefore you're wrong so not my intention to say that it must be done this way I am simply stating that uh

this is one way that seems to work quite well for communicating the types of things that you've worked on and and essentially that you have been able to have a big impact at the places that you've worked at because at the end of the day the people that are hiring you that's what they want you to be able to do and if they have to understand how much you need to grow into that versus how you have been operating that can make a big difference. Um, but yeah, I think like two two sort of meta points that I want to get across here are uh one, how am I going to switch these lanes? Let's see. Give me one sec. One more lane. Actually, two more lanes. Now it's one more. Okay. Um, two meta points are uh, one is that as software engineers, we generally do a pretty poor job of communicating things outside of outside of our like own what's a good way to say this?

See, it's already hard for me to do. um communicating things to other people that are outside of our direct domain. It's a skill that we have to use literally in the workplace when you're working with other stakeholders that maybe are not technical or people on different teams. Um, so I say this because I've been doing this for over a decade and it's a common theme and it also gets translated this way in resumes as well because it's the same challenge when you have things that you understand. You have your own understanding of these things in your domain. You understand the significance, the importance, um, you know the terminology, the jargon, everything else. You need to find ways to communicate this to other people that don't know. Um, you can test this, and I'm not saying it's like going to work perfectly or is the is the perfect test uh outright, but you could test this if you have a friend or significant other who is willing to read through your resume.

Now you're you might say, well, you know, the hiring manager, whoever is not my significant other or my friend, and like that's a totally, you know, crappy comparison. My point is that there should be ideally it would be great if someone that is your significant other or friend who doesn't understand the technical domain you're in has some way to interpret the impact that you've had. I'm not saying that you have to gear it perfectly for them, but it's a good litmus test if they read through it and they're like, I literally have no idea what you've done. Like, I think that's a good test to be able to say, okay, maybe I need to kind of reword some things or change how things are explained. It's not that you have the wrong things written down, but you may want to think about how you're you're phrasing them.

And again, it's not that they have to understand 100% of everything. You know, that net migration example I was giving, they might be like, I don't even know whatnet is. And like that's cool. Like they might not have to, but um could they understand why that was important? I think that's kind of what I'm after. And it doesn't have to be every single thing, but if they can at least have some takeaway, I think that's a good litmus test for you. Um, I should like I should try this. I should update my resume and then give it to my my wife and see, you know, like just so I can tell you guys like this is I'm not just making this up. Like I I believe that this is a good way to at least like get a little bit of a litmus test on on your verbiage.

Um, so that's one part. And then the other part in general is like I don't think that we do a good job in general as software engineers for like explaining why things are important and it's just another communication challenge. Think about like this is going to I'm sorry I know this is going to bother some people but think about being frustrated with tech debt not being done and in your mind you're like I know that we have to go clean this class up. It's crazy. It needs to get done and like product or you know product owner is not letting me do it and like this is ridiculous but like I know that this is the most important thing to do and like this is an example. Sorry if you have a product owner that's actually terrible and you have done a good job of explaining why.

Um but I think a lot of the time when I've sat in conversations and this is also as a software engineer by the way. Um because my role before Microsoft was a dual role as an individual contributor and an engineering manager. I sat in the conversations as both and I have seen people try to say we should do this tech debt but then not have any reason as to why it's beneficial. They know in their mind why it is but they're very unable to explain why. And I think that it's a very common thing that happens on résumés. I've done a ton of well not a ton. I've done like 30 ré reviews on my channel. And uh it's a common theme. It's a common theme where people will list something and I'm like, I bet you I bet you if I were to talk to you about this, you could tell me why it's so important.

But when I read this resume, I have no freaking clue. No clue. But it's not because I'm like, "Oh, I bet this person is just making this up." Or like, you know, clearly they don't know what's going on. I'm like, "I bet you it is important, but you haven't told me why. It's not obvious." Um, so this is the kind of advice I try to give when going through that kind of stuff. And yeah, it really comes down to those two points, I'd say. So, um, with that said, I'm at CrossFit. If you're interested in having your resume reviewed, I have moved my resume reviews from my main channel, Dev Leader, over to Dev Leader Path to Tech. That's where they're all going. I'm re-uploading all of them there on that new channel. If you are interested in having your resume reviewed, please go watch one of those videos.

You'll see the instructions on how to do it. I'm a little bit behind on the resume reviews right now, but I will continue. I'm just migrating channels, so it's a bit of a pain in the butt. Thank you so much for watching. I will see you next time. Take care.