Developer Intern Resume Review: Did They Nail It?!

Welcome to the ré review series. My name is Nick Cosantino and I'm a principal software engineering manager at Microsoft. If you want your resume reviewed, consider submitting it to résumés at devleader.ca. If you have any other additional information that you'd like to submit with your resume that would help me in terms of my analysis, giving you feedback, make sure you send that along with the email. Just a disclaimer, when I go to review these résumés, my goal is to try and provide helpful feedback. So, I will try to call out what I think is good. I will call out what I think could be improved. And at the end of the day, I'm trying to help people succeed. And this is just my opinion. Other recruiters, hiring managers, and other individuals may have different opinions, but people are submitting these to me because they would like my perspective, and that's what you're going to get. With that said, let's jump over to this video's resume that we're going to look at together. Now, this individual has sent over their resume, and they are looking for internship opportunities. So, if we start looking from the top, it looks like they actually have two different sets of post-secary education. So, to me, that stands out. That's pretty interesting. I think that it's cool that they have computer science and something that looks like it's completely unrelated to computers. So, I think that that's actually helpful to have a different background as well. So, that's pretty cool. I like that they have the technologies and languages called out at the top. I've talked about this in other videos and on Code Commute, which is my vlog YouTube channel. The idea around this that I do like is that if someone is using any type of automation to scan through RSés or if you are a recruiter that happens to have to go through a ton of different résumés and you're looking for certain keywords that are standing out or say there is a recruiter that maybe doesn't have a lot of technical depth and they are told to go look for keywords. Having something like this I think can help. What they're not doing in this case is just making their entire resume a bunch of keyword vomit. It's like it actually is something that I can read through, but they do have a spot where they're calling these out. I do think personally that is helpful. Super high level. And I'm going to go into these in more detail, but they have their experience called out for work experience. And the other thing down here at the bottom is they do have some side projects called out as well. So, I like that. Uh, personally, I like having side projects visible on résumés. Historically, when people are asking about different things that they should be focusing on, I do recommend they have side projects, not only for trying to learn and practice and get better. But if you're building things and trying to demonstrate to people that are recruiters or hiring managers, hey, look, I'm building software. I'm building with these technologies, I think that's a great way to be able to call out more, especially if you don't have a ton of work experience. This is one of the ways that you can create some type of experience, even if it's not necessarily professional working experience on Teams. Now, when it comes to this top job that they've listed here, one of the things that I like is that they're calling out the things that they have done. I think that's something that can get lost when people are writing resumes. Often times they will say like, I worked in this group and then from there it's like, well, I don't know what parts you did, right? Like, we did whatever. We did whatever. I am not hiring a whole team. So, it's really difficult for me to know. It might be very obvious to you as the resume writer. But if you're thinking about it from the recruiter's perspective or a hiring manager, when you say we, it's really difficult. So, I like that this person ended up saying the things that they specifically were responsible for. One of the other things that I really like about this is that in this fourth bullet that we have here, they're talking about memory usage, right? Like they're cutting overall memory usage by 100 megabytes. This is helpful because it's like something that is quantifiable and sometimes when we're thinking about this from the outside, right? Someone that doesn't know anything about this particular project, but at least if I'm working in the software space, I can recognize, hey, memory savings, that could be helpful. Now, I am going to be saving my criticisms for after, but one thing that stands out here is I actually don't know anything about how much memory 100 megabytes is relative to everything else. So, that might be something that could be helpful to to call out separately. Another thing that is really helpful is that when they get into some of the details here, so validated machine learning model predictions against manually annotated peaks, generating precision recall metrics and visualization figures. This is the kind of thing that if you are trying to apply for jobs in this space like in this domain, then being able to call out some of these things that might be more specific could be helpful. So I think that's pretty helpful to be able to do. And then another sort of uh quantitative measure that they have at the bottom here. Use proteomics framework to achieve 100% expected coverage and protein fragmentation analysis. So I think that's cool, right? They're able to again call it something quantifiable. This isn't always possible and I recognize that. But I think if you can find those opportunities to quantify things and again when you are quantifying or even if it has to be qualitative, try to think about someone that has no idea about the thing you worked on. How are they going to understand the impact that you're trying to have? That's just something to keep in mind when you're framing these up. In this next one, where they're talking about collaboration with the team, I think that's great to call out. Again, as more junior developers, being able to call out any type of experience you have working on Teams, I think is super helpful. This is something that if you don't have work experience, volunteer experience or experience building things in teams, it can be really challenging to try and call out some of these uh maybe like soft skills or scenarios where you are going to be working with teams at a real company. So like how do you try to prove to a recruiter or a hiring manager, hey look, I got that covered, right? So if you have anything like that that you can call out, I think it's very helpful to do. So that's good. And if you think about what I said earlier about trying to create experiences, right? So I mentioned having a side project listed at the bottom. That's an experience you can create and you don't need other people to do that. However, if you're thinking about trying to create experiences where you're working with others, it's not impossible to do. It's just a little bit more effort. So if you wanted a side project where you're collaborating with others, you have to go find other people to do that. But maybe that means contributing to open source. Maybe that means volunteering on something. There are plenty of options. I just think that the barrier to doing it is a little bit greater. A great point that they call out here is they led the implementation of a postloading feature. So again, being able to call out some type of leadership that might be at different levels in your career, right? This person is going for an internship. So when I think about leading the implementation in this context, I'm not assuming that they're, you know, leading multiple teams and trying to collaborate across an organization, but within their small team that they're working on, they might have taken responsibility for being the one to go design that implementation or actually carrying out the implementation of that work. So I think to me that's a great thing to be able to call out here. And then again like subtly calling out different technology, right? So created the backend infrastructure using Postgress and Java. I think that that's really good to be able to do and it's not like overusing keywords like this sentence wasn't, you know, like 30 keywords and I'm going like, what are they even trying to say? It's kind of like nicely layered in. And finally, another great thing that uh especially I I don't know if like everyone else likes to think about this, but I like to think that if people are calling out some type of testing, then they're thinking about other parts of the software development life cycle. for a intern or a junior. I'm not going to be uh super hard on them if they're if they're not familiar with testing because even when I went through 5 years of university, we didn't talk about testing at all at any point in university. That was something that came up during internships. I was very fortunate to have that. But because of that experience for me, I'm not going to be like bothered if like interns and juniors don't know that just because that's what I went through. But it is nice if someone calls it out especially as more junior like it's like okay at least they have some familiarity with this in terms of writing them in terms of having to think about that as part of the software development process. So I do think that that's good going to their side project, right? So again, calling out some technologies here, Python, SQLite. Cool. Okay. Again, helpful to know. Um it's not going to be something that's overwhelming uh when they're talking about their project, but I think that it's helpful. They talk about some of the features and then in terms of uh being able to look through um exception handling and stuff like that. So it's a quick summary of the project that they built and I think like I said, calling out some of the tech is kind of helpful there. So, with that said, I think I would like to go over this now and try to offer some constructive criticism. And I will always try to make sure that I read in the disclaimer that my goal is to try and be critical. And that's not because I'm trying to pick on anyone. I'm hoping that the people that submitted this because they've seen my other content, whether that's on Code Commute or Dev Leader, they understand that I am trying to help. That's the whole purpose of me doing this. I do not want to make videos where I'm just essentially like picking on people, making fun of their resumes because I don't think that that's helpful and that's my entire goal here. So, with that said, let's try to see if there's opportunities to improve this, right? The first thing that I wanted to call out is that I absolutely acknowledge that all of this is experience that this person is doing and I think that's great. they call out some of the technical details, but one thing that I wanted to call out is that a lot of what I see captured here is uh very specific to this domain of work. And when I was talking through this a little bit earlier and I was saying, I want you to think about being on the hiring manager side or the recruiter side, a lot of what's explained here is so specific to what's going on in this domain that if you are applying to other jobs in this domain, I think that that can work very well. Otherwise, I think that that can actually work against you. Just to give you an example, when I read this part here, okay, this uh this second last bullet in this section, validated machine learning model predictions to me, I think I understand what that means at a high level. Um against manually annotated peaks. Okay, so they're going through some data and they are the ones or you know, someone in their team, someone had to go annotate this data. But then they say generating precision recall metrics. I'm not totally familiar with exactly what that is. I can understand visualization figures and then they talk about where this is published. Um, so like where the figures are published, but like I don't know anything about what this is. The reason I'm saying that is like if I were trying to hire this person in a completely different domain. So say that I was trying to hire them uh for working on an ASP.NET Core web application cuz that's what I'm doing on the side. To me, this wouldn't stand out as something that um seemed relevant. So it's not that it's wrong. It's not that it's bad to include, but when people talk about being able to apply to many jobs and, you know, should I be tweaking my resume? I would say personally, if you are applying to a job in this space, talking about these types of things, mass spectrometry, if you're applying to jobs that are very similar to this, I think, yeah, call out these technical details because it's going to be relevant. But if you're applying to something completely outside of that, this work experience is still very valuable. But if you can change the message around it to be more applicable to other things, then I think that that will land much better. Again, let's go to this last bullet. Use the proteomics framework to achieve 100% expected coverage in protein fragmentation analysis. That sounds cool to me. Um, I could guess a little bit about what that means. Um but like again it's so specific to this domain that for me working in a different domain this would not add any value. Let's go up. I just want to kind of try to call out a couple of other examples. Right. So extracted integrated multiple DLS from an external file reading repository. That makes sense to me. By the way, if it's not obvious, um, what I'm trying to do is call out things that if they seem generic enough to me as someone who knows nothing about this space, then I can make it relevant, right? I'm trying to show you that as someone who doesn't know about this, if you were applying to a job in my space, like what what stands out as something that it's even understandable to me. Cuz if it's not, then it doesn't land with me. And that's not that it's wrong, it's just that it's not useful for me as someone recruiting or hiring. So eliminating redundant dependencies, awesome. Okay. To the toml. Uh cutting over overall memory usage by roughly 100 megabytes. I called that out earlier as like you know that that makes sense to me. Use peak to inspect method names and dependency walker to resolve dependencies before integration. This I understand. This makes sense to me. Um, I think what they're trying to do is call out peak and maybe the fact that they understand dependencies, but like this doesn't seem like that much of a value ad to me to be honest. So even though I understand everything in this one, I am much more interested in this. I'm much more interested in the impact of redundant dependencies. So yes, it cuts overall memory usage, but what let's go beyond that, right? Right. So I had said earlier is 100 megabytes is that a lot you know if the overall memory usage was 10 GB I might say 100 megabytes is like that's okay that's great but it's not it's not much but is there more to that story right this is the overall memory usage great but um we're talking about like DLS and dependencies so does that change anything about the like some type of build time does that change some other factors like what is the overall impact of doing that because yes it's quantitative ative, but me on the outside of this, I don't understand the actual impact that had. So, it's helpful. I think this is a good start, but that's kind of how I would try to change this part. I think this part here is also interesting. So, continuously improve the latest build versions of thespec to ensure OS distribution compatibility after adding or removing dependencies. I like this part, continuously improving things. But like, what does this actually mean? I think this is an example of something that is probably much more obvious to the person that wrote this, which is great, right? Like they they see the value in this and I think that they're on to something with it, but like basically as someone who's not familiar with exactly what's going on here, I don't understand why that's so valuable. What I'm trying to do is call out that there might be a disconnect in terms of understanding. And to you, it might be like, well, duh, man. Like, isn't it obvious? Like, this is this is what it does. this is why I did it. But it's not obvious to me. This is something to think about. Now, other recruiters, other hiring managers, they might be able to, and this is the the case for a lot of things, right? They might be able to extrapolate and go, "Oh, I see that they're doing this kind of stuff. Therefore, I could imagine and then they extrapolate to other things where it might be applicable." But instead of trying to put that onto a recruiter or a hiring manager to try and go figure that out on your behalf, what I'm recommending here is try to change the language and the wording you use to to explicitly say, right? Cuz I like the continuously improving part. I like that you're talking about what it is, right? But what's the impact of that? Don't don't leave me to go try and figure that out. I think that's what I would uh recommend changing in this first part. Personally, if we go down to this next one, like I said, I like the collaboration part. Uh, deploy a full stack social media app. I I forgot to to mention like calling out full stack I think is great. I do think that they do a good job. Again, I might be making an assumption here, but when they talk about these pieces that are below, my guess is that they're saying I did this. Now, if I think about this a little bit more, they did say collaborated with a team of four. Does that mean that this individual was responsible for all of these things that they called out? I know they specifically say led the implementation of a postloading feature. So to me I expect that they are the one that did that. Now with these other ones integrated a search by name feature like I again I want to make the assumption that they did this specifically but this is something to try and think about. It's kind of like general advice, so I'm not necessarily criticizing it here, but something that came to mind is someone who is reading the resume should not have to guess at if it was you or your team that did it because I said this earlier, not hiring the team. I want to know what you did. I think they did an okay job of that because at least on the first pass when I was reading this, I that's how I felt like they were the one doing it. A lot of what's listed in this section. And so I had mentioned the led the implementation part that that seemed pretty good. But a lot of what's called out here are features to me. This is uh a pattern that comes up where people are talking about the work they've done, which is which is good. So not criticizing that part, but something that gets lost when people do that is like just to give you an example, introduce dark mode feature that users could toggle for better visual experience across the site. Okay, so I know why this one's done. It's for better visual experience across the site. I understand why that was put in there. And one of the things I just realized as I was recording this video though, and this is maybe just a formatting thing, very easy to address, but I didn't even realize now that I'm reading this. I thought that they said during a 4-month contract uh that they were specifically talking about this social media application, even though they said full stack applications, I literally just realized social media application there and e-commerce bookstore down here. I might try to find a way to make that a little bit more clear. This is me fumbling it, reading through. I'm just one person, but there's one data point. I'm one person that didn't even realize this just happened because I finished reading to the end of this sentence and was like, hey, wait, there's extra words on the next line. And then I realize, oh, this is a whole separate app from this one up here. So, small detail on the formatting. I think you could probably do something to clean that up a little bit, but that's okay. The train of thought that I was having there was that when we talk about features, I want to make sure that the impact is understood. So, if we go back up to this one, integrated a search by name feature, it says to find and route to existing profile pages within the database. To me, this whole line tells me something you did, but like maybe this might sound harsh, and I don't mean for it to to sound harsh, but like I'll say it this way, like why should I care about that? This single line doesn't give me a reason to understand why I should care. I understand this is a feature you built. You might understand the impact of this and that's great. So my intention here is not to say, "Hey, you built something that's useless." Not the case at all. What I'm saying is I don't understand from reading this single line the um the significance of it. Maybe that's a nicer way to put it, right? instead of putting it on me to go try and think about hm why is this significant because think about this from the perspective of a recruiter or a hiring manager going through tons of résumés I will not be trying to put in extra effort if I have to go through tons and tons of résumés so basically you want to reduce the cognitive load on me in this case as the person reading the resume so that I just get it right away like oh that is significant that is the importance of it another little criticism that I'd like to call out for This right here is like I think created the backend infrastructure using Postgress and Java. Okay, the keyword part I thought was handy was done in a way that was uh not overwhelming. And then it says to ensure efficient data management and processing. This part is kind of like empty to me. And it's not because I don't understand what the idea of efficient data management and processing could mean. It's that again I'm left to sit here and go like well did you accomplish that? Like and what does it mean to have accomplished that? Right? So you picked those things but like what was the end result? You ensured efficient data management processing but but like what was the outcome of that? So to me this like if again if I'm thinking about this I understand that you picked these technologies but you say ensure efficient data management I don't see that there was some like uh I don't know conclusion to that you just stated that you did like so for example you could have listed any two technologies here right you could have said that I use my SQL and C to do this it ends up telling me when I read this line that you use two technologies and that's really all that I know from reading this line it's not that it's bad. I just think that it could be improved to be more specific. Next up, when I read this line here, configure the controller to facilitate integration between the front end and backend components. This just feels like it's a really wordy way to say that you did some work between the front end and the back end. I would just maybe suggest that there's probably a I don't know a different way that you could sort of indicate the impact of that or the significance. So, you do call out range of full stack applications, right? So the way that I might kind of change this phrasing up is something along the lines of like I was successfully able to integrate front end and backend components by you know working on both sides of it or something like that. You can pick your own words, but the idea is like this to me just sounds like you're talking about like you worked on a small part like the controller and then I I know how full stack development works, so I understand that's a point between the front end and the back end, but it doesn't seem to carry a lot of weight with it. So, I think that there's probably a different way that you could phrase that. And finally, on this last line, when we talk about comprehensive unit tests, this prepared comprehensive unit test, I just want to give you an example here. Okay, so I already called out that I like the fact this person called out unit tests and testing in general. How do we make this better? Because when I read prepared comprehensive unit tests, is that because there were no unit tests and you added them? When you say that you added comprehensive unit tests, does that mean that you achieve some type of code coverage? Did you set a standard where code coverage was reached at some level and now through automation it's maintained? What's the significance of that? I don't know. When you say comprehensive, I don't know what you mean by that. Right? This is another example of like I can think of what I imagine comprehensive to mean, but I don't know that from reading what you've written. Like does that match? And now I have some extra cognitive load to try and think about this. In which case, if this is the 100th resume that I've read, I would just read this person can write tests. Okay. But really what might be happening is you're trying to say, "Hey, look, I actually went really far on writing the test suite and here's the level I took it to and here was the impact of that and like I created the infrastructure that other people could easily add test to." Like I think that there's potentially and I don't know this but if there is potentially like more like uh I don't know significance behind this then try to take that opportunity to call it out because like I said I read this and if I'm getting tired of reading through resumes I just read this person they could they understand at least they've written unit tests and maybe from your experience there's a really big discrepancy between just like okay I wrote a unit test or two and like I actually built something awesome. some here. So, just an opportunity that you might be able to improve that. Jumping down to the side project. Um, again, I wanted to mention that I really like that they have something that they built. The problem with how this is written to me is like the only thing I know from reading this is that they use Python and SQLite. I don't get a sense of anything that they learned from it. I don't get a sense of the like the scale of what they built. And when I say scale, and I've said this in other videos before, I'm not of the mindset that if you're, you know, an aspiring developer, someone trying to get an internship or their first, you know, first role, I'm not of the mindset like you need to go try and build an app and get a million users or something like it's just not something I I recommend you focus on. But I do think building things on the side and learning is great. But when I read these three lines, the only takeaway that I have personally is, well, two things. one, someone took the effort to go build something on the side. That's great. And that it's built in Python and SQLite. I don't know if Python and SQLite were already two things that they're already like like that's their jam. That's what they use regularly and they're just like using it or did they go build it to learn SQLite? Like what was the significance of this project? That's something that I would try to think about here in calling out projects in other content I put out. I've said like I don't think that there's anything wrong with saying, "Hey, I built this project. I built it to learn about whatever. Um, I was trying to optimize performance and like here's a thing I did for that." I don't think there's anything wrong with that. Some people I know get worried. They're like, "Hey, it's not a finished project or I didn't get a million users." The anecdote that I like to share with people is that for my very first internship, this was at the University of Wateroo. the person that was putting on the interview said to me or said to everyone, "Bring something for show and tell." The only thing that I really had was I was building this video game that after what it's I don't even know how many years it's been now. It's still not done. It wasn't done then. It's not done now. It's something that's been rewritten and refactored a million times. I haven't worked on it in years still. But the point is that I brought that for show and tell. And this is a little bit different, right? And I realize not every interview is going to have a showand tell time, but the point is that it wasn't done. But this was something that I had spent a ton of time on and the interviewer was able to ask me questions about it, right? For example, like I I wasn't using a database at the time. I think I was just using like XML files cuz I hadn't really worked with databases. And I had said to him like, you know, showed him how it worked. It was a little 2D game. You could have an inventory with items and stuff. It was kind of like Pokémon and Diablo if you know those games. He would then ask questions like, "Oh, like how do you save the state of your game?" And I was like, "I'm currently, you know, writing it out to an XML file." And then I said like, "But something that I want to try and do is maybe use a database. I haven't done that yet, though." So then he would say, "Okay, well, you know, what do you see like the pros and cons to these things?" What was cool in that experience is that I was able to tell him what I had learned and what I was trying to learn. And I reflect on that experience and I've carried it with me. Right? So I always say you don't need to have some project that is 100% complete, you know, shipped to a million users, you're making money from it. You got some projects that you're building and learning on. Like tell me what you're building and learning. Like that is a significant thing. For me personally, I am very interested in seeing that people are trying to build up their knowledge, build up their experience, invest some time, and get better. And the to me side projects are such a good way to demonstrate that. It's also a great way again to add some other technologies in. So I've seen other people saying like hey like I'm a React developer but I haven't used Angular or you know they call out some other tech stack they haven't like spent a lot of time on. Go try a side project. Build something on the side. Be able to try and include that on your resume. But don't just add it to fluff it up. This is a good opportunity for you to say like, I'm going to go spend time and learn this so that I can feel comfortable talking about it on my resume. I really appreciate this person sending this in. I hope that that feedback was helpful. I think a lot of good things going on here. This person was specifically applying to jobs in this space. I think that they'd be very much on the right track here. if they're going for something more general. My biggest piece of advice is try and find a way to make all the details up here more general. Like abstract the important parts so that they're applicable to other scenarios. So, thanks again for sending this in. And a reminder for you, if you want your resume reviewed, please send it into résumés at devleader.ca and I'll try to make sure that I can get to it. Thanks and I'll see you next time.