What Back-End Skills Do You REALLY Need for Your First Job?

Transcript is auto-generated and may contain errors.

Hey folks, I'm driving across fit in in a second. I'm not physically driving right now. Uh, this one's from LinkedIn. Given your experience, I was wondering if you have any advice on which backend skills or areas, so they said technologies, patterns, tools, etc. I should focus on to better prepare for that first job. I'm learning on uh learning on my own and not pursuing a CS degree. So, guidance from someone with industry insight would mean a lot. So, that was sent in on LinkedIn. Uh, let's get driving here. And as I get moving, should turn the car on, too. It's my wife. You got to close your door. I'm too nervous to hit that. There we go. Um, yeah. Friendly reminder, if you want questions answered, leave them in the comments or do as this person did. If you'd like to be kept anonymous, just send me a message.

On LinkedIn, it's Nick Cosantino or Dev Leader on any social media platform. That is also my main YouTube channel with edited videos instead of these vlog style videos. So, um, this question's come up before on Code Commute. We're just under 300 videos now. So, this kind of topic is is periodically going to come up. Uh I'm happy to kind of chat through it again though because I think every time I get rambling it's a different you know slightly different perspective on it. So um okay so a couple things to to to kind of call out here. Right. So this person is not they're you know nothing about boot camps, college, university, anything like that which is um I'm only mentioning it because when I go to talk through advice and stuff here like that's not going to come up. Um, will that make it harder? Perhaps, right?

I'm not here to say that that's impossible. Um, there are plenty of people that I have talked to, especially I do a podcast on my main channel as well. And, uh, no, you don't need to have, you know, a university degree, college degree. Um, in Canada, college, university are different things, which is why in my mind, I always end up like saying them as separate things. uh you don't have to go to a boot camp. Um do those things help? I absolutely think they can contribute to um you know being more successful at it, but I think it's going to be based on the individual going through it. Like did you actually get value out of it? And the second part is um like for some some jobs when you're applying they like legitimately will say and actually stick to it that you need to have a degree.

Um you don't get to decide that for the company. They do and if that's what they want then that's what they get to put down. So uh doesn't make it impossible but just something to to note. Now I make an assumption here because when people talk about backend um it's like they talk about software being split into front end and back end right which means it's a dichotomy. It's only those two things but um and then obviously like full stack which covers everything. But I I think when people talk about backend they're specifically saying like I want to work on web services. Um, the reason I'm like there is a world of stuff that's not user interfaces that is not it's also not like web services. So I don't I don't know, but I'm assuming this person is explicitly talking about building like web services in the back end.

When it comes to technology, um, the reality is like you can go you could probably do a little bit of homework. I don't know off the top of my head. If you wanted to, you could go do some homework by searching around to see what's the most in demand language. Like if you have literally no preference and you're like, I just want someone to tell me, go do a search online. I don't I'm driving and I don't know and I don't personally don't really care um what the most in demand language is for backend. Like if that's how you would like to direct sort of your learning, then I would recommend that. So, you know, you can build stuff in JavaScript for the back end. I don't personally love that idea. I don't like using JavaScript though. Uh I'm also very biased for C, but you know, depending on what kind of service, you know, you're the language you pick is just a tool, right?

So when people ask what technology and stuff like that, I'm like it honestly it it's it's like once you gain some experience using any of them, you'll realize that you can kind of go between. Well, probably shouldn't have switched into this lane. Um he's sped up. We're good. The uh the reason I'm saying this is like I understand that when people are trying to learn and get started, they want to focus their attention where it's most valuable. Like it it makes sense, but in my opinion, the reality is that there's like foundational things that you learn and you take them with you when you're going to the next thing. Um, you know, people see on on uh on job applications and stuff when they're applying, job postings, sorry, when they're applying that, uh, you know, it'll say like X years and whatever language or this and that.

Like, in my opinion, those are all helpful things because you'll just get onboarded faster, but once you know some of this stuff, it doesn't actually matter at all. Um, to be honest. So if you like and it makes it hard for me to answer because like that's my stance on it. It just doesn't really matter. And then you're like, "Well, that's a crappy answer. It doesn't help me." So then I would just say like the best way to know is to go look at the places you want to work, right? Go look and see what they list in their job postings. Start with that, right? So, between searching online, you could ask Chad GPT um and tell it like search online cuz sometimes you'll get like dated information. Um look at the the job postings where you want to apply. Look at the technology they're listing if you want specifics.

But in my opinion, it's not going to matter long term. I think that's the more important part I'm trying to call out is like you can pick anything, work on it, and then over time switch to other things because you will need to in your career. So, it's not like if you pick one thing now, it's going to be the wrong thing and then you're screwed or something like that. It's just that, you know, the first company you apply to, they might say, "Oh, we were hoping someone had more Java experience." So, sorry. So, I realize it's pretty generic answer, but that's my recommendation is like do those three things. search online for stats, ask chat GPT and ask it to like search the internet and then look at jobs you want to apply for.

Um, a couple other things I wanted to touch on when it comes to like backend software development is like especially if you're truly thinking about web services is like start building an understanding of uh cloud providers um like get comfortable trying things out where you like deploy into Azure, deploy into AWS and have something running Right. Um, if you're running stuff like on your desktop, it's fine. But like I think there's something to be said about understanding some of these environments that you might be deploying into. Even if it is not a like Microsoft, uh, Amazon or Google like Google Cloud Platform. If you don't end up using those things at your first job or maybe you never use them because you're not using those big cloud providers, I think just going through the process of trying to deploy into them will help you in terms of reinforcing your understanding of like I need to go run a web service like what does that mean?

