Contractor Goes FULL TIME - What Level Software Engineer Will They Be？

Hi and welcome to the ré review series. My name is Nick Cosantino and I'm a principal software engineering manager at Microsoft. In the ré review series, I take the résumés that you submit and I go through them and I offer my feedback on them. So that's going to include things that I think are working well, things that might be my personal opinion about style or other things, things that I would recommend that you should change to try and stand out more, and things that I think are just outright not working. So it's not meant to be a roast by any means. I will be giving critical feedback, but it's not going to be anything that's making fun of anyone because I want to make sure that you feel comfortable submitting them because I just want to be able to help. With that said, if you're interested in having your resume reviewed for free, you can submit it to résuméser.ca. With that said, let's jump over to this resume. We're going to be reviewing it from an individual who's been a longtime programmer according to them. So, they said over half of their life they've been programming. And uh they have included their GitHub and website and they kind of mentioned in their email when they sent it. But the way that I review these is I'm going to be treating it very much like I would if I were just getting a resume. I personally will not go to any website or GitHub unless I see what I want to see on the resume and want to go read more. So, the reason I bring this up is I've heard from some individuals, they've been coached to sort of bait the ré reviewer into, you know, only putting so much on the resume and that way they can follow up with other things or they can find out in the interview. My perspective is if I'm not seeing it right away on the resume, I'm not going to see it at any other point. If it's something that I can uncover more of during the interview, that's great, but I already have to be impressed by the resume before there's even an interview. So, I don't think that that strategy works. That's not what this individual said, but I've heard it from other people. Just wanted to call it out. So, I've not seen their site or GitHub. They mentioned that they are a freelancer and they're trying to go more of a like traditional route. So, I think as we go through their resume, you'll see that they've had freelancing jobs. They've been doing some stuff in parallel, but I believe their intention is to get their resume together and start going, like I said, a more traditional route, maybe to um, you know, an established company or to big tech or something. they didn't really clarify but something that's not necessarily freelancing. So they had a couple of questions that if I can answer as I'm going through this or by the end that they would find helpful. One is that how should they try to highlight the overlapping tenure, right? So when they are doing freelancing and they have multiple contracts going on in in around the same time like how should they call that out on the resume or like does it get too noisy or just any tips on that? So, we'll talk about that. And then if they were to get hired in in a, you know, sort of standard company, what level should they even be talking about, right? Are they a senior software engineer? Are they junior? So, I'll give some perspective on that at the end of this video. To kick it off on the resume itself, uh, let's go through the structure. I think we got the right pieces going on. There's obviously some highle info at the top that's redacted, but they have their work experience called out. I like a little skills section. So they have their languages and frameworks and technologies. They have called out internships and extracurriculars as well as education. I always mention that for education like if you have it, please put it down. That includes certificates and stuff like that. In my opinion, it's never been a deal breakaker for me. But I don't like recommending that blindly to people where it doesn't matter or something like that. Some places have it as a requirement and they're going to, you know, live by that. There's other places that list it as a requirement in the the job description and they don't actually care. It's just it happens to be there. So, in my opinion, if you have it, you might as well list it. So, uh they did in this case, which is great. A couple things that I might tweak and tune on this. Um I don't know if it's just me, this might just be a personal preference, but I feel like the real estate usage on the single page here is not great. It's two columns, but it's it kind of feels like it's in little quadrants. I don't know. it's not really doing it for me. I feel like it's not an effective use of space for some reason. Uh maybe it's the font size or something like that. These are little details obviously, but in my opinion, if there were uh like what I find is more traditional is like more of a single column where you have they could put their skills and frameworks up at the top. They could collapse it a little bit smaller so we don't have uh more of these spaced out sort of uh you know boxed border icon text things going on. and then having the work experience kind of spanning, you know, the the entire line because if we look at the first block for work experience and the second one right below it, each one is three lines of actual experience and that takes up an entire quarter of the page for real estate. So, seems like a minor detail. I don't know if this person did it on purpose to try and uh you know, sort of fill the page, but my recommendation would be to perhaps move away from this. Try some different layouts. Seems minor. My opinion is that uh that might help actually allow you to get more real estate for more information to put on here. The other thing that I'd mention, this is just my probably my personal opinion, but I consider internships work experience. So, they have internships and extracurricular called out. Personally, I would take uh the internship experience uh which is the first item in uh this section here. Let me just highlight it for you. So, in this section, um that is actually an internship. So I would pull it over to the work experience but then of course if this is the work experience in you know one half I don't know what this layout what the strategy would be so makes it a little bit messy but I consider internships work experience and then extracurricular could be uh either things are volunteering for or side projects and stuff like that and actually now that I'm reading this I think that this bottom one I know it's redacted at this point so I'm forgetting but the bottom one I'm seeing led the architect ure of a chat moderation bot. I think that this bottom one here is actually the internship and this one that's a mod for a game I believe is just the side project. So, apologies for the confusion there. But overall, I think they got the right pieces. I'm just not really a big fan of the format because I think the real estate could be better used. Let's go through the work experience though. Um, I think they've done a good job of trying to quantify impact. So just to give you an example, led the tag stack migration resulting in decrease of uh 1,200 seconds to 20 seconds. So big performance improvement there, which is great. We can see this next one, uh provisioning environments fostering a 30% decrease in onboarding time, right? Like without knowing the details of what's going on, I can understand what that kind of impact means because they've quantified it and it's general enough. So I think they've done a pretty good job of that throughout the resume. I'll call out something in just a second um related to the how they've quantified some things just to try and illustrate a difference. Um one thing that I I like in general is I like when people are able to take sort of the skills and and apply them to work experience. In this particular case, I don't know if it's working for me. Just to give you an example, like I see that for this entire work experience, they call out um these five technologies here, right? and the technology and language. But I think what would be more interesting for me is instead of it just like listed out, we already have it listed out like in this section up here. So my personal take would be to kind of inline the stuff that you know without oversaturating the text like just kind of saying like just as an example led the text stack migration from you know Vue.js to uh NUXtJS. I don't know how to say that. Next, I've never said that out loud, but you know, if that was the migration or something else was a migration calling out the tech directly in line, I would prefer that. So, the the difference just to explain it is like I don't know how much of what was done, right? I have to read all five of these and just try to make an assumption about what was done in the in the text above. I know like this bottom one actually has it. So, players with um this framework. So, like that's good. I can't see it for the rest. So that's my personal preference. I always kind of recommend to people if someone who's reading your resume has to guess at what's going on or they have to make assumptions, I think that there's an opportunity to improve the clarity. So this is a minor detail that would help there. The next part that I wanted to call out though was going back to quantifying things. And I think that in some spots we see numbers, which is quantification, but it's not actually sort of um driving the same meaning that I I think they they might be expecting. So what I wrote down in my notes is quantifying things like users is mostly important when we're talking about the scaling of systems. Right? So when you hear in my opinion when you hear someone talking about like you know I was you know developing features or working on a service with you know 1 million users on it. Okay, like that's helpful if you're talking about the fact that that's the scale of the system in terms of the load or how you had to do uh your design tradeoffs and things like that to be able to support that. It doesn't work the same way if you're like, hey, there's a million people that use this thing and like I happen to do a part of this that doesn't actually sort of intertwine with the scale of the system if that makes sense. So, just to give you an example, we see a little bit in here, I think, down at the bottom, right? LED architecture of a chat moderation bot uh serving 100 to 4,000 concurrent uh users. Like, this is a very good use of that in my opinion, right? Because uh and actually, I would even say like the 100 to 4,000 concurrent users, I would say up to 4,000 concurrent users. Um that that range is huge. And even in that range, you might have different architectural decisions. But hey, like you've done a system with 4,000 concurrent users. Awesome. But the scale is something I can understand there. Where it's less helpful is built a mod for and then I think the game name is here. Then it says with over 70,000 current subscribers using Lua. The number of subscribers if there was five subscribers versus a million subscribers. that doesn't help quantify in in this case like what the mod was or the significance. It's like it's trying to anchor some quantification to the wrong thing. The one that's a bit of a hybrid. So, this is kind of interesting to talk about is this one uh here which is holding a 97% positive five-star rating. So, clearly what they've done is good and they have over a 100,000 downloads. So, in my opinion, again, the number of downloads, like I don't care. And I don't mean that to be insulting. That's just like not a it's just not a thing for me. It does. It doesn't move the needle at all. But I think what is helpful uh in terms of representing uh how they've quantified things and qualified them 97% positive. If there was one review and someone left a 97% I don't know, was it this one this guy's review that I'm reviewing the resume for? he gave himself, you know, um some rating or when we see a 100,000 it's like okay in aggregate clearly this is something that's uh done very very well. So that's quite interesting. I just wanted to call out when I keep saying quantifying stuff in these videos generally if we're talking about users like uh it's going to be to try and mention it for scale of the systems that we're working with. Okay, I think that was probably the biggest part. I like that they called out the quantification. I just wanted to clarify my perspective on on what that means. But overall, I think pretty good job in terms of trying to to call out impact. Even down here, spearheaded development of community focused web apps, seeing 76% of the active community sign up within the first quarter. That's great. What gets kind of lost is like I don't necessarily know I don't know what was done specifically to have that happen. like if they wouldn't have done great work. I'm assuming they've done great work. Is the great work in the web app or was the great work in in getting people to move over to it, right? Active community sign up within the first quarter. Like I'm kind of left guessing at like what what actually was done here. Was was it developing the web app? It kind of seems like that. But if it's just making something awesome, like what was the the 76% of active community sign up? I don't necessarily know how that translates. Is that more of like a marketing push? Is that something different? Right. I don't know how the quantification is being assigned over. This next one I think is a great one. Migrated client to serverless resulting in an average of 23% reduction in infrastructure costs using Cloudflare workers D1 and KV. So again, this is a quantifiable impact. I understand even like let's say they were talking about the product or something and I'm like don't know what that is. I don't have to know what that is, right? I can understand going moving to serverless what that might entail and then the fact that there is an infrastructure cost reduction that's 23%. That's that's great. This last one um I will just say kind of outright like this isn't uh it's not really contributing anything. This is a good reminder where this sounds like harsh feedback but I I need people to hear this. And the line that I say in in these ré reviews is like for every every single line that you write in your resume, you should be asking yourself that the resume reader is going to say, "Why should I care?" Every single line. Why should I care? So, I will just say it out loud, right? Why should I care that you developed a beautiful chat room overlay widget viewed by hundreds on Twitch TV? Again, like the widget itself, it's not a distributed system. if it was viewed by hundreds, if it was viewed by one person versus a million, that doesn't change like how you would go design that. This one to me is like it's not adding value. And I don't mean, this is the hard part with these things, right? I'm not trying to suggest like, oh, your chat room overlay widget is dumb or it wasn't beautiful, it was ugly. Not what I'm saying at all. I'm not trying to discredit the work that had to go into that or that it's not good or something like that. But this statement, it doesn't help me understand anything. If this was done in some technology like like tell me more about what's going on because a beautiful chat room overlay widget or the hundreds on Twitch TV, those things aren't contributing uh anything that feels meaningful to me. Okay. So again, don't mean for that to sound too critical. I don't want to um minimize or, you know, uh suggest the work wasn't good. It's just not adding value in the resume when I'm reading it. Overall, I think there's some areas for improvement. I think like if we go back to the resume, one thing that they say deployed over five web apps using Laravel um and this uh JS framework for clients internationally like there's five web apps and there's three bullet points and one of those bullet points is a beautiful chat room overlay, but five web apps. So like I I I think there's a lot more opportunity here, right? get rid of this third bullet and what are the five web apps like tell me something interesting about each and every one of those. I think there's lots more room for opportunity here. So that's my biggest sort of suggestion for this individual in terms of answering some questions aside from you know kind of uh what I might tweak about the resume. One of the things that I have not or I guess two things. The first was around highlighting multiple clients with overlapping tenure. I kind of started to touch on that at the end, but I would note like they have these two, you know, work experience entries here. They're both up until present like in terms of showing parallel stuff. That's how I would do it. what they're doing in this bottom one where they're saying you know five web apps. This is the kind of thing like if you just have a time frame and if it was you know five clients 10 clients whatever like I would call out the more of them you have like the more you have to start kind of being picky and choosy um given how much real estate you have on your resume. I would call them out as like individual things that you can talk about the impact you had or something that was like really interesting about one of those uh web apps, right? You don't have to list all of them. You don't have to try and say, "Yeah, but I did three of them at the same time." Like just bucket them in your work experience. So, just as a as a quick example, right? If all three of these bullet points were talking about, you know, the the top three web apps that had something interesting and I don't know how many clients at the same time, like that doesn't really matter so much to me, unless there was something interesting about how they were operating and balancing a client load. If you want that to be a selling factor for your resume, then you could talk about that as well with the bullet point. But my point in this case is that the sort of work being done in parallel. I think just listing the sub bullet points for the projects that you're working on could be the the best way to do that. The last sort of question they had though was around like leveling. And I just wanted to kind of acknowledge like this is extremely difficult to tell from a resume and no other conversation. to give you an idea um like around considerations and when I talk about this this could be some opportunities that let's say this person has in their mind they're like I I am a senior software engineer I I'm literally not in a position to comment on that if that's how they feel some of the things that I would say like hey these could be opportunities to call out one thing I said in my notes was like how much of what we're talking about here in the work experience how much was built in teams versus you were working like solo as a contractor because in some cases when you're working solo as a contractor your work interactions in terms of getting requirements and delivering on those those could look very unique. In some cases you are trying to interpret the requirements and deliver on something. In other cases you're just being told what to do. If we're talking about building stuff in teams there's some interesting collaboration opportunities, right? So, um I think I would need to understand that better, but that's something that you could call out on a resume like this, right? If I have no idea when I go to read this, right? It's it's an opportunity to convey information. So, that's one thing that I would be trying to gauge. So, for example, if an individual had said like, I built stuff in teams, I've done crossf functional work across teams. These are things that I I need to see in a senior because that would be an expectation I have of them in the role. I need to have some amount of confidence that they have some experience doing that. Another thing I wrote down is like what did stakeholder interactions look like, right? So I was just talking about cross team work but like I don't know have you if you've never worked in a role where you had stakeholders like uh product managers project managers working with other teams um collaborating on projects like if these stakeholder interactions are a really big thing that you end up sort of learning as you're going through your software development journey. So I would I would need to understand more of that to understand the the level, right? For example, if this person had zero of it, then I there's no way in my mind that I could put them at a senior level. Doesn't mean that technically they might not be capable of that. It's just that if they've not demonstrated it, then I would need to see them demonstrate it or have confidence in that before I could go ahead and and qualify them as such. Without any evidence of that, like I I I can't do that with confidence. So then it automatically comes down to midle. Now at mid level, I'm expecting that people are working autonomously. So being able to call out things like hey look I was able to get requirements coming into me and I could go deliver you know on those things with good autonomy that's good but I also want to make sure that I can understand that there's some team dynamics going on someone who is mid-level in my opinion they don't necessarily have to be doing like crossorg stuff that I might expect a senior to but I expect them to be very you know competent within the team and operate within the team and collaborate again I don't see that on here doesn't mean this person didn't do it, but this is an opportunity to call some of those things out. So, if I had to guess, uh, this person would be, you know, operating somewhere on the mid level, perhaps closer to the junior level, but I'm totally speculating and I just wanted to be transparent that it's really difficult for me to know and guess that, but that's how I might sort of go through that thought process in case that's helpful. So overall, yeah, I think some areas for improvement, but I think especially if they have like, you know, five web apps that they were deploying, there's probably a little bit more room to call that stuff out. And yeah, like maybe some of the experience is there, the good work has been done, it's just not called out clearly. So hopefully that helps. Hopefully you found that interesting. And just a reminder that if you're interested in having your resume reviewed, you can submit it to rumé[email protected]. Thanks so much. I'll see you next time.