New Devs MUST Know These TOP Skills to Succeed!

Transcript is auto-generated and may contain errors.

Hey folks, I'm just headed to CrossFit. Um, got to get on the road here because I'm going to be late. I don't know how that happened. Um, we're going to be going to LinkedIn for a question that came in. And um, oh man, my neighbors with all their cars. I can't see anything coming. the uh the person that submitted this question, I kind of let them know like there are already a bunch of videos on code commute like this, but I realized that compared to my other channel which is called Dev Leader, the code commute videos are probably a little bit trickier to search. Um so said I'd go make another one. But in the meantime, because there'll be I don't know a little bit of a delay before this is uploaded. Uh in the meantime, go check the the channel for more on this.

But the question is about as someone who's about to graduate uh or you know has just graduated and maybe they're kind of like they're unable to to secure that first job out of college or university. How do you like what kind of skills should you be building up um to really kind of take that next step forward? Right? So again, if you're in college or university and about to wrap up and you're like, "Okay, I want to get something at like after this and you know it's competitive, what you need to be focused on or if you've just graduated and you weren't able to secure really what you want, like how do you start making sure you can go for that that next step?" Um, so just a friendly reminder, if you want questions answered, leave them below in the comments or send a message into Dev Leader.

That's my main YouTube channel. also my social media handle that I use for everything or you can message Nick Cosantino on LinkedIn and that's exactly how this person found me. So the um the big recommendation I have here is like I think couple things one in terms of how you focus the specifics I would say try to understand what is required for the roles that you're trying to get into. Sorry, I don't I realized I'm like out of breath and I don't know why. Um, so if you like for example, if you like if you want to get into web development, right? Uh, versus mobile development versus you want to be doing like uh work with embedded systems, where you go focus your time and energy will probably look very different. Okay, so I would highly recommend going and looking for the jobs that you're interested in.

And this isn't necessarily like to go evaluate everything about the jobs, but to go scan through job postings and see like what what are the common like tech stacks, like what languages, like all these different things. Try to find patterns. If you're not sure, you could ask like chat GPT or something and say, "Hey, like I'm interested in this, like what would you recommend?" But this is really just to kind of figure out some specifics because a lot of the other advice is going to be pretty generalized and um I think you know if I were to try and say okay well go build some projects you should go use JavaScript and build in React like that would be completely irrelevant advice for someone who's not doing web development uh or who wants to focus, they're doing web development, they want to focus completely in the back end.

So, um just try to get a feel for the area that you want to get into to go narrow down uh language, text stacks, things like that. And that way when we get into this next part, you can have some things to work with. But the next part and this is just going to be about projects ma uh mainly is I think you want to spend time where you can building projects um and that's going to be because you want to accelerate sort of the different aspects of your resume. So when you think about uh job market being really competitive and stuff, right, the the people that have I'm not saying more experience is necessarily better experience, but when you have no experience, like probably some experience is going to be um it's going to come across as better. So, it becomes very hard to compete with other people that have work experience because they've already Oh, don't do that.

Okay. Sorry. So, it was turning left in front of me. Um, yeah, like just being able to have more things on your resume to make up for uh the fact that you're potentially competing against people with some other work experience. It's going to be very helpful. So you have that. The other thing is that genuinely um building skills and understanding and experience using those things. So in some of the other videos on code commute when I talk about this stuff, people are like which projects how do I know what to go build? I think there's a couple different ways to look at the project building and uh I think that most of them are valuable. But you could go build a project that is never going to actually get finished, that's never going to have users, like never mind paying users, um, and you're just building it to put it together to understand the system.

And personally, if I saw something like that on a resume, I think that's great, right? It's not hey I followed the tutorial and like just copy pasted the code like no like you went and built something and like I want to learn about what you learned because I think it's really awesome that someone was like I want to go skill up on something. I want to learn about this technology. Um and you know like in if you're brand new to the industry I I understand like if you don't have the prior experience we all have to start somewhere. There's always there's always a first job. So, okay, like what what have you been doing to go try and learn and get better? And having projects and being able to demonstrate that, I think is very helpful. Um, you could also just be trying to say, hey, I want to go build something.