Because it's got to run somewhere and odds are it's not going to run on like a desktop computer sitting in your office. Okay. So, I think that's helpful. Um I I like the reason I'm framing this up is that my suggestion is always like, hey, like go, you know, pick a tech stack, pick a language, and start building like, you know, interesting hobby projects interesting to you that you can go work on. And I recommend that because in my opinion, it's the best way that you're going to learn about the stuff that you need to get experience with because you're going to be interested. You're going to spend the time on it. But that's advice I keep giving.

What I'm trying to do now is think a little bit more peripheral because if you're already doing that or that's the canned advice already that you hear, let's if we talk about some of the stuff that's related but not um it's not directly the thing, then I think that that might be extra helpful for better exposure. So yeah, I would practice like deploying into different environments. Um the other thing is like databases, right? Like if you're going to be working on the back end, um I would make sure that you play around with relational databases and non-reational so that you can understand how object stores work, why you want to use those, when you want to use a relational database. The reality is for the scale of anything that you're building as a hobby, it probably won't matter at all realistically, right?

um unless you manage to have a hobby project that has like you know tens of thousands of users or something which would be super cool for you and that would be awesome but um odds are you're not going to be hitting like real scale issues in any hobby thing you're building but I think that it's an interesting exercise to go through and say hm like this is a hobby project okay if I wanted to build it to accommodate these constraints how like how would I design this? Like those types of exercises as you're building stuff I think are really valuable. Um because the goal in that case is not to just like kind of whip something up as fast as you can. The goal is like I want to I want to practice, right? It's the same thing where it's like, just to give you an example, there's a lot of people that in their careers like when they're building stuff like especially startups and things, it's like they jump to Kubernetes right away, right?

There's memes and stuff about this online. It's like you're a startup with like 10 users doesn't need Kubernetes and it doesn't. But um if you're building a hobby project and just want to practice so that you can see like what is Kubernetes, how does this work? That's that's very different. You're making a conscious decision to go like experiment and try something out versus like I'm making the decision because our software needs it. So I would play around with um different databases in terms of relational non- relational. What comes to mind is like uh you know MongoDB for non- relational. I would say like Postgress, MySQL for relational databases. Um, there's other ones that exist out there. Obviously, not that you need to to memorize these things, not that you need to like, you know, have the syntax like tattooed on your hands. It's just that having some exposure to trying them out and building some things as a hobby with them.

Now, you can include that kind of stuff on your resume, right? If you don't have the work experience to show how you were using this technology because you haven't done a job in this field yet, that's I mean you can't put the work experience. So the next best thing is showing like I don't have that work experience but I built some things using these technologies and have that on your resume. So that would be my recommendation. I got to switch lanes here so I need to focus because this person's not letting me in. Come on, friend. No one. Okay, that's pretty silly. Here we go. This guy's tailgating me now. You don't got to do that. It's the off-ramp, buddy. It's not helpful. Um, the other thing I wanted to mention, and this is going to sound like counterintuitive probably, is that like if you're trying to work in the back end, I wouldn't say like drop all front end stuff.

Like, don't ignore it. And I say that because you're working in the back end, you're likely building stuff that a front end is going to be communicating with. So if you understand how like how access patterns work, right? How how you might want to design APIs, I think this kind of thing is really valuable, right? Being able to say like, oh, I I work in React or I built projects in React. That that alone probably isn't like having that for a, you know, a resume for your backend development. Probably not something that's like, oh, amazing. But I think the experience that you gain from being able to like kind of you know go full stack and actually have some front end communicating with your back end and understanding how that works is is very helpful.

So to give you an example right um like when I build even brand goes which is what I'm building right now um it's it's easy for me as someone who's basically exclusively working on the back end I can say oh I need an API that's going to I'm just making this up list the users I need an API that can list all of their their scheduled posts I need an API that can but if we don't think about it in context of the front-end application, you can run into situations where the screen that you're trying to give data to um ends up needing to make like 20 queries to go get data from the back end. Now, you could instead have like an aggregate service that basically matches like what the page is looking like. So that service on the back end is responsible for getting the data as necessary and then feeding it to the front end all at once.

So like you could design things very different ways depending on your understanding of like of the front end. So I'm only saying this because I wouldn't like specifically hyperfocus only on the back end and then like pretend like there's no such thing as a web front end. Um, so something to think about. But you'll notice in all of the things I'm talking about, I'm basically saying like build stuff. You got to be building. Um, especially like, you know, if you're if you're not going to to college or university or boot camp, you're not putting yourself into uh some of these environments that could help with networking or some of them have like internship opportunities, right? If you're foregoing that, and I'm not saying that, you know, bad idea or you'll never do it. I'm just saying if you're not using those opportunities, you need to find ways to compensate for that.

Okay? So, you need to be building things because you're not spending time in a classroom learning about whatever topics. So, you have to go learn about them. And I'm assuming hands-on is probably going to be the best way. Um, I've seen that for basically everyone. So, it's my recommendation. Uh, I think that's mostly it. I would like as you're building stuff, I would try to keep track of the different technologies and stuff, right? Because don't don't go do this for another year, two years, whatever it is, whatever period of time, and then go, "Okay, now I want to put my resume together." and then like, okay, what are all the things that I've done? Like record as you're going, right? You could even like do a project, find a way to add it to your resume, and then like when you go to work on the next one, like keep adding things there until you're like, "Ooh, I need to start like actually dialing this in like because there's enough projects and stuff, right?

I just I don't want you to get to a point where you're like, "Okay, I'm comfortable to start applying." and then you can't remember anything you worked on. So anyway, hope that helps. Uh, thanks very much for the question. If you have questions of your own, leave them in the comments or send them into Nick Cosantino on LinkedIn or Dev Leader on any social media platform. I'm going to go lift weights. I'll see you later. Take care.