Um, I already know about I'm just again making this up. I already know JavaScript and React and I wanted to put together something and actually try getting users and and navigating that. Um, that's also something that's interesting, but they're interesting for different reasons because you learn different skills and face different challenges in trying to do that. When you're trying to like commercialize something, right? Like now you're talking about are you talking to users getting their feedback and incorporating that in like the software development life cycle because that's going to take a lot of time and energy versus just someone who's like into the tech stack trying to play around with it. They might be able to dedicate more attention to like the the inner workings of what's going on. So they they have different pros and cons and uh so I don't think like there's a right or wrong answer but I do think that if you don't have experience yet um dedicating time to building projects is going to be extremely helpful.

Um, I know like I I generally have the mindset like, you know, if you're not listing projects, you're building on your resume, like that's a I I kind of feel like that's where the bar is set. Like, it's got to be there. But, uh, I I do resume reviews on my main YouTube channel. And, um, so if you're interested in that, you can go check it out if you search or look for the resume review series. It's just a playlist. A lot of the recent videos are are from that uh playlist. Um you'll see like it's not it's not even the majority of people that submit resumes to me have projects and that's not the end of the world. But in my mind, like that's something that's completely in your control. When people will say, "Oh, I didn't get like uh you know, didn't get to learn about this at my job or whatever else or I don't have experience yet." Or I'm like, "Man, that one is totally in your control.

I realize you might feel like you have limited time. Everyone's got the same 24 hours in a day. And if you need to be able to, you know, push through to have something more on your resume to stand out, I would say like find a way to get some time to do that. It doesn't have to be for the rest of your life every day, but try to carve out some time out of your schedule to make that happen because it's uh I just think it's an easy way to add to your resume that shows that you are interested in learning and that you have been working with different technologies. So, uh in terms of which projects, that's kind of how I would frame things up, right?

is um go through some job boards, look at common tech, ask AI whatever you want, but figure out which technology based on where you want to get into and then make a decision about like if you just want to hack around and try to learn how to glue some of these pieces together, have a working application. Uh in my mind, I think that's probably a better approach. It's not that trying to get users and stuff is wrong or whatever, but I just feel like for most people um that early on that's probably one of the most beneficial things. Did I lose my map? Sorry. I just want I like having the map because as I'm talking and just like driving on the highway like I want to make sure like oh there's my exit. Good. Um so that's probably the bulk of it. Um but I think the other thing that I want to mention is like one of the big like there's there's two things.

One is like prepping yourself, right? and making sure you're building genuinely the skills and experiences that you're going to need. I think that's like in my mind it feels like one of the most important parts of this because that's like actually what matters. But this other part I feel like unfortunately is necessary and that's like you need to find ways to stand out. Okay. So the tricky part is when I offer advice like this and say this is how I recommend doing it. Like let's think about what that translates into because like obviously not every developer is like watching my videos and following this advice. But it's pretty generic advice. Like not to on myself for it, but like what I just everything I said I feel like is relatively generic, right? I believe in it, but I feel like it's also quite generic. And so if you have a lot of people following this advice, because it is generic, probably other people are saying similar things.

I'm not don't feel like I'm special in this regard. Like, okay, so now you have however many new developers coming into the the workforce. They're all going, "Okay, let me pick some like some primitives, some basics from the area I'm working in, and like I don't have the work experience, so let me build some side projects." Like a lot of people are going to be doing similar things. And some people just, like I said, they won't even be building side projects. So if you want to stand out, like I think minimum side projects that's already going to set you apart from other people that aren't doing that at all. So I think that's like that's why I say like I feel like it's a like a baseline expectation because if that one's in your control, do it because some other people just aren't. You can automatically have a leg up.

So that's one. But then you still are going to have a lot of people that are doing that. Uh in which case like I don't know like trying to find ways that your projects are going to be different I think can be helpful. So uh I've I've said before like I don't think like calculator apps or to-do apps are like bad projects. I know everyone's like, "Oh, that's so dumb. Like whatever. You don't learn anything." I'm like, "Dude, you can learn tons. You can add all sorts of complexity into whatever you want to go learn about a technology, right? Like you want to go, oh, calculator is so simple. I don't know. Go write like custom expression tree like syntax evaluation to do formulas and stuff like I don't know that sounds like it might be pretty complicated versus just like add a number or keeping state making sure that you're using algorithms or balancing your parentheses like you can add more complexity into stuff if you want to make it a learning thing.

So, the reason I think like a calculator or to-do app sucks though, and probably probably the only reason is just that like it's probably going to be one of the top things you'll see on people's um resumes. So, like in terms of a standout factor, it doesn't help a lot. Now, like does that does it actually matter like that your to-do app or your calculator app was the best version of that? Like, no. But it's I feel like it's a human nature thing for someone scanning resumes like yes seeing some projects is going to be helpful but then if there's a project where they're like I haven't I've seen a thousand resumes today and I've seen you know 500 of them have calculator apps like this is I haven't seen something like this. That can be just a helpful thing to help stand out. Um so trying to find something unique I think is uh is an interesting opportunity there.

So talked about projects for preparedness for you talked about trying to stand out a little bit. Um, and then the other thing that I I think is worth mentioning before I get to CrossFit here. Someone wasn't happy. They were holding down their horn at someone else. Um, I think the other thing worth mentioning though is uh depending on your time horizon for interviewing and stuff uh and your comfort level, practice your interviewing like 100%. Uh it's a skill in and of itself, right? Like I am guilty of not uh ever feeling up to date on my my interviewing skills. Like if I needed to interview today, I would bomb an interview like for sure and not necessarily on behavioral interview questions. Still would want to practice behavioral interview questions as an engineering manager. That's probably like arguably in my opinion the biggest component because that's what I do.

um if you're trying to like and I know that for engineering managers I get coding questions I think it's stupid uh system design questions more relevant although like for both of those things I literally have engineers on my team that I should be leaning into to go help with that stuff I do think it's fair to ask a system design question to an engineering manager to make sure that if they're trying to help their team and do like help guide them through do the right things, especially if they're getting stuck, that you're at least capable of navigating those types of things. But, uh, asking me coding questions, like, man, I'm very lucky that I code outside of work every day, but, uh, that's, uh, not something I do at work for the last almost 5 years. I don't code at work. So, I would totally fail an interview if I had like, you know, four or five rounds of interviews in a like an interview loop, I would probably completely fail the coding question.

And even though I said because I code every day, guess what kind of coding I don't do every day. I don't do lead code style questions. So unfortunately with that being so common I would completely fail that which is a reason I think it's completely stupid system design I would probably fumble through and again not because I don't work with big distributed systems it's because I feel like a lot of those questions you still have to know like uh a pretty broad set of things like if I'm not working with a messaging queue actively at work I'm probably going to have a difficult time because like most solutions have some type of queuing system in them. Um, so it's tricky.

Uh, behavioral stuff though, like I said, I would probably do uh pretty well just because if someone was like, "Tell me about a time when you had to work with an employee or work with another team." I'm like, "Yeah, it's like that's what I do every day." Um, so point is if you feel like you don't you're not comfortable with that type of stuff, you're going to want to be comfortable by the time you're sitting down to to interview with someone, right? And that's what I recommend is just finding time to carve out dedicated to interview practice. So don't uh don't forget about it. Yes, the projects and stuff are important, but uh the interview practice is going to be key for that that point in your journey. Oh, there is one more parking spot. Nice. Okay, I'm at CrossFit. Thanks, folks. I will see you later.

Hope that one helps. And like I said, there's other videos on this channel already covering that, so you can check those out, too. Thanks. I'll see you later.