How to Get a Developer Job – Even in This Economy [Full Course]

This course will help you find a programming job, and it's specifically designed for self-taught developers. Lane Wagner has created some of our most popular courses, and he's back to teach this course. He covers everything from job search strategy, resumes, networking, interviewing, and a lot more. Let's start learning. Look, the job market for entry-level developers is absolutely brutal right now, but that doesn't mean there's no hope. Now, I've personally worked with hundreds of students that are looking for their first programming jobs, and I'm absolutely shook by how poorly so many students are representing themselves as they look for jobs. Now, what that means for you is if you don't make all of those super common mistakes, you'll actually stand out in what seems like a sea of other candidates. So what even is this course? Well, it's a collection of tactics and strategies that I believe will help you maximize your chances of landing that first programming job. So start by making sure that your resume, GitHub, LinkedIn, and personal projects are all up to snuff and optimize for actually landing that first developer job. Now, if you stick around all the way to the end of the course, I'll even talk you through some of the most effective strategies for applying, networking, and even nailing technical interviews. I guess I'll introduce myself real quick. I'm Lane Wagner. I'm the host of the Backend Bancer Podcast. I've been building software for a little over 10 years, and I've actually worked as a hiring manager for the last three. Now, I don't just want you hearing my opinions, so I've actually interviewed over 20 other industry experts just to prepare for this course. You'll be hearing some of their stories and advice directly from them later in the video. I've also been in touch with Quincy Larson himself, yes, the founder of Free Code Camp, which is of course the YouTube channel that you're watching this on right now. He recently published a wonderful free book called How to Learn to Code and Get a Developer Job. I'm going to be covering some of that content in this course as well. The point is, you'll actually be hearing from some pretty amazing people in this video, and I kind of feel bad that you'll be stuck with me for so much of it. Now, this course is actually quite a bit different from the other coding courses that I've published because we're not actually going to be doing any coding in this video, but it's still going to be very hands-on. All along the way, you'll be making updates to your resume, tweaking social profiles, and even adding documentation to projects. There's going to be a ton of stuff to do, so please don't just binge-watch this video from start to finish. In fact, I highly recommend bookmarking the video and taking it a step at a time. Now, everything that you need for this course will be in this video, but if you do want a text version of the course to follow along with, that's available for free over on boot.dev. I'll be sure to drop a direct link down in the description below if you do want to follow along that way. Don't worry, it's completely free to make a boot.dev account, and all of the content for this course, in fact, all of the content on boot.dev is free. A paid membership really just unlocks some of the interactive features that you won't need for this course. And just so you do know, this course is part of a full backend developer career path over on boot.dev, so if you are interested in going from zero to hireable as a backend developer, you can definitely check that out as well. Now, if you do get stuck at any point during this course or want some feedback, there are a few resources that you have available to you. The first is the boot.dev discord community, and the second is the free code camp discord. And if you want to connect with me directly, you can follow me on Twitter at wagslane. You can also check out my podcast back in banter. That's here on YouTube or anywhere that you can listen to podcasts. Now, before we dive into the content, I've got one last thing to say. In fact, it's really more of a disclaimer, and that is that a course about getting a job is fundamentally very different from a course on computer science. Look, there is a concrete correct answer to the question, how do I invert a binary tree? There's not a correct answer to how should I build out my resume? What does a good template look like? So I just want you to go into this course knowing that basically everything we're going to talk about here is subjective. All of the advice you're going to hear is really just my advice and the other guests' advice on what they think are the best strategies for landing a job based on their personal experiences. So just take everything we say with a giant grain of salt. Now, let's talk about how to get your first job. This first chapter of the course is going to be all about overall strategy, right? Some general ideas that if you can put them into place, they'll really help you over the long haul. And remember, we're kind of in this for the long haul. Being that first programming job is quite difficult, like I'm not going to sugarcoat it for you. The first programming job is probably the hardest programming job that you'll ever land. Not in the sense that the job itself is going to be all that hard, but that it's going to be the most difficult job search. Your second job, your third job, it really gets easier over time as you gain more and more experience because future employers will be able to look at your past work experience as sort of proof that you can do the job. Okay, it's story time. Let's draw a little graph along the x-axis. This will be time. And along the y-axis, this will be the likelihood of getting a job. I want you to be able to have a good looking graph. Every person's graph is going to look different, and let me show you what I mean. Let's start drawing, and I'll just use some orange. Okay, when you just start learning to code, the likelihood of you getting a job is extremely low. So you're starting off down in this bottom left hand corner. Now as you progress learning, this likelihood of getting a job should hopefully go up over time. In fact, let me label this, we'll say this is while you're still learning. What can happen that's really dangerous is you might complete some sort of learning program. So that could be you get your CS degree, it could be you finish a boot camp, it could be you finish an online course or a large project, but sometimes what will happen with people that I've seen is you'll hit this wall where you kind of think, okay, I'm basically done learning now, or maybe even to put it more mildly, I've learned enough that it's time to get a job. And when that happens, because you stop learning, the likelihood of you getting a job as time goes on, if you stop learning, either stays stagnant, let me go back to orange, stays stagnant like this, right? Or in the worst case scenario, it actually goes down over time. Because every month that passes, you have a larger and larger gap on your resume, right? If your resume says I completed my CS degree or I completed my boot camp or my online course in February, and now it's September, and you have no work history in there, that starts to get worse and worse for you. So I want to propose an alternative. And the alternative is, once you decide, once you hit this threshold, let's say there's this threshold where you feel like you've learned enough, let's just say it's right there. In fact, I'll draw it over here on the graph. If you hit this threshold of you kind of learned enough that you should start your job search, what you want to do is spend roughly 50% of your time still learning, right? And usually that means building projects. It can also mean doing online courses or tutorials, but really building projects is probably the best thing. And then the other 50% of the time, you should be spending on the kinds of things that we're going to talk about this course, right? Actively going and finding a job, whether that's cold applying or networking or whatever. But if you do that, then as time goes on, the likelihood of you getting a job just keeps going up and up because you're making yourself a better developer with every month that passes. And I want to tell you a little story about this. I got a traditional CS degree and when I was still in school, this would have been about 2013, I met a guy who had graduated with the same CS degree from the same university three years earlier and he was working as a janitor at the local hospital. Now there's nothing wrong with working as a janitor, but of course he had a CS degree. Like he wanted to be working as a programmer or as a software engineer. The problem was when he graduated with his degree, he didn't have any portfolio projects, he didn't have any internships, he didn't have any work experience. So he spent, you know, three to six months looking for a job after graduation, wasn't able to find anything in that period and kind of just gave up. He really experienced that first line that I showed where, you know, when he first graduated from university, he may have, you know, had had this kind of a likelihood of getting a job way up here. But as time passed, it actually got harder and harder and harder and it makes sense, right? If you graduate or finish your program and two years down the line, you're still looking for work, but you haven't really done any projects or any freelancing or any, or just hadn't had a job in those those two years, it kind of looks a little suspicious on your resume. Employers look at that and they go, well, why hasn't anybody hired this person the last two years? Maybe I shouldn't hire them either. So anyways, this freaked me out quite a bit, right? I'm looking at this guy who's three years graduated from the degree that I'm currently in. I'm like, am I in the wrong field? Am I going to be able to find a job when I graduate? Turns out I really didn't have too much of a problem. I had to put in a ton of legwork, you know, I probably put out 50, 60, 70 applications when I graduated. I got kind of a part time job in my senior year and I built a ton of projects on the side, capstone projects, but really, you know, my goal the whole time was just to make sure that every month that passed, I'm becoming more and more and more employable, right? So you don't get this kind of trough of sorrow after you complete your learning. And as we all know, you never complete your learning as a programmer. Like that's an insane notion. So I really want to get this idea of the threshold in your mind, not as a threshold for you to stop learning and start doing your job search, but just as a threshold that you hit and now you start your job search while you're still learning and building. So to give you a rough idea of what you should practically do, let's put it like this. Let's split up your time into learning and building, some of your time over here. And then on the other side, we'll say applying and networking, really just anything, any activities that have to do with actually, you know, doing the job search. So learning and building, where before you were maybe spending 100% of your available time learning and building, right? So you had 100% of your time here and you had 0% of your time here. Like this makes sense when you're still very new, right? When you've only been learning to code for like a year or less, like you definitely don't want to be wasting your time applying and networking. But when you do hit that threshold where you feel like you're qualified for junior positions, whether it's front end, back end, full stack, doesn't matter, once you feel like you're confident and ready for that junior position, you don't want to do this, right? You do not want to switch to 0% learning and building and 100% applying and networking. And I recommend somewhere around 50-50, and it depends for everyone. But you want to be splitting your time amongst these two tasks. And this doesn't mean every waking hour of the day, right? You've got 8 hours sleeping, 16 hours awake, that doesn't mean 8 hours learning and building and 8 hours applying and networking. What it means is whatever time you have available to dedicate to your future career as a programmer, that's the time you should be splitting, right? If you have a full-time job already and you can't quit because you need to pay bills, like I probably wouldn't even recommend quitting, maybe you've only got a couple hours at night every night and a few hours on the weekend. Let's say 10 hours a week or 20 hours a week, that's the time that I'd recommend splitting between learning and building and continuing to apply and network. Now the next strategy that I want to talk about, again, not a nitty-gritty tactic, we'll get into those later, but kind of a high-level strategy that will inform a lot of the other stuff that we're going to do in this course as we learn how to get a job is signal versus noise. Okay, what does that mean? Let's draw it. Have you ever seen a heartbeat monitor? The heartbeat monitor usually looks something like this. You've got this little squiggly line and then it shoots up when a heartbeat happens. It kind of goes back to baseline and then it shoots up again on the next heartbeat. This is how doctors monitor your heartbeat in hospital. You've probably seen it in movies. Well, these big bursts or these big mountains in the graph represent signal. This is what the doctor cares about. He wants to know when do the individual heartbeats happen. These other parts down here, this little squiggly stuff that happens along the way because it just goes up and down very slightly, that's the noise. Here we've clearly got a signal and then all this crap that's just kind of, again, just kind of little squiggly ups and downs in the graph, that's just noise. When we talk about signal and noise, we're kind of talking about what we care about and what we don't care about. We want signal, we want to know when something interesting is happening, something that we care about is happening, and we want to kind of ignore the noise. It just doesn't matter very much. There is an analogy here, I'm not just teaching you about heartbeats for no reason. When you're looking for a job, and this really applies to any job, but for us we're talking about programming jobs. When you're applying for a job, your primary objective should be to provide as much signal as you can to your potential employer that you're a really good hire. Your employer is trying to sift through a ton of noise. They're getting 50, 60, 100 applications. It's super noisy. They're trying to dig through very quickly many, many applications, many resumes, and they're trying to find the signal. Who is the best in class? Who should I hire? You should be thinking, how can I provide upfront signal to this potential employer that I know what I'm doing? You don't want to have to make them dig through every nook and cranny of your GitHub profile before they find something interesting that you've done. You want to put the interesting things that you've done front and center. You want to call attention to them. You want to make it as easy as possible for anyone who might hire you to find out that you've done some incredible stuff, that you've built some really cool projects and that you know what you're doing and that you're the right person for this job. To reiterate, noise are the little bumps on the graph, the little bumps that can be potentially confused for signal, and they're what makes it hard for the person who cares about the signal to find the signal. Your job is to make everything that's impressive about you super obvious and to stand out from the rest because that's really how you're going to land that first job is just by standing out being impressive and making it really, really easy for the person who's eventually going to hire you to figure out that you're the right one because they have a ton of noise to sift through. So you're probably sick of hearing from me at this point. Let's cut over to my friend TJ who I had on the Backend Banter podcast to talk about exactly this idea and how projects can provide a lot of signal up front. Yeah, I think there's sort of a two-fold way that you get helped by doing open source stuff. The first one is I think when you actually build something, you accelerate your learning a lot. So by actually doing, you learn a lot more than just by reading or taking a class or whatever. Not that those things often provide you sort of the baseline that you need to be effective at building, but then eventually you need to move on to building things. So that's like the one side is you do learn a lot of new things, and then the other side is it does open up connections, and in a lot of ways it's a much easier thing to put on your resume because you can point to something that someone can go look at instead of just like saying, well, I worked at Corporation X for three years, I was managing several projects that shipped and delivered on time, and everyone's like, okay, but I don't know what any of those things do or look like or whether they're still running, all I have is your side of the store. So if instead it's like someone is out there using your stuff that you make, that's a big signal to say that you're able to ship code that people find useful, which ultimately, like unless you're writing Haskell, that's sort of like a goal of the company, I think. Now the last thing I'm going to say about strategy before we start diving into some more nitty-gritty tactics is that nobody's going to give you a job out of pity. I don't know a better way to say that, I don't know a nicer way to say that, but I've met people online who seem to think that the best way to get a job is to write a big sob story about how no one will give you a job and to send that to hiring managers, right? I've worked as a hiring manager and I've received kind of these sad stories, and they are sad like it pulls at my heartstrings that someone spent all this time learning code and they're having a hard time getting a job, like that is sad, but that strategy, right, of sending out what are essentially just sad stories about how you can't find a job, that is a terrible strategy for getting your first job, I've literally never heard of this working. And the reason should be fairly obvious, if I'm a hiring manager and I have a new job that I'm hiring for and I get 20 applications, and one person tells me you should hire me because I'm having a really hard time and I really need this job and nobody else will hire me, if I'm trying to be fair and objective and not discriminatory in my hiring, it is my job to hire the most qualified person. Now that message they sent me might not outright disqualify them, but by them coming forward with the idea that nobody wants to hire me, that's anti-signal, that's really bad, right? That's just telling me, that's just giving me social proof, it's like an anti-testimonial, it's giving me negative social proof that nobody wants to hire this person, why should I want to hire this person, maybe they're not very good. So rather than try to get a job out of pity, you really want to come to the table, right, you really want to put forward on your resume, on your social media, like you want to put forward this air of confidence, because that's what people that are hiring you want to see, they want to see someone that feels confident that they can add value to the business and that they are the best hire, that's what's actually going to help you get the job. So try to be confident, I know that can be hard, especially as a junior developer, maybe you're not super confident in your skills, but that also ties into why I said really as you're searching for a job, you should be continuously learning and building because nothing builds up your confidence like having some really amazing portfolio projects that you can show off, something tangible that proves that you know what you're doing. So you don't need to be a jerk, right, you don't need to be cocky, but you do want to put forward this air of confidence. It's like any negotiation that you've probably seen in the movies, right, you don't want to come to the negotiation table acting desperate because then you're going to get a really bad deal or frankly no deal at all, right, you want to come to the table with confidence that you can add value to your future employer and that's going to be what helps you the most. It's time to get your portfolio projects in order. Now, everything we do in this course, build a resume, work on github profiles, LinkedIn profiles, none of that will work if we don't have a really good project or two that we can optimize and make look really good because that's really what we're going to be showing off in all of those other places. Assuming this is your first programming job that you'll ever have, you need a stand in for work experience, right, with your second, third, fourth programming job, the best thing on your resume is your previous work experience. If you don't yet have a job on your resume, the best thing you can have are great portfolio projects because they kind of act as a stand in for work experience. The hiring manager can just go look at the project and see if you know what you're doing. Now, I want you to right now choose one project that's going to be your main portfolio project. Most hiring managers don't have time to look through 20 or 30 different github repositories. They're going to want to look at one project that you've built and honestly, a lot of the decision making that goes on inside their head is going to be based off of that one project. If you don't have one yet, that's okay. I'm going to spend some time in this chapter talking about how you can choose a good project or how you can enhance an existing project but just keep in mind, you might want to pause this video, bookmark it when we're done talking about that so you can go make all of those enhancements and then come back and finish the rest of the course. So assuming that you either have a bunch of projects and you need to pick which one's going to be your main portfolio project or you don't yet have a good project, let's talk about a couple rules of thumb for picking a good project idea. The first one is that you really want to stand out so you don't want this main portfolio project to be something that you followed a tutorial for online, like that's a huge red flag. It's obvious when you built something through a tutorial. You don't want it to be something simple like a Spotify clone or a Twitter clone, you really don't want to be a clone, that's not very interesting. You also want to avoid really common types of projects like tic tac toe games and to do apps. You want to choose something that really stands out and is unique. I really can't stress this enough. When someone's reading your resume and looking at your projects, the only thing they're going to see is like a one line description of what your project is and you kind of want that to grab attention. If it's something that solves a real problem that you experience in your life, especially if it's a unique or interesting problem, those are the kinds of projects that are a good candidate for your portfolio project. So let me tell you about a project that I did when I was in college that I think is a pretty good example of something that's unique. I wrote a Python script that took as input an mp3 file and as output generated sheet music of, well, a drum beat, it was actually a pretty simple program. But that's the interesting thing, your program doesn't have to be the most sophisticated piece of technology ever written, you really want to maximize for the interesting factor because that's what's going to get someone reading about your project and calling you on the phone to talk about it more. This project that I built, you essentially would sit down and you could play a drum beat into a microphone, throw that mp3 file through my Python script and it would spit out a semi-accurate version of what that drum beat would look like in sheet music. It wasn't the most accurate thing, it certainly wasn't the most useful thing, but it was something that was interesting and it did work. So it got people when they were looking at my resume to ask follow up questions about the project, like, oh, that's really interesting, I've never seen anything like that before, like what did you use to detect the loudness spikes in the music, did you use any libraries, what did you import, right? It got us talking about the project and that's really the position that you want to be in. So try to think of something that's interesting, right? I also built a Starcraft 2 battle simulator at one point, again, not a sophisticated piece of technology, it was a Python script and it had hard coded values for all of the different units in the game, right? Marines do 50 damage per bullet and marauders do 75 damage per bullet or whatever it was. It was just a command line tool, right? It didn't even have a front end, it wasn't a full application, but again, it was interesting, some of my interviewers liked Starcraft, so it was something that we could talk about. So really try to come up with something interesting, unique and something that's big enough that you do have to solve some technical problems, because again, when people do ask the follow up questions, you wanna be able to have somewhat of an interesting conversation about code. So the next thing I wanna talk about is kind of just opening your mind to all of the different types of projects that you can build. If you're a front end developer, you might be thinking, well, you know, I could build like a portfolio side, I could do something with HTML, CSS and JavaScript, and if you're really focused on front end development, that might be the best option, although you'd probably want to build some sort of interesting web application. If you're a back end developer, there are some other options that I want to open your mind to. So for example, this is a library, right? Which to be fair, you could totally do a library on the front end and publish to NPM. But in this case, this is a Go library that I built that actually helps me get a job as a senior developer. And the interesting thing is, this is actually an incredibly simple library. If you spent some time looking through it, assuming you have some basic familiarity with Go, you'd be like, wow, I could build this, this is actually no big deal. But it's kind of cool because it demonstrates, A, that you know how to code. It's naturally interesting to Go developers because it's about performance in the standard library, which is kind of interesting. It also demonstrates that I know how to design a decent API, which is something, and when I say API, I don't mean like a REST or a CRUD API, I mean like a good library API. Like I know how to encapsulate the complex logic and expose only the parts of the library to the end user of the library that I want to, right? So there's like some pretty interesting things going on there. But it's also inherently very unique, right? It's not like a to-do app or something like this. So anyways, the purpose of this library is actually really straightforward. Basically the standard time.time type in Go can take up to 24 bytes of memory, which is quite a bit. And that's kind of needed for some of the advanced features that it offers. But I wrote this library because in this library, a timestamp only takes four bytes of memory, which is significantly less, right? You can save like 80% of your memory. But it does have the limitation of it can only represent timestamps from the year 1970 up to 21.06, right? But it's a fairly well-designed library, if I do so myself. It matches the same API. It has all the same functions and methods as the standard time.time. So the point I'm getting at is I really think you should consider building a library. If you've built a lot of applications in the past, building a library is a good way to stand out. Again, most applicants don't build libraries. They just build applications. So something to think about. Another thing you should consider, again, especially if you're looking for more kind of backend or data-related positions, is a command line tool, right? You can avoid all the complexity of HTML, CSS, and JavaScript if you're looking for backend positions by building an interesting command line tool that generates maybe an interesting report, right? Maybe it pulls data from different sources on the web and generates a really nice Excel file or Google Sheet as output. Anything dealing with interesting or esoteric data, right? You can think of video games are always an interesting source of data or various APIs, like stock APIs. Think about what you could do with a command line tool that can also be a really great source of inspiration if you don't want to just build another web app. So to sum up, you've probably built a lot of projects. Some projects are good for learning. Things like Spotify clones or Twitter clones or, you know, to-do apps. They're good for learning. They're not good for your portfolio, right? So spend some extra time. If you don't yet have a project, get started on one, bookmark this video, come back when it's ready. If you do have one, just try to pick one that's kind of going to stand out on the page, has an interesting title. Now, we're going to cut to another clip from the backend banter podcast. This time, Theo Brown was my guest and he explains not only why building projects is one of the best things you can do for networking, getting to know people in the industry and generally just getting noticed in order to get a job, but also how building projects is the best thing you can do for your own personal learning, especially once you already have an understanding of all the fundamentals. What I recommend for beginners always, I have a video I made called your goals kind of suck because as beginners, as engineers in general, we suck at goal setting and that's the thing you should be focused on is setting realistic goals that aren't necessarily about the code because I want to learn JavaScript. I'm going to be a JavaScript engineer. That's a goal. That's an absolutely terrible, you're going to fail type goal. That's like imagine a skateboarder says, I want to be a professional skateboarder. No, you don't get good because you want to be a professional. You get good because you have specific tricks you want to learn and you're down to hit the ground over and over again until you get good at it. You certainly don't get good at skateboarding by watching a bunch of skateboard tutorials on YouTube and thinking about it all day, or certainly not going to university and sitting in a class where somebody tells you which chapters of a book to read about skateboards. You get good by getting your reps in. You got to hit the ground over and over again, trying to do something specific. A good example of a goal for an early engineer is, I really like this video game. There's some math in it that's annoying to do. I want to build a calculator to keep track of these events in this game. That's a fantastic first goal because you will know when it's done with a traditional like the common type of goal, like I'm going to learn JavaScript. When are you done learning JavaScript? Because I've been writing JavaScript for 15 years now and I'm not done learning JavaScript. It's so important to have that natural, I have achieved my goal, like end point, and I find that most goals for engineers, especially beginner goals, don't have a point where they can reflect and say, yes, I have achieved this, which makes it a bad goal. I'm a massive advocate for project-based learning, especially in this field. I would argue in almost all fields, it's a strong way of doing things, but in software dev in particular, it's the only way you're not going to go insane. You cannot learn Golang. You can learn how to build X in Golang. You can build X in Golang and use X and be proud of it, but you can't learn Golang. You can't learn JavaScript. You can't learn these things. You can learn how to use them for specific things. Absolutely. Almost all the best engineers I know are people who only learn to code because they had some specific problem they had to solve. One of my favorite engineers is an engineer named Jason Dokden. He's the founder of the URL mental health charity. He's a certified therapist and got into mental health through his World of Warcraft guild that became a charity that now became this huge way for people to get their first therapist and help them out financially if they need it and organization-wise if they don't. It's such a cool org. I love them. He started looking into getting a website made for them and the lowest he could get for a charity's website was $400,000. He's like, it can't be that hard to build a website, right? And taught himself from scratch modern web dev and now he's like one of the best Tailwind engineers I know. He's really into typography and typesetting in particular. He's just nerdy about it and like regularly files PRs to my projects just fixing things. He's the best. And he like onboard himself to that point in under three months solo. And he had one engineer friend who used to work at Twitch with me that he quickly superseded and that friend was like, yo, man, I'm sorry, you know more about this than me now. Can I put you in touch with my friend Theo? He might be able to help because you're using this next JS thing. So you got thrown into my circle. He was still using vanilla JS. So he rewrote his project and typescript over the weekend. He became a huge typescript advocate after that point, but like he got good because he had a problem to solve and he knew when it was solved. He needed a website for his charity so that people could sign up, join the guild and do what they need to find a therapist. And he had that very noble driving goal pushing him to learn how to code. And there's no way you can do better than that. And then I just want to reiterate, one project is really what you should be focused on. It's okay to list two or three projects on your resume, but there's, you really should be spending the majority of your effort, the lion's share of your effort on one single project because one really impressive project is way better than 10 mediocre projects, right? 10 or 20 or 30 kind of lackluster, low effort projects are not going to land you a job, but one really good project definitely can. So once you're done with your project, all the code is written and you're really happy with where that part of the project is at, the coding part, it's really important to document the project and put it somewhere publicly accessible. When I say document, what I'm really talking about is a read me. So I'm here on this lesson in the course on boot dev that talks about the read me. And I really just want to show you kind of what the sections of a good read me look like. So I would argue that in almost all cases, your projects read me should have a great title, a great description, a section that talks about the why of the project, right? The motivation, the goal, the thing the project is doing. That's hopefully interesting. How to quickly get started with the project. Even in the case of a library, it would be like how to install it, right? NPM install or go get or whatever. And how to start using it in your application. If it's an application, it might be like, Hey, I'm publicly hosting this at this URL. You can go look at it, right? Or it could be instructions for how to clone down the repo locally and run the project, especially if it's like a CLI tool or something like that. A usage guide, so this is actually like a more in depth guide that goes through some of the more granular features and details of the project. And then this one's kind of optional, but a little section of the read me that explains how anyone could contribute to your public repository if they want to. So first, let's talk about your project's title really quick. This is actually something that a lot of new developers swing and miss on. The last thing you want to do is make your title downplay or undersell how interesting your project is. So for example, if you made a to-do app, the last thing you want to name your project is toy to-do app or test to-do app. It makes it look like it's just something that you were kind of doing on the side to figure out or, you know, it's something that you were doing for learning purposes when really you should be building a project that can be used in production that you're proud of. Remember, your goal here is to communicate to employers that you can build production ready software. If you built a project that, I don't know, zips up directories and you know, .zip extension and compresses them in some weird way, don't call it test-zipping-cli-application, call it zippy, right? Something memorable and personal and that makes it look like a real project. So your title is just the name of your project. Your description should be like one, two, or three sentences that just explains what the project is and it should really be as simple and as clear and concise as possible because the person reading you read me, like you've only got a few seconds to grab their attention so you really want to nail this description. And again, please refrain from downplaying your work with using words like just or test or practice, it ruins the whole field. We're going for production ready project. That's what we're trying to put out into the world. So for example, if you had an app called Zipzod, you might write, this is Zipzod, a command line tool for zipping and unzipping files with an ultra-low memory footprint, right? Very clear, very concise, says what it does, has a bit of personality. This is the kind of description that you want. In fact, I'm going to jump over to, this is one of my personal projects, actually, Go Rabbit MQ. It's a, well, I'm not even going to tell you what it is in my own words, I'm just going to read the read me, right? So my title is Go Rabbit MQ. It's actually not the best title ever. It's extremely descriptive. This is a Go client for the Rabbit MQ message bus system. I could have been more creative here, made it a little more fun, but the description's not bad. It says, wrapper of Rabbit MQ AMQP Go, which is a well-known AMQP message protocol library, that provides reconnection logic and sane defaults, right? That's all it is. It wraps this other library and it provides reconnection logic and sane defaults. We're going to cut to my friend James Q. Quick, who I had on my podcast, to talk a little bit about why you really should not use words like just or toy to describe your project. I want to keep those out of our titles and descriptions. Yeah, I love that you brought up like people early on applying for roles and which side of the humility and confidence they maybe lack or have too much of. And I, so for context, I've taught two rounds of a bootcamp called Launch Code. And this is, we start at like 150 people and we usually graduate at like 50 or 60. It's meant to be like a big numbers thing. And then how many people make it through and it's free curriculum for people. And it's a big involvement and like engagement anyway. So I've taught 300 plus students through bootcamps over the course of a few years and consistently across the board, I always tell people you need to be more confident. And again, this is a practice thing. You need to talk about yourself more confidently because I've almost never in my experience of teaching bootcamp students, found someone who sounds conceited. Like in this, in this transition period, they're starting at zero, right? Like they're starting and this is not something we encounter much as adults, right? Like as kids, we learn new sports and we try to play the piano and we do all these things. As adults, we very rarely start from level zero. We're not used to, we're not used to doing that. We're not used to feeling like we're at the bottom of the barrel again. And so almost, I mean, I can't think of a person in my teaching career that I thought, hey, you need to tone it down. Like you're gonna, you're not gonna, you're gonna turn people off by the way you talk about the things you've done and the things you've learned. So yeah, practicing that confidence and that really just comes down to practicing how you talk about yourself and the things you've done and nitpicking with words that you use. The easy one that I talk about a lot is the word just, I just built this. I just learned how to do blah, blah, blah. And that diminishes what you've done, like very subtly, but it shows me that you don't have a lot of respect for what you've done. And that's something, one more aside, and then I'll kind of pause. I run a discord community called Learn, Build, Teach. And this has been like a philosophy of mine for several years of like, we spend lots of time learning. As developers, we use what we learn to build stuff and then like teach other people too. And it's a great way to continue to learn. And we have, we have an event on every Friday morning and it's called Wends of the Week. And it is specifically geared towards people celebrating their own wins because most of us don't spend enough time reflecting on the good things that we've done, right? Like most of us finished the week on a Friday and we reflect back and we're like, Oh, I didn't do this. I didn't do that. I didn't get as far as I wanted to with this. And we rarely ever flip that to just appreciate, well, here's what I did do. And that's still a good thing. So that's what that time is specifically dedicated for is because most people, including myself, most of the time, don't take the time to really appreciate the things we've learned, the things we've built, the things we've taught other people go in kind of full circle there. We just don't take the time to do that. And I think that has, can have a significant influence on how you talk about yourself and how you show up specifically when it comes to interviews. So hiring manager has come to your portfolio project on GitHub and they've read your title and your description and they haven't lost interest, which is really good. The title and the description need to be fantastic, right? If those aren't good, you're going to lose the person immediately and they're going to, they're going to go away. They're going to go to the next applicant, right? But if those are good, the next section that they should find is a why section or a like motivation or goals. And really the purpose of this section, it's just like one or maybe two paragraphs of text, but it explains why this project needs to exist in the world, right? What inspired you to create this project? What problem is it really solving? So I wrote up this little example given our zipzod project says there are a lot of ways to zip and unzip files, but none of them use so little memory zipzod is the zipping tool you need for working on low memory devices like raspberry pies. I use a raspberry pie as a home server and I was frustrated by my inability to easily manage large files on a small device. So I built zipzod, right? So if you can tie in like a personal story, right? I use X and it had me frustrated for Y reason. So I built this project, right? As software developers, our job is to solve real world problems. So even if it's a small problem that your project solves, if you're solving a real problem, that comes across really, really well to hiring managers. So try to think through the motivation. And again, maybe this means going back to the drawing board and building another project. That's not a problem. Learning and building will always continue to make the job search easier and easier, but just make sure that you have a really good Y section in your readme. I want to show you another example of a motivation section on a readme that I thought was really good. So I'm on the HTMX repo. HTMX is a front end library for building ironically, kind of server side web applications. But anyways, it's a great project. And I'm going to go ahead and scroll down to the motivation section. And it says, why should only a inform tags be able to make HTTP requests? Why should only click and submit events, trigger them? Why should only get and post be available? Why should you only be able to replace the entire screen by removing these arbitrary constraints? HTMX completes HTML as a hypertext. Fantastic motivation section. Let's take a look at one more example. So this is the Python WebSockets library says, why should I use WebSockets? So notice they changed the title, right? They didn't call the section motivation or goals. That's okay. But the idea is the same, right? The idea is the same. We're explaining why the project was built, why it needs to exist. Okay, they say the development of WebSockets is shaped by four principles. Darkness. WebSockets is heavily tested for compliance with RFC 6455. Continuous integration fails under 100% branch coverage. And just a note here, like you want to do good markdown. Like this is a nice markdown ordered list. And here we've hyperlinked, you know, we've hyperlinked some anchor text. We're not just pasting in a big nasty link. So make sure you format things nicely. Simplicity, all you need to understand is message equals await WebSocket.receive and await WebSocket.sendMessage. So here we're just saying like, look, we wanted a really simple way to work with WebSockets in Python. And this is the simple API that now exists because this project robustness WebSockets is built for production. For example, was the only library to handle back pressure correctly before the issue became widely known in the Python community. This is a great example of backing up your claims. Anytime you make bold claims about, you know, performance or something like that, you're going to want to link to the source so you can so you can prove that. And then finally, performance memory usage is optimized and configurable, a C extension accelerates expensive operations. It's precompiled for Linux, Mac and Windows and packaged in the wheel format for each system and the Python version. So this is a little longer than you probably will need for your personal project. But notice, it's still pretty concise, right? And this is this is actually quite a large project Python WebSockets. So keep it concise. But get the message out, right? This project needs to exist because like, okay, next, let's talk about the quick start section. Now, I want to point out at this point that when a hiring manager is reading through your projects read me, it's actually unlikely that they're going to take the time to like clone your project, run it, all that kind of stuff they might they might do. And so I mean, you want your project to work, like I'm not saying it shouldn't work. But I just want to prepare you for the idea that, you know, title, description, motivation, the reason those sections are so important is because a lot of the people that are perusing your project are not actually going to take the time to clone it and run it. But that is the purpose of this section is to make it super easy to use it or at least super easy to see how it would be used, right? So let's take a look at a quick example. I've actually included the the raw markdown or an example quick start section section of your read me just in case you're still a little fuzzy on how markdown works. Okay, so we've got the quick start heading. And underneath, we've got another heading, it says install zipzod using the go tool chain. So this is, you know, a code block that someone can very easily copy and paste into their terminal to install zipzod and then run zipzod with an input directory and an output file. So just very basic usage example, this is a fantastic quick start, it's only a few lines of code to copy and paste into the terminal, and then whoever's using it is up and running with your project. Now, if your project isn't a CLI tool, but it's instead a web app, then I would recommend hosting it somewhere on the public internet, right, because then your quick start section gets even simpler and even easier, you just kind of link. This is a markdown hyperlink, right, kind of just link to your live running app, and maybe add some explanatory text like upload your file, you get a download link when it's done. So here's a real world example of what I'm talking about. This is the discord go, the go client library for discord. It's actually just a community library, but it's probably the most popular one. And its quick start guide is kind of broken down into a couple of different sections. But again, the idea is the same. So got this installing section. It's got a simple command I can copy and paste into my terminal to install discord go. And then the usage is like, okay, just import the package at the top of your go file. And here's some code that you can copy and paste into your app to get going with the discord client. Next up is the usage section. And deceptively, this might feel a lot like the quick start section. But this is really where you want to brag about any advanced features or special things that your app does. You don't want to get technical with the description. So in the case of a command line tool that zips up files, you might have a list of all of the different available flags that your command line tool supports, right? And you'll probably want to include a bunch of examples of how somebody can go about using all of those different options. So again, here, we're just going a little bit deeper. And I would argue that for a personal portfolio project, what you're really trying to optimize for here is you want to show off all the cool stuff you built, right? It is about helping users of your project, like you do want the documentation to be accurate. But at the end of the day, you really want to be showing off, look at all this cool stuff that I built. The last section I want to talk about is the contributing section. So this one should probably be at the very bottom of your read me. And there's a couple of goals here. One is when you add a contributing section, there is a chance that other people out there online will find your public repository and want to contribute changes back to it, which is super cool. The more attention your repository gets, the more stars it gets. Like that only helps you, right? You're maintaining a larger project that looks more impressive, frankly. But the second reason that you want a contributing section is so that you can explain to hiring manager or really, frankly, anyone that's reading your read me, how they can actually get involved with the project on a technical level, like if they wanted to pull down and run the code, right? So the usage section and the quick start were really about being a user of your project, right? Which in the case of a library is pulling it down and running the code, but in the case of like a CLI tool or a web application, they may not interact with the code at all in those sections of your documentation. So this section in the case of a web app might actually be cloned down the repo and run, you know, NPM run dev to get a local development environment up and running. So we're trying to show them how to run the code and really what's going to happen is if they're really interested in you, if they really like your project, they might actually clone down the repo, run the code and poke around through all the different code files in their own development environment. Like this is something that I've done as a hiring manager when I'm really interested in a project because, you know, I read through the rest of the read me and it really piqued my interest. I certainly don't pull down every project of every resume of every person that applies for my jobs, but when I get to the point where I'm ready to call someone to bring them in for an interview, I might pull down their code and actually poke through it. So let's take a look at this example, contributing, heading, first step, clone the repo. And I really like when the instructions are super explicit. Like it's impossible for the person reading your documentation to mess up, right? Like we've spelled out the entire git clone command. We've told them to change directory into the directory. Once they've cloned it, we've given them the build command, right? In this case, this is how you run the project locally. This is how you run the tests. If you want, here's a description of how to submit a pull request, right? Be very detailed and very explicit. The last thing you want to happen is for someone to be super interested in your project, clone down your repository and not be able to figure out how to get it to compile. They might even at worst think your project is broken because they can't get it to compile and run. So you really want to spell this out and make it as simple as you can. It's time to talk about GitHub profiles. I'm a big believer in GitHub when it comes to your job search. If I had to stack rank LinkedIn and GitHub in terms of which is more important for your job search as a programmer, I think I'd actually put GitHub above LinkedIn in terms of if you could only have one really good one, I'd take the GitHub. So in this chapter, we're going to talk about making an amazing GitHub profile. And the first thing that I want to start out with is that the principle is the same. We're really trying to provide a ton of upfront signal to whoever's looking at our GitHub profile, right? We want to show them that we know what we're doing as quickly as we can so they don't have to spend a lot of time digging through the profile to see all the cool stuff that we've done. And the very first thing we're going to want to do is make a good impression with our profile itself. And really what I mean by that is we just don't want to come across as a bot. And one of the easiest ways to not look like a bot is just to have a profile picture, right? Most bots don't take the time to add a unique profile picture. So just by not having that default blocky, colorful GitHub image, it adds some signal. I'd also say like, take the time to get a good photo, even if it takes an hour or two. You don't have to go hire a professional photographer or anything like that, but get a good picture of yourself. Smile, ideally, don't look angry. But you just want a good profile picture because you're going to use this for your GitHub for your LinkedIn. You can even throw it up on your Twitter. It's going to be useful to have a nice headshot of yourself, so just make it high effort and it's going to help a lot. So here's an example of my GitHub profile, again, it's just a picture of my face, not a big deal, you don't need to look amazing, I certainly don't, but at least I'm happy and you can kind of see that I'm a real human, that's really all we're going for here. Probably don't use your favorite anime character, I mean, again, I'm sure people have gotten jobs with pictures like that, but I just, I think it kind of makes you look less professional, so I'd go for a picture of yourself. Next is you're going to want to add, let me see if I can zoom this in a little bit more, you're going to want to add your full name, right? Just as it appears on your resume, this is really easy to update in GitHub. If you made your GitHub a while ago, like say when you first started learning to code, you may have added a joke name or a name that you used as your gamer tag when you were 17. The point is, you can update this, you don't have to leave it as whatever you used when you happened to create your GitHub account ages ago, right? The same goes for your username. I'd highly recommend picking a username that's like pretty tame, kind of just probably maybe your first name, dot, last name, something like that, right? My name's Lane Wagner, so wags Lane, again, just pretty easy. You know, RobotKiller69 might not be the best GitHub username. This stuff isn't going to make or break whether or not you get hired, but it's like, let's just go over all the little things and get them right so that we know this isn't the reason we weren't hired, right? We might as well check all the boxes, it only takes a few minutes. Next, be sure to add a quick bio, right? I've got my bio right here, I like go, I tolerate JavaScript and Python, haha, right? Super funny, I have a great personality, um, at wags Lane everywhere, right? Something super quick, ideally maybe shove in a little bit about what you enjoy, what you don't enjoy, show that you have a little bit of personality as a developer, but definitely fill it out. Again, it's just another little thing that shows that you're a real human that's interested in development. Lastly, before we move on, GitHub gives you a really easy way to link an organization, the city that you're from, this can actually be really important, especially if you happen to be from a tech hub, like don't hide that, right? Put that front and center, if you're in San Francisco, you might as well advertise it. Personal site, Twitter, um, another personal site, like just fill this stuff in, if it makes sense. If you don't tweet a lot, like don't put your Twitter, who cares, or if you're embarrassed about what you tweet, don't put it, if you don't have a personal site, that's okay, you don't need one. Um, I would say in the general case, you probably want to put your location, um, just so that when you do apply to local jobs, they'll be able to see that you're local, which will give you an edge over, you know, all of the different remote workers that might be trying to apply for that same job. Feel free to poke around my GitHub, if you want an example of an okay, put together GitHub, it's not the best GitHub in the world, but I've at least spent some time. Um, I'd also recommend taking a look at Eddie Joao's GitHub, um, Eddie's a friend of mine and he does a ton of stuff on GitHub and he has an absolutely amazing GitHub profile. So if you want an example of something that's really, really good, be sure to check his out. Next thing I want to talk about is that GitHub has this really cool feature called a profile read me. So this section here, this intro text is actually generated from a very specific GitHub repository. Let me show you how that works. So this is my github.com slash wags lane page. And this, this repository is github.com slash wags lane slash wags lane. In other words, my username is wags lane and I went and created a new repository in my account called wags lane. And when you do that, when you have a repository and your username that match that repository, it's read me, right? This, this, uh, this read me that's in the repository will be used to populate this section of your profile page. It's kind of just a conventional thing that GitHub has put into place. So if you want to create a little intro like this, that's how you do it. Create a repository in your GitHub that's named the same thing as your username and that read me will populate. Now my intro is actually probably not the best example of what you want in your intro just because I'm not a junior developer looking for work at the moment. I'd actually recommend, and this is what I do recommend, uh, in the associated section on boot dev. Let me get this out of the way. I recommend that your intro section have maybe one or two paragraphs that kind of outlines a bit about your story and how you got into programming in the first place. And like everything we do in this course, try not to be generic and vague. You don't want to say something like I'm a passionate web developer that loves writing tests and I want to work on cool projects. Like that's the most bland, uninteresting thing that you could possibly put in your intro. And if that's what you're going to put, like just don't even have an intro at all. What you want to put is something that kind of shows your personality, maybe shows some of the opinions or some of the special things that you've been learning as you've been getting into development. So I'm going to go ahead and just like read this example that I wrote up. Um, I've been enjoying web development for the first time ever since I built my first go project stack wrapper. The consolidated tool chain makes me want to leave the JavaScript ecosystem behind for good. Right. So obviously this example is someone who's been learning go. They've decided they don't really like JavaScript, but it's really good to inject those sorts of opinions into your writing, especially if the kind of jobs that you're applying for would agree with the kind of opinions that you're putting forth. Right? Like, so you probably wouldn't want to write this if you're applying for JavaScript positions, but if you're applying for go positions and you genuinely believe this, it goes a long way to kind of signal that again, that you're human and that you have opinions and that you've, you've been through this stuff, right? You appreciate, you appreciate goes consolidated tool chain, right? It's like a way to show your experience without just saying that you're an experienced go developer again. So bland and boring. Cool. I'm currently on the lookout for role in backend web development, ideally writing go or Python. I'd especially love to work at a startup on a tight knit team where I can make an impact quickly. If you're hiring, let's chat. I think this is a pretty good example, right? And again, it's about bringing your personality forward and also about kind of niching down. Like if you're already finding a niche in the types of jobs that you're applying for, like let's say you're only applying really for backend development positions in Python, you might as well in your intro, just mention that that's what you're looking for because it will set you apart from all the folks that just have a super generic, I'm looking for any programming position. It'll set you apart from them, right? And when someone wants to hire a backend Python developer, they're much more likely to hire someone who in their resume says, I'm a backend Python developer, right? That's much more likely than them hiring someone who just says, I'm a full stack web developer and I use every technology. Next let's talk about pinning repositories. So right below your intro, right? Your profile read me, you're able to pin repositories. And if you're getting your first programming job, my guess is you probably only have one, two, or maybe three repositories that you want to pin. The most important thing is to take your primary repository, the project that you're most proud of, right? That we talked about in the last chapter and make sure you pin that one first, right? In my case, it's this go rabbit MQ client, like I put the most work into that repository. I really want it to be the one that recruiters, that hiring managers are clicking on and taking a look at, right? Now I've been developing for a decade now and I have a few other public repos that I like to show off. In this case, there's five. One of them is actually just a blog, but you don't need five and it's better to have a fewer number of good projects than a larger number of mediocre projects because realistically someone that looks at my profile, like they're going to check out one, two, again, maybe three projects. So don't go for quantity here, go for quality and really only pin the stuff that you're super proud of. Next, I just want to mention your GitHub heat map. Now I don't want to brag, but my GitHub heat map is pretty good. If you can't tell, I code nearly an unhealthy amount. I think I've only missed like two days in the last year. I kind of cheat though, so first of all, do not hold yourself to the standard. I cheat in that my blogging and a lot of the project management work and even some of the way I organize my life, I just do in Git and use GitHub for it. So I'm so used to Git and I love Markdown that I just use GitHub so much and that's why my profile looks like this. You do not need an amazing GitHub heat map in order to get hired. So I just want to be very clear about this. This is the least important thing we've talked about so far, but I'm going to mention it because it's really easy to come here and change your contribution settings to also allow for private contributions. That means if you've had a job in the past or if you've worked for a client where even if the repo you were working on was private, it will show those contributions in green here. It's not like it's not going to violate privacy. It's not going to show what the changes were, but at least it will show that you were coding. And so that's a nice little trick to kind of boost your heat map and show that you write a lot of code. All right, before we leave GitHub behind us for the moment, I want to talk about stars. So at the top of your repository, you'll be able to click on this stars tab and this shows everything you've starred. So this actually is not super important, right? So I'm just pointing this out so you don't get confused. This is all of the stuff that you as a GitHub user have starred. The thing that might be more interesting to employers is who's starred you or how many stars you've received. So for example, my Go Rabbit MQ library has 619 stars. It's not crazy. It's a huge open source project, but like that's pretty good for a personal project. Frankly, anything over just like 10 or 20 stars is pretty impressive because it means somebody cared about your project. Now again, I want to point out getting GitHub stars is not critical. You do not need to spend a lot of your time going around and promoting your projects. But if you do have a project that you think other people could benefit from, especially if it's like a library, it might be worth taking the time to post about it on Reddit, right? Or drop a link on Hacker News if you think it's unique. Because if you can fairly easily get a few stars, it does act as social proof. It's kind of like a testimonial that, hey, this guy built something that's interesting and I like it, right? So having stars on your GitHub repo does help, but I wouldn't waste too much of your time trying to chase down the stars. If there's some low hanging fruit, then again, maybe go post in some different communities just to kind of get the project off the ground, but don't spend too much time here. It's time to talk about your LinkedIn profile. Now LinkedIn is probably your second most important social media presence if you're looking to get a job as a developer. GitHub really being the most important and I stand behind that. I know GitHub is not really a social presence, but when we think about profiles on online platforms, I definitely put GitHub above LinkedIn if you're a developer, obviously that's not true for other roles like marketing and sales, but if you're a programmer, I'd rather you have a good GitHub than a good LinkedIn. So in this section, because we already talked about GitHub, we're going to be talking about LinkedIn and just know that a lot of the stuff you did on your GitHub profile will translate over to the LinkedIn profile. So this section might feel a little bit faster, right? For example, you already went and got a good profile photo, so we're just going to use the same one on LinkedIn. Now one more caveat I want to add there is that when a recruiter or an HR person is looking you up, they will probably go to your LinkedIn over your GitHub. If you're in the later stages of the application process with like the hiring manager or the other engineers on the team, they're more likely to check out your GitHub. They'll probably look at both, but my guess is they'll spend more time on your GitHub. When I was a hiring manager, I certainly did. Okay, let's pound out a few basic things. So I'm here on my LinkedIn profile and you'll notice I have a profile picture again. Don't use the default. Hopefully you already have a good profile picture from GitHub. Just upload it here. One main difference is that on LinkedIn you get a banner image. Not super important. You probably could leave this blank and get away with it, but as long as we're doing everything the right way, you might as well come up with a banner photo. If you have a photo of you at a conference, that's fantastic, or at a meetup, those kind of photos do really well. Or just like you doing some hobby that you have, right? Maybe it's a shot of you at the beach with your family, whatever. The purpose of the banner image isn't necessarily to show what an expert you are. It's more just to show that you're a human, that you're not a bot, and that you've put some amount of work into your profile. And then also make sure you add your location. Again, LinkedIn is, well I guess this is the first time I'm saying this, but it's important to understand that LinkedIn is not just a social platform for sharing a resume, it's also one of the biggest recruiting and hiring platforms in the world. And all of the fields that you fill in on LinkedIn are going to be used by recruiters to find you. So you want to make sure that all of this stuff is accurate and up to date. And for example, I am technically in American Fork, Utah, which is a small town outside of Salt Lake. I'm not going to put that, I'm going to put Salt Lake City metropolitan area because that's where all the jobs are. So there's little tricks you can do like that to kind of, you know, you want to fudge your way into the big city. But the point is, you want to be filling out these fields so that you get picked up when recruiters and hiring managers are looking for people in your area. Now scrolling down the page a little bit, let's take a look at my about section. So this is kind of like the summary of at the top of a resume, or on GitHub, it's kind of like your profile read me, right? It's just one or two paragraphs, you really want to keep it short, that put your best foot forward. So it really should look pretty similar to whatever you put on your GitHub profile read me, albeit it's just a text field, it's not full markdown, so you might have to do some formatting changes. Let me read you mine. And I'll kind of explain what I like to see and what I don't like to see in one of these summaries. So mine says, I like to work in go JavaScript and Python. In fact, let me zoom this in for you so you can see a little bit better. Okay, let's try that. I love to work in go JavaScript and Python, but I'm happy to use whatever tools most suited for the job at hand. My two favorite daily activities are learning and teaching within my team and listening to vampire weekend while I jam out some code. I've recently been on a rust and Zig kick doing some stuff on the side when I have time in those languages. I'm also interested in the marriage of the server side rendering single page application world and how we can build client first web apps that still have certain pages that pre render immediately for SEO purposes. Okay, so this is actually on the longer side, like I probably wouldn't go much longer than this. But there's a couple things here. First, I'm calling out technologies that are interesting to me. Now, I have, you know, seven to 10 years of professional experience, depending on how you you slice the time frames a little bit. And I'm really only calling out three different programming languages here. And down here, I'm just saying this stuff interests me, right? You probably want less, right? Like you probably want to focus on the main programming languages or technologies that you're interested in getting jobs for. Because it's better to have a profile that screams, I want a job in back end development writing go, for example, then I'm a web developer that can do anything. And that might be counterintuitive, right? It feels like you're shutting yourself off from a lot of potential jobs. But what it means is when you do go apply to those go jobs, the recruiter or the hiring manager will read that you're super interested in go. And that puts you ahead of all the other kind of generic applicants, right? The assumption being that you've spent a lot more time in go and that you're really going to enjoy the role. Now, I will say this second sentence here, I can't remember how long ago I wrote this, by the way. But the second sentence here, my two favorite daily activities are learning and teaching within my team and listening to vampire weekend while I jam out some code. The nice thing about this is it shows a little bit of personality, which is a thing you want to do. The not so great thing about this is it feels really generic, right? Learning and teaching. Like who doesn't like to do that? It's kind of bland. The more specific you can be in general, the better because it does come across as more human. But you also want to be specific to like stuff that will be interesting. Like my hiring manager doesn't care that I listen to vampire weekend. Like they don't care that that's a band that I like, right? So we don't want to spend a lot of time on this kind of stuff. Ideally, we'd be saying things that show our personality through the craft, right? So like, for example, this next paragraph does a much better job. I've recently been on a rust slash Zig kick, right? Showing that I'm interested in lower level programming languages, and that this is what I'm playing around with currently. And that I've been doing a lot with server side rendering and single page applications. So I've recently been working in a lot of like SEO stuff. It's a little more tangible and probably more of the sort of thing that you'd want to include in this section of your LinkedIn. I want to show you an example of another really good LinkedIn profile. So feel free to look at mine. It's okay. But this is Danny Thompson. He's a friend of mine. He's big on Twitter. If you're in tech Twitter, you probably know who Danny is, but he has a great LinkedIn presence. Absolutely fantastic. So, but in particular, I want to show you what he's done with his experience. So Danny has been in the industry. Well, let's just take a look. Let's take a look at his experience tab. So he's, he's currently, it looks like he's currently at AutoZone. He's been at front door at Google, right? He was a board member for STEM in Shelby County Schools. That's awesome. He's a teaching assistant at launch code. And this is great. If you go back far enough, you can see he was a fry cook from 2008 to 2019. Now this is a question I get a lot about like, what should I put on my LinkedIn or on my resume under the experience section if I don't have any experience as a developer? And we'll talk about this a little bit more in the resume section. But for now, I just want to point out that it's actually a really good idea to have experience on your resume or on your LinkedIn, even if it's not programming experience. Because that at least shows that you can hold down a job, that you're hardworking, right? That you've been in a professional environment in some cases. So you're going to want to put it. And usually what happens is as you get more and more tech jobs, you might start removing some of the older jobs, right? My resume when I first was getting into tech had things like bank teller, waiter at a restaurant. Those were my two most recent pieces of experience. They're not on my resume anymore. But they were for the first two or three jobs because I wanted to have a couple of entries in that list. So again, Danny Thompson, you can check out his profile on LinkedIn and follow him. It's a great example of how to craft a LinkedIn profile. A couple more sections worth calling out are, of course, the education section. If you were self taught with like free code camp, right, like this video right here, you can actually add free code camps to your education section. The same with boot.dev. If you're a boot dev student, you can add that to your education section. Of course, you can add official degrees, you can add certifications. There's a lot of stuff that you can add there. So there's really no reason to leave this blank, even if you didn't go get a traditional four year CS degree, right? There's other things that can actually go in that education section. I'd recommend filling it out. There's also a project section. This is a great place to add the projects that we recently added to our GitHub profile, right? So the same exact projects. They can go here. Again, some recruiters and like HR folks, people that aren't developers, they don't go to GitHub. So we really want to include that here on LinkedIn. Now again, we'll touch more on this in the networking section of this course, but I want to just mention it here while we're talking about LinkedIn, that it can be really tempting on LinkedIn to just connect to everyone, right? You just go find everyone in the world and you start sending cold connection requests, cold DMs. I wouldn't recommend that. We'll talk about it more later. But there's a better way to get in touch with people, right? And to start building a network than to just cold DM and ask for things or cold connect with people you don't know and have no reason to connect with. So for now, again, I just recommend not doing cold connections to people that you don't know. And we'll talk more about it in the networking chapter. Now I'm back here in this section of the course that talks about how to add experience to your LinkedIn profile. And I just want to touch on this, this section, because I think it's really important. So I talk about being tech adjacent is an advantage, right? So we talked about how if you worked at jobs that are not really technically related, right? Like for example, Danny Thompson was a fry cook for many years. You still want to include that. There are a lot of jobs out there, though, that are tech adjacent. In other words, you weren't a developer, but you were working with developers or you were using technical products or software products. And there's a way that you can reword your the experience section, like the description to kind of emphasize anything that you did with it was even remotely related to tech. So let me give you some examples. If you had an IT ops job, right, so you weren't writing code, but maybe you were in charge of deploying software, then you might say something like, I worked closely with the development team to ensure that the software was deployed and running smoothly. It was an awkward scroll. Okay, I wrote custom code to automate deployments, right? Or I built a slack bot to provide real time updates on the status of the production environment, instead of something a little more bland that doesn't emphasize any coding, managed production environment upgrades, installed databases and analyzed logs to troubleshoot issues. So you really just want to emphasize anything that you possibly could have had to do with code, right? And then just just one more point while we're here is to be as specific and as interesting as you possibly can. So you don't want to say things like, working on a back end REST API, like that's pretty boring, right? Or worked on a collaborative team and practiced leadership skills, vague, right? Everyone, everyone could claim to have done that. Used Python and JavaScript to build an app that tracks data, right? Tracks data? Like, like, what is that? What does that mean? What did you actually do, right? So here's some examples of what you could do instead. Built some media uploading service using Kubernetes, Docker and Go, right, something super specific that handled 1000 files per second, again, super specific, right? We're talking about performance now, that's fantastic. It replaced the old service that struggled to handle 100 files per second. So here we're, again, like providing actual numbers, we're not just saying improve performance, we're saying improve performance by how much, right? That's how you get attention. I led an initiative on my team to develop and plan to streamline our QA process for our React native mobile app. We reduced the average turnaround time for a pull request approval by 50%. Again, very specific, we're talking about the exact technologies we used, right? And we're saying that we made something 50% more efficient, right? The QA process, that's an expensive process that people are, that companies are paying people hourly to do, so that can save a lot of money. I built a full stack Django app that pulls weather data in real time and sends alerts to subscribed users in geographic areas at risk of severe weather, okay? Again, specific technologies, we're not saying tracks data, we're saying pulls weather data in real time, right? That's fantastic. This says sends alerts, that could even be more specific, right? Sends SMS text messages to subscribed users. We just want to be as specific as we can, again, because that's what really gets attention and gets people's heads turning. It's time to talk about resumes. Now, a lot of the stuff that we're going to talk about in this chapter about resumes will also kind of just apply to your LinkedIn profile, and I just didn't really want to talk about it then. So just realize that as you make updates for the copy of your resume, so like the words on the page for your resume, you'll want to probably go back and work those updates into your LinkedIn profile as well, because at the end of the day, your LinkedIn profile really is just kind of a web form version of your resume, right? So your resume is a document, your LinkedIn is the exact same information in a web form. The nice thing about LinkedIn, of course, as we talked about earlier, was just that it's parsed by LinkedIn, and since LinkedIn is this huge job board, you can be surfaced as a candidate for jobs sort of naturally. Okay, first, let's talk about the medium of the resume. And what I mean by that is I'm doing this in a Google Doc. Google Docs are great because I highly recommend getting your resume reviewed either by a friend or family member in the industry, if you know somebody, or in an online community, right? So going and finding a Discord or a Slack group where you can post a copy of your resume and get feedback and advice from people who are in the industry on how you can improve it, right? You're going to want to put in, work up front to get it to a good place, but at that point you should get it reviewed. So Google Docs is great because you can just share a link to it, right? We're not downloading and uploading files, it's just kind of this living document. So we're doing the resume in the Google Doc, and then I would highly recommend sending it to employers as a PDF. And the main reason for that is not everyone has an easy way to view like Word documents. Like Google Docs have their own file extension, and Word Docs have a different file extension. Some companies use like desktop, Microsoft Word, sometimes the compatibility is not great, but you can always download a Google Doc as a PDF and Chrome or really any modern web browser will open a PDF. So it's viewable, just in a browser, which is pretty nice. So to reiterate, we're editing in Google Docs, we're sending to employers as a PDF. I think it's a pretty good general rule. Next thing I'm going to recommend is to make your resume visually appealing. Now it doesn't need to be the most perfectly designed thing in the world, it doesn't need to be this stunning masterpiece of design, right? Especially if you're applying for backend engineering positions. It's just not that important. But you do want it to look good. You don't want it to look like it was kind of broken or that you don't know how to format a document like that. That's bad. It just kind of makes it look like you don't know what you're doing in general. So that's a problem. And then the reason I say you want it to look good, good might actually be the wrong word here. What I think it should be is looking different. So when I was a hiring manager, I got a lot of applications, right? Sometimes I'd be sifting through 30 applications. And generally speaking of 30 applications, 20 of them would look identical. There's a black text on white paper formatted exactly the same way, right? I'm guessing there's some very common like black on white resume template that people are finding online. And it just makes them all sort of blend in, in your mind, right? As you're sifting through these papers, if a resume looks a little unique, it sticks in your mind. So, you know, when HR or recruiters or hiring managers are going through a stack of resumes, it could be physically going through a stack, which is less common these days, but it could also be, you know, electronically. If one sticks out visually, and they like it, it's easier for them to find it again, if that makes sense. You just go the extra mile, find a very basic template, right? This template that I used, it's just got a splash of red. It's just got a splash of red. It's got a serif font for headings and a sans serif font for like bullet points and body text. And like, I think this is really all you need. Again, you don't need to go spend a ton of money. You do for the most part, want it to be plain text, right? These resumes do get read in by automated systems, ATSs, applicant tracking systems. And so you do want it to be a fairly simple text-based format so that the machines that parse these resumes will be able to pick out things like the keywords. Now, I'm over here on the text-based version of the course. We're in chapter five, lesson two, where we talk about templates, right? And I have collected a few templates that I think are pretty good, pretty minimalistic with a little bit of color to help you stand out. You can use one of these if you like, or you just use them as examples, right? You can't just find another template or make your own. But I think all of these do a decent job of just kind of being text-based, very simple, very easy to visually parse. And right, contact information is bolded. You want people to be able to find your contact info, but just a little bit of blue, right? In this one or in this one, just a little bit of orange, right? And here we've got a little bit of green. So just don't do plain black on white. That's my take. Some people might disagree, right? I'm not saying that I know everything, but I know that when I'm sorting through applications, having them all be a little visually distinct helps me remember which ones I liked and which ones I want to go back to. Next, let's talk about the actual structure of your resume, right? We've looked at a few different templates, but to be honest, I would not recommend going and finding a template from online and just using the structure. Usually those templates are published by designers, right, who are just interested in making a really pretty resume. And while that's fine, you can have a pretty resume, you really want to get the structure right. So let me tell you a little bit about my philosophy on this. So you really should think about your resume as a landing page on a website or as if it were a landing page on a website. In other words, you've just got a few moments to grab somebody's attention with your resume. There's no chance that a hiring manager who has 100 resumes to go through is actually going to read every single one top to bottom and comprehend all the information on all of them. It just takes too much time, right? They're going to skim. So we want to put the most important stuff at the top and we want to make the most important stuff eye-catching, right? Okay. So if you've never had a job in tech, the structure I recommend looks like this. Name and contact info at the top, that's universal, right? You want someone to be able to see your name and you want them to be able to get in contact with you. That contact info should include things like your GitHub and your LinkedIn, absolutely, and an email address and phone number. I would recommend putting an email address in a phone number. Some people don't do that. They like want to be DM'd on LinkedIn. They're worried about getting their phone number out there. I would argue that if you're trying to get your first job in tech, a few spam calls is worth the cost of getting your phone number in front of hiring managers so that they can call you very quickly on the phone, right? We're just trying to reduce the amount of friction that it takes someone who's interested in hiring you. We're trying to reduce the amount of friction it takes for them to get in touch with you, right? We don't want the reason they decided not to reach out just because it was too much hassle. That would be a shame, right? After that, the about me section. This is the same as your about section on your LinkedIn or kind of the GitHub profile read me. It's going to be a very similar section, one, maybe two paragraphs. We're really looking for just like three sentences, four sentences, like keep it really, really short and terse. We should not be trying to take up space here. If you have nothing interesting to say, it's actually better not to say anything at all. Really try to come up with something interesting, a good way to introduce yourself. Next we're going to put skills. This should really be like a bulleted list of items and keep in mind that ATS's applicant tracking systems are going to be trying to parse this data. You want to keep it pretty simple, right? We're just putting keywords in basically, right? Like Git, GitHub, JavaScript, Python, Kubernetes, Postgres, all the things you've worked with, shove them in there. It shouldn't be crazy long, but hit the most important things for the jobs that you're interested in, right? Emphasize the stuff that you're interested in doing day to day. Okay, next portfolio projects. So again, this is assuming you are looking for your first job in tech. I recommend putting your portfolio projects not only above education, but also above your work experience, because those are going to be the most important things. That's what you want anyone looking at your resume to click through to. You want them to go look into your projects and see what you've built. This changes if you've had a job in tech, then the most important thing is your experience. You want to be very obvious and clear that, hey, I have four years of experience as a developer. Here's where I've worked. So you kind of flip the portfolio projects and the experience in that case. So in a nutshell, the whole idea is we're putting the best stuff more towards the top. The stuff that we want someone who's skimming our application to run into, we're putting that near the top. Really briefly, let's talk about contact information again. Like I said, I recommend four pieces of information at a minimum. Your phone number, your email address, your GitHub, and your LinkedIn. Your GitHub and your LinkedIn should definitely be clickable links, right? Again, we're just removing friction. Like why make it hard on the recruiter or the hiring manager to go look at your stuff? Make it simple, right? So Google Docs, really any rich text format is going to support clickable links, so you might as well hyperlink them. And like I said before, you're going to want to include these. Don't worry too much about spam calls. If you get them, you can always block them. Those systems work pretty well. One last thing I will say, we did touch on this earlier, but your GitHub handle, in my case Wagslane, your LinkedIn handle, and your email address, these are going to be read by humans. So again, if you have one that you're embarrassed by, KillerLord69 or whatever, or Dabber420, whatever, I don't care. If you don't like it, if it's embarrassing to you, change it. Just change it. Go get a new email address. Or change your handle on GitHub and LinkedIn. It's not particularly hard to do. So minimum four pieces of information there. It is once again time to talk about the about section. And I know I've mentioned it before, but I want to just go over a few more examples. And in particular, if you want to read these examples, again, you can find them on bootdev, this time in chapter five of the course lesson five. So the about section of your resume is really important, especially if you're a career switcher. So if you're switching from, in Danny Thompson's case, he has such a great story, I have to just keep bringing it up, frying chicken to becoming a developer, having just a little bit about your story can be really inspiring, and it can explain a lack of experience on your resume. Everyone sees that you are looking for your first job in tech, they kind of want to know what the story there is. They want to know, you know, did you drop out of school? Did you get a CS degree? Did you attend a boot camp? Are you switching from being a fry cook? Are you switching from a career in IT operations, right? They want to know what's going on. Okay, so don't do this. I'm just going to go ahead and read you a bad example. I'm a developer who writes Python and Go. I love to hang out with my family and write code in my spare time. I'm looking for a great company to work for. Really generic, not super specific. Everyone's looking for a great company to work for. That whole sentence does nothing for us, right? I love to hang out with my family and write code in my spare time. Okay, everyone's going to claim to write code in their spare time. I'd rather be shown that than just having you tell me. And okay, you have a family that tells me a little bit about you. And Go and Python, that's kind of specific about technologies. But in general, this is not something I'm impressed by. Let's take a look at some examples that I think do a better job. First one, I discovered a love for software engineering three years ago ago, I guess there's an extra W there, we'll fix that later, three years ago, when I stumbled onto a book about Python and started writing little scripts to automate some of my daily tasks as a middle school teacher. Okay, whoa, super cool, right? So you're like dabbling in code as a middle school teacher, and you're writing scripts to automate some of your tasks, like that's pretty cool. It's a lot better than like, I was sick of my job as a middle school teacher, and I learned to code so that I could pay the bills, like that's not as interesting. This is cool, right? I love teaching, but it just doesn't pay the bills these days, and I was having so much fun writing code, right? So we are mentioning, it's not that it's wrong to mention that like, you'll make better money as a developer, we all know this, you can you can own up to that. But it's this, it's this little tidbit about writing scripts to automate some of my daily tasks. Like, that's the kind of thing you really want to slip in to one of these little kind of little bio sections. Now with several big projects under my belt, okay, so we're mentioning that we've built several large projects, and having completed several rigorous online CS courses, right? Okay, cool. So this person is taking their education seriously, they're going and learning, you know, computer science fundamentals. That's really big. It's a really big deal. I'm making a full time switch to back end web development. So this answers a lot of the questions around your backstory. And that's really what you're trying to do in this section. Another one, coding can always just been a hobby for me, I write little projects here and there to keep track of D&D campaigns, but I hadn't considered it as a career path. After a couple of years as a waiter, I realized I had talent for this coding stuff and decided to go about learning the right way and take some in depth CS and back end development courses. Now that I've completed those and have several real world projects under my belt, I'm excited for a full time career in software engineering, right? So we're getting specific again. I got into coding, and I was building projects for my D&D campaigns, right? Pretty cool. I was a waiter, but I've taken a bunch of courses, I've built a bunch of projects, like that's the kind of setup we're trying to, we're trying to put here. I've been enjoying web development for the first time ever since I built my first go project stack stack wrapper. Okay, so this is pretty cool. It's calling immediate attention to what I'm guessing is this person's capstone project, right? So if you have a really impressive capstone project, you want to call attention to it. You're trying to kind of not hide, but you're trying to get the person reading your resume to forget about the fact that this is going to be your first developer job and get really enthralled by whatever projects it is that you've built, right? I was playing around in the world of React slash Next.js for a while, but goes consolidated tool chain makes me want to leave the JS ecosystem behind for good, right? This is an interesting tech opinion, right? Probably not the best opinion to put forward if you're applying for Next.js jobs, but if you're applying for go positions, like this is a great thing to put in here. It shows that you've been around the block and that you really appreciate what go is about. It's like showing that you have experience without just claiming it, right? This person isn't saying, I am an experienced go developer, right? That's not interesting. Everyone's going to claim that, but by saying I've done a lot with React to Next and I didn't like it for this specific reason, and this is the thing I really like about go, it just shows that you have experience without having to like just come out and say it in a really bland way. Hopefully that makes sense. I'm currently looking for a role in backend web development, ideally writing go. I'd especially love to work at a startup on a tight knit team where I can make an impact quickly. I'm just niching down a little bit on the types of roles you're looking for. I just want to mention this here. The boot dev discord, we have a job help channel. If you would like to drop your resume in there, you're more than welcome to and we'll give you feedback. Next, I just want to mention a couple things about your skills and technologies section. You really want to be fairly concise here. Let me tell you about the stuff that you should omit. You really don't want to be putting stuff in here that makes it look like you don't have experience. And what I mean by that, if you're listing like Microsoft word or Microsoft teams or slack as technologies that you have experience with, like that's not impressive. Like we kind of just expect you to be able to use basic web apps. So don't put that kind of stuff here. We're really interested in what technologies you've used as a developer. So like a couple programming languages, right? Maybe some databases if you're looking for back-end work. Again, maybe some infrastructure stuff, especially if you're on the back-end side. If you're on the front-end side, you might be listing things like Tailwind CSS or Bootstrap, right? Different front-end frameworks that you've worked with. Here I've listed Fluent Spanish. That's kind of random, but it is another skill that I have. I don't know. To be honest, I would probably drop this to somewhere else in the resume, but this isn't a big deal. It can live here if we want. One thing I want to caution you against is don't try to quantify your skills. Like just, just make it a list. Just list your skills. Go JavaScript, Python. Don't try to do anything cute where you say, well, I'm a five in Go and I'm a three in JavaScript, right? Or I'm a, I'm a two out of five in Python. First of all, it makes no sense. Like what are you quantifying? Like how much of the language you've used? Like are you just comparing yourself to others, right? Like where another junior developer is a five out of five Python, I'm a two out of five. That's obviously awful. It's like, just don't do it. It makes very little sense. And it's one of those things that not only will be kind of obvious when someone reads the rest of your resume, right, they'll, they'll, they'll read your skills and technologies and they'll go look at your projects and they'll see, oh, this person's like all their projects are in Python. We should assume that Python's what they're most familiar with. Like that's good enough. You don't need to like explicitly say it. It's also one of those things that just will get cleared up either in a phone screen or in the interview. So just, just, just don't do the quantifying thing. It's, it's not worth the time and it in the worst case, it makes you look a little silly. Now this section is also one of the sections that's most easy to customize. And what I mean by that is if you're applying to both Python and Go positions, it's pretty easy to have a version of this section that's for your Python jobs and a version of the section that's for your Go jobs, right? And you're going to emphasize different technologies and skills in either copy of the resume. These are keywords. If you're applying to large companies, it's very likely that they have an automated ATS or HR, right? Like non-technical HR people or recruiters scanning your resume. And they've just been told, Hey, we need someone that's done Go Docker Postgres, right? If it doesn't have those three things, throw the resume away, right? So it is important to list everything that you're familiar with. But because those lists can get so long, you can kind of tailor this fairly easily to the different jobs that you're applying for. Now let's talk a little more specifically about your projects. This is going to be a section of your resume that's very similar to your GitHub. But I want to talk about exactly what you should include on the resume. So first of all, of course, you're going to be including the name of the project. This next part's really important. Add a link to the project. I have reviewed so many resumes that have the name of a project, but there is not a clickable link through to the GitHub. Like I want to check out your project. Please make it easy for me to check out your product. A short description of the project. So this should really be just like one or two sentences, probably the same as the like what or why, or even just the description on the project on GitHub, right? So you don't necessarily need to write new copy for this. It should be very similar to what exists on GitHub. You're definitely going to want to include the tech stack and technologies used in the project. Like this is a good way to signal to the person looking at your resume that you know certain technologies, right? And it's a lot more powerful than just saying, I am a good Golang developer, right? Like, no, it's much better to have a great go project and to list underneath, I used go and I used Postgres, right? And I used goose or whatever technologies I used. Great. Okay. Finally, I want to say two more things that I think are really important. Two projects here is good. Three is probably too many. On GitHub, you know, if you have a lot of projects, if you're an experienced developer with many years, I mean, you can have six, you can have eight projects on your GitHub that you're calling attention to and it's not really a problem. But on your resume, there's not enough room for that. And you really want to kind of emphasize, I would say at most two projects on your resume. Only do three if you really feel strongly about that third one. And then finally, don't be afraid to use at least a paragraph or two for each project. You're like, it's okay if there's a decent amount of text underneath each project heading and description or sorry, heading and link, because especially if you're someone with no work experience, it's like, what else are you going to put on your resume? Like you really want to be spending the time kind of showing off how great this project is. So it really is okay to have some bullet points, to have an explanation of each project. Like don't shy away from that. So we already talked about this a little bit, but the work experience section of your resume, even if you haven't had a programming job yet, is still very important. There's two things you can do. First, you can list previous jobs that you've had that are not programming related. And if they are programming adjacent, you can do your best to emphasize any little bit of coding or ops or command line, like anything that you did that's remotely related to programming, like emphasize that in the description of the job. So that's number one. But number two is if you don't, if you don't have any programming experience, you can always go get some experience without having to get hired. Let me show you what I mean. I've got a clip from Bill Kennedy, the founder of Arden Labs or one of the founders of Arden Labs. Um, and he was on my podcast back in banter and he's going to talk a little bit about how you can do this. This is what I would say. And I talked to my wife about this as well. She's in a place right now where because there's so many people looking for work and the economy is falling apart and there's openings, but the 5,000 hour people are getting them right now because there's just too many of them. Um, what do you do? Do you know how many nonprofits there are right now that need software development? I mean, you're looking for something to problem to solve, going knock on a local nonprofit and tell, ask them what technology problems do you have right now? Maybe you'll get lucky and they'll need some sort of website that could leverage some backend APIs. Why not work on that? There's no stress. You ain't getting paid. There's no timetable. You now have a problem that you have to solve. So you get to learn without any stress and you're helping the community out at the same time. And then on your resume, I'll show you how to make that look like you were working at a job because you technically were, you know, you weren't getting paid, but we don't put salaries on resumes, do we? So now under experience, you were working with 501c3 nonprofit blank building software. This wasn't school. It wasn't education. It was a job that happened to be pro bono, but who cares? And so this is what I'm going to say to you, okay? If you have that time and you're looking for a project, there are a ton of nonprofit organizations all over the place that would love your help. Maybe part of that project isn't fun and fancy for you. Maybe there's a browser front end piece to it. Well then get your friend who loves front end to do that and let them learn how to work and get together as a team. And you do all the backend APIs and the database stuff and, and whoo, imagine if everybody did that, how much better the world would be. So I think this is really great advice. What employers are looking for in your experience section isn't really that you were paid to do work. It's that you did work that was useful to someone, right? So even if you work for a nonprofit pro bono, right? You're not getting paid, like Bill said. Or if you contribute to a larger open source project and those contributions actually get merged and used, you weren't paid. But I don't believe, I certainly wouldn't as a hiring manager have any problem with you including that in your work experience section. As long as you're super clear about who you were doing the work for, right? You want to be clear this was work for a nonprofit 501c3 or this was work for this open source project. Just list your salary, right? Like Bill said, you don't have to put that it was pro bono or for free work. That's not a question that comes up. Just put who you did the work for and what impact it had. My philosophy around this kind of stuff is of course you always want to be telling the truth. You never want to be caught in a lie and that means that you shouldn't ever lie about this kind of stuff. But at the same time, it's all about putting your best foot forward and presenting yourself in the best possible light, right? You don't need to draw attention to the things that some employers might view as weaknesses. Why would you do that? On the same token, you don't want to omit anything that an employer might see as a strength. So show off your strengths, don't bring attention to your weaknesses, don't lie, be transparent and you can make a resume that otherwise looked really unimpressive actually look like top of the pack. But let's talk about applying to jobs, right? Everything we've done up to this point has just been getting us ready to apply for jobs. We're just getting profiles ready, we're building a resume, we want to be in a really great spot so that once we start applying for jobs, everything that we do is as effective as it can be, right? You put in the work up front and now you can just churn out a bunch of applications and they'll be a lot more effective than if you didn't go optimize all of those things first. So the first thing I want to talk about is like, let's set a weekly goal right now and just go do it. And what I mean is, first of all, sometimes people try to apply to way too many jobs, right? You hit the ground running for a day or two, you apply to a hundred jobs, you don't get any callbacks and you get discouraged, right? You can get burnt out pretty easily. I recommend trying to find a healthy pace, maybe 20, 25 jobs, something like that, that you can apply to, again, I don't know, three, four jobs a day, right, to hit that 25 jobs a week goal or whatever kind of goal you set. But you shouldn't be spending more than like an hour a day on this, right? At most like two hours because keep in mind, you still want to be spending time learning, building and doing some of the other activities like networking and warm introductions that we'll talk about in a later chapter. And then just don't wait. I hear so many students kind of get to this point in their career journey and the imposter syndrome hits. Like, am I really ready to apply for jobs? No, no, no, I'm going to spend a little bit more time tweaking my resume. I'm going to spend another week on my project. It's like, just start applying. Like I've almost never seen someone start applying too soon because all that happens is that you get rejected and in some cases you get feedback about that rejection, right? Like, oh, your project wasn't impressive enough for us or oh, we're looking for this keyword on the resume and you had that keyword. You don't always get feedback, but sometimes you do, especially if you ask for it, but you always get the feedback of accepted or rejected, right? And so I would just start that process sooner than later. Okay, so the natural question is where should I apply, right? Now there are the obvious places, of course, I'm not going to spend a lot of time but like indie, LinkedIn, Glassdoor, AngelList, these are places that you should be spending some time applying. The problem with these places though is that while yes, all of the jobs are there, like there's many, many thousands, millions of jobs hosted on those platforms, there's also all the competition, right? So you're going to want to spend some time there, but you don't want to spend all your time there because everyone in the world is applying to the top 50 jobs that show up when you type backend developer on LinkedIn, right? Like everyone is applying to those. It doesn't mean you can't apply to those, you can, right? LinkedIn has a really great easy apply button, but just remember that LinkedIn's easy apply button, it's really convenient. You don't need to fill out a whole application, all you have to do is click the button. But that's all anyone has to do. So those job postings are going to have much higher application rates because there's thousands of people on their phones scrolling for jobs on LinkedIn, clicking the easy apply button, right? So we're going to talk about, in addition to spending some time on the large platforms, we're going to talk about some other places that you could also be applying, places where the competition will be much lower and you'll have a much greater chance of standing out. The first one that crazily gets overlooked is your local area, right? So in 2020 and 2021, obviously the entire world went remote, especially in technology. But it's 2022 or rather it's been rough in 2022 and 2023 for the job market and the culture of remote only has shifted back to there being a lot more onsite jobs. So just don't forget that there are a lot of onsite jobs and when you limit yourself to remote only, you are playing on hard mode in the sense that you're competing with the whole world at that point. When you apply to jobs that are in your local area, you're only competing against the other candidates in your local area. So there are a few great advantages, right? The candidate pool is much smaller. You can meet the folks that work at the company that you want to apply at. You can meet them in person, right? You can maybe even just ask them to meet you for coffee. It doesn't even have to be the hiring manager, it could just be somebody that works at the company. You can get a sense of the company culture just by visiting the office, right? And if you do get the job, you'll be able to work with your coworkers and mentors in person, which means you'll learn faster, which is actually a huge advantage. You can have a remote first job, I'm not saying you shouldn't consider it, but there are some distinct advantages to being in office with other developers, especially in the first year of your career. There's something about being able to just spin around in your chair and chat with somebody about a technical problem that you just don't get over Slack. While we're talking about local jobs, I want to play a clip that a friend of mine, Kent C. Dodds, the author of Epic Web.dev and Epic React, he put together. It's a story of his from when he was applying when he was right out of college and how actually showing up physically at the office made a huge impact and actually got him hired. Hi, my name is Kent C. Dodds, and I build educational material for people just like you on Epic Web.dev to teach people how to build full stack applications. I want to tell you about how I got my first job in this industry. So I was going to school and I had part time jobs while I was in school that were in the industry and that was cool, but I noticed all of my friends were starting to get their full time job offers and I was really nervous about that. I was interning at working part time at a company called Domo and I took a break from them to go intern at another place over the summer. And when I came back, I was talking before I left, I told them, hey, I'm going to want to come back. I want to have my job back. Yeah, that's fine. So two weeks before I come back, I'm calling them and saying, hey, I'm going to come back and I couldn't get a hold of anybody, so I'm like, great, that's not good. I'm not going to have a job. And I have, at this time, I had a daughter and another kid on the way. So I'm like, oh, shoot, I need to be able to make money even while I'm in school. So I get back and I still haven't heard from them and the Monday comes on what I thought was going to be my first day at the office again and I decided just to go. And so I just went into the office and I said, hey, I'm back. And they said, oh, we were totally not expecting you, but OK. And I said, you can go find my manager. And he came out in his face like, whoa, what are you doing here? And I just thought like, what's the worst they can do? Just tell me to go home. I don't have a job. But that's not what they did. What they did was they like, OK, come on back. We'll find you a computer. We'll get you working. And I got my job back. But again, this is just an internship. All my friends were getting their full time jobs post graduation and everything. So I was a little bit nervous about that. And they weren't interested in giving me a full time offer contingent on my graduation or whatever. They were just like, when you graduate, maybe we will have something for you. So we had these hack night projects every couple of weeks. We would do these hack nights and I would participate in those because they were fun. And I built something that was pretty cool, cool enough that my coworker decided the CEO should see it. And so this was late in the evening, like 1130. The CEO is still at the company. It's a startup and he didn't have work life balance. I don't know. But he was there. And so he comes over and I fumble through my presentation and I say, yeah, this is what I did. It's kind of cool. And Merrick Christiansen, the one who brought the CEO over said, yeah, Josh, like this is super cool. This guy, he's just an intern, like he's only working part time. And I said, yeah. And Josh was like, oh, yeah, that's cool. And I said, yeah, actually, if you give me an offer right now, I'll accept it. A little bit bold there and everybody, there were a bunch of people around watching and they were pretty surprised that it would take such a bold move to talk that way to the CEO. But Josh liked that, I guess. And he slid a piece of paper with a pen over to me and said, go ahead and write down your number. And I said, well, OK, I hadn't actually thought about what my number was. I wrote something down that I thought was good. And he called up the HR director and said, hey, can I hire this kid? And they're like, yeah, I guess so. So that's how I got my first job. And so hopefully that is you can take a couple of like lessons out of that, like be bold and not overbearing. I wasn't like a jerk about anything or whatever. I wasn't annoying or anything. But I showed up and I was ready to do the work. I put in good work. I worked hard and delivered really good stuff. And I made certain that the right people knew about the work that I was doing and the opportunities that they could have to work with me. So I hope that is helpful to you in some way. That's how I got my first full time job out of graduating out of university. And good luck on your own journey. See you. I really encourage you to look is on company websites. So if you know the companies in your area or if you know the companies that just exist out in the world that are hiring remote and you like those companies, you can go straight to their careers page, like just Google the name of the company and careers, and you'll almost certainly find their careers page. The nice thing about going straight to the website is a lot of times those applicants are fast tracked because they're not going through layers and layers of HR software. Sometimes there's even just an email address for you to submit a resume to. So it's a way to kind of take a side door that not everyone's taking. Most people are not going straight to the companies they want to work at and looking at their careers pages. They're just trolling job boards. So definitely spend some time here. You should have an idea of some of the companies that you'd like to work at. It's worth taking the time just to check out their careers page if they have one. The next place you can look is in niche job boards. So you've got the big job boards, like Indeed and LinkedIn, but there's also niche job boards out there. Little ones, right? Like Remote OK, Golang Cafe, WeWork Remotely. These are job boards that like not everybody is on. And so the competition, the people that are applying for those jobs, it's going to be much, much lower. It's easier to stand out. I also want to call special attention to Hacker News, right? Hacker News is kind of a Reddit-like site run by Y Combinator, and every month they do a who's hiring thread. They also do a who's hiring and who's looking for work. And it's kind of this old, intimidating, like text-only website. But it's a really great place to go and hang out and meet some folks and apply to jobs the old-fashioned way, right? So a great way to kind of, again, we're looking for ways that we can take the side door so that we're not competing against, you know, a thousand people all clicking the easy apply button on LinkedIn. So definitely check that out. And if you want this little list of niche job boards, you can come to boot.dev and go to chapter six, lesson two, and I've got links to all of them. This is just a few examples that came to my mind. There are a lot of these. In fact, there's also a lot of like local Slack and Discord communities that will just have a jobs channel and like local companies will post in the jobs channel. One more point is that non-tech companies do hire developers. And frankly, I started really at a non-tech company, a non-software company, right? I was working as a developer on like internal tooling, it was more of a hardware company. And that's a pretty common story for people just getting into development. So don't overlook the fact that there might be companies in your local area that need developers, but they don't advertise their jobs in all the same sexy ways that like venture capital backed startups do, right? I mean, we looked at Danny Thompson's profile, he's working at AutoZone, right? Like that's not a traditional tech company, and yet he's killing it there. So make sure you're keeping an open minds to all of the opportunities that might be out there. Take a second and talk about recruiters. Recruiters can be helpful, but they can also be a gigantic waste of time. And you don't want that to happen. Let me explain. Recruiters make money on commissions, generally speaking. So when they help a candidate land a job, or more specifically, they're hired by the company. So when they help a company find a candidate, that's when they get paid. And to be perfectly blunt, there is not a lot of money, if any, in sourcing entry level developers. So if you were an entry level developer, it's unlikely that a recruiter will be useful to you. Now, there are some exceptions. If you want to go work at fang companies, like big tech companies, they often have internal recruiters that are trying to find like up and coming talent, right? A lot of times they source out of universities, or maybe they're doing sourcing on like big open source projects, or at large hackathons. In those cases, like yes, an internal recruiter will probably be useful to you as an entry level candidate, but recruiters that work for like third party recruiting agencies are going to be unlikely to be helpful to you because they're not going to be making money on those transactions, to be perfectly frank. So I'm not saying you should ignore every recruiter and mark all of their messages as spam when they do reach out to you. But I just want you to be wary of your time, because what recruiters do is they spray out messages to a ton of people, either via DM on LinkedIn, for example, or via email, and they're trying to contact tons and tons of people, and then they're kind of just like putting the time on the people that they're contacting to get back in touch with them if they're a good fit. So you don't want to spend a lot of time like gathering, you know, your resume and your links and answering the recruiters questions. If it's unlikely that you're going to get the job in the end, it's just, just be wise about it. The motivation is interact with some of the recruiters, you can kind of see how the game is played, but just be wary and don't try to waste too much of your time with them, especially if you're an entry level candidate. Once you do have more experience, right, once you have a couple of years of experience, you're applying for like a mid-level or senior role, recruiters actually can be extremely helpful because they're highly incentivized to get you placed in that role, and they can make as much as like 20%, 30% of your yearly salary. So it does get, it does get, it does get to the point where they are actually very useful to you, but if you're entry level, just be careful. It's time to talk about the disgusting corporate word that is networking. So networking is a long-term play. I want to like get this out there. You really want to start networking early, ideally, even when you're still just learning to code. If you're watching this video, you probably are more towards the kind of, I don't want to say end of your learning journey because there is no end, that's the wrong way to say it, but you know, you've been learning for a while, I guess is the way I'd put it, and now you're looking for work. Networking is the ultimate side door, right? So we talked about how there's some side doors when you're applying to jobs, like instead of going through the front door, which is like LinkedIn, easy apply, we're going to go find niche job boards or apply directly on Hacker News threads or company's careers pages or walking into the office, right? Those are some side doors, but the ultimate side door is networking. It's making friends who have jobs in the industry, and then eventually those friends might stick their neck out for you, right, and let you know about an opportunity, or even if it's not sticking their neck out for you, it can be as simple as giving you a warm introduction to a hiring manager. So let me give you some examples, let me zoom this in, so do not, cold DM people asking them if they have work for you, that is not networking, I've met lots of people who think this is networking, this is not networking, right, this is just spamming DMs and it's not helpful and I've never seen it work, so probably don't do that. Don't join discord servers and spam the jobs channel, right? Now that doesn't mean that the jobs channel is not useful to you, it can be, but you probably want to either A, look through the jobs channel for open positions and then go apply to them, or B, hang out in that discord for a while and make some genuine friends in there, right? Become a regular, become a trusted member of the community, and over time you will be more likely to be considered by the hiring managers that are also hanging out there. They're not going to do you any special favors if they just met you, that's why I say networking is a long game, it's building up a bunch of real friendships and real relationships within the tech community and then eventually those relationships will just naturally become useful to you, it's not about exploiting those relationships, it's just you build them up and you get sort of this mutually beneficial relationship between you and whoever you become friends with. So another one is do not show up at meetups and hand out business cards, right? When you attend meetups, which we'll talk about more in just a second, like you should be spending your time there just getting to know people, right? Getting to know people, making friends, you want to show up consistently, don't expect to like be everyone's best friend after the first meetup, every time you go you can sit by somebody different and talk to them, but you don't need to just show up and hand out business cards. Do engage in conversations with folks on Twitter, LinkedIn, Discord, etc., about something they posted about, right? So when somebody posts on one of these social platforms or like hang out servers or communities, right, like Discord or Slack, they're posting about what they're interested in, it's like engage with what they're already interested in, that's like one of the best ways to make friends. I don't want to like make a course on this because it's just such basic stuff, but for some reason, you know, we struggle with it. Help people out when they ask for help online, right? So a lot of kind of new people to the idea of networking, just reach out and ask for help. Do you have work for me? Will you be my mentor? Can you help me with this problem I'm having? You're going to make good friends and build strong relationships much faster if you just do the opposite, right? If you're the helpful one, right? Everyone wants to help someone who's helped them in the past. So if you're a very helpful person online, that will come back to you in the long run. I'm going to keep saying it, but networking is a long game. And then do go to meetups and talk to people about the talk that was just given, right? So meetups are just a place to hang out, talk about technology. If you do it consistently, you will build a network. It's practically impossible to go to a meetup and hang around after the talk and talk to a few people. If you do that for six months, it's basically impossible to not build a little network. So just keep that in mind. There is a time factor that's important. On that note, I had Mariah Peterson on the Backend Banter podcast, and she runs several meetups and even organizes a conference. And she talks about how much meetups can help you in your first job search. So let's cut to that clip. I used to pre-pandemic and a little bit during the pandemic, it got really hard during the pandemic, but pre-pandemic, I would go to a bootcamp every three months and I would talk to their cohorts and I'd say, and all I did was talk about going to meetups. There were probably at least 30 to 40 local meetups in Utah at the time. And I said, if you want a job, you go to these meetups. And it's not to say, hey, I'm looking for a job. It's because that way you meet the people who are hiring. The people that go to these jobs are hiring managers. We used to get a lot more recruiters than we do now, but they want to refer you. Your friends want to refer you to jobs. And the only way to make friends is to go to meetups. And then it's so natural and easy to socialize with people who have the same interests as you. Like, you can go to a meetup and be like, whoa, you, like, you'll talk about weird things. You'll be like, oh, you also use a Linux laptop instead of a Mac? Or, oh, you like Macs? Or, oh, I've never thought about building a video game in Go. I love it. That was one of our talks was somebody wrote a video game in Go, a Game Boy Advance game that you could run on emulators. And it was so cool. And all of the nerds that play video games now want to do that. Or talk about your, like, there are so many nerds with so many interests. I've had a talk. Oh, somebody who's like, yeah, I wrote a Go library to edit my images for me. So they would do SVG edits on image editing the SVG library. Great. So you like visual input. Like, there's so many facets and interests. And once you make those people with similar interests, you'll never have to look for a job. Like, after my first job, I got my second job from a meetup. I got my third job because I host a conference. And the people recognized my conference. I got my most recent job because of meetups, because I go to so many meetups and people know who I am. And I'm not saying you have to run them. I love when people who don't have experience speak. Because it's new. Like, I love when people share what they do. I do not care how professional it is. I just want to see your demo. Like that's all I want to see. I want to see you run that code you worked on so hard so I can clap and applaud for you. But like, if you want to get a job, you have to find your community. I don't care if your community is online. But the best communities are local in person. That is my unbiased opinion. I just want to emphasize, I think that going to local meetups is one of the best long-term things that you can do to make your job search easier. In other words, if you're just now getting started on your job search and you start going to a meetup once a week, so that would mean you'd probably need to find four different meetups in your local area to be able to go once a week because they usually meet on a monthly basis. But if you can find four meetups that sound interesting to you and go to one every single week, after six months you'll have met so many people in the industry. If you don't take advantage of this, it's like the old saying, looking a gift horse in the mouth. Like I would be suspicious of whether or not you're actually taking your job search seriously. I get that there are some circumstances that make it impossible. If you live really far away from any sort of city that has meetups, or if for whatever reason you work a job that's always in the evening so you're not able to make it. So I get it, there are some circumstances where you can't. But if you can, it is so helpful. Please try to find meetups and please try to attend them. It won't get you a job on week one, but it's very likely to help you out over the long-term. Quincy Larson, the founder of Free Code Camp, which is of course a massive, amazing resource for learning to code for free. Also, of course, the channel that this course is hosted on, on YouTube, Quincy published a book recently called How to Learn to Code and Get a Developer Job. Now, obviously, this course is not about how to learn to code, but it is about how to get a developer job. So I would be super remiss if I did not mention this book. First of all, the book's available for free online, and if you want to read it, I'm going to drop a link in the description below. But what I'm also going to do is read you a quick excerpt from the book. And I got Quincy's permission to do this, so I mean, I guess it's available for free online. So, but we talked about it, okay. The story starts. How did a teacher in his 30s get his first developer job? I had just finished a long day of learning at the Santa Barbara downtown library sipping tea and building projects. The best thing about living in California is the weather. We joke that when you rented an exorbitantly priced one-bedroom apartment in the suburbs, you were not paying for the inside, you were paying for the outside. My goal was to spend as little time in that cramped 100-year-old rat trap as necessary and to spend the rest of it walking around the town. It was a beautiful Wednesday evening. I still had two more days to prepare for that week's hackathon, and my brain was completely fried from the day of coding. My wife was working late, so I checked my calendar to find something to do. So first of all, I understand that, like, depending on where you live, there will be more or less tech events. If you have hackathons in your area, oftentimes hackathons are happening at, like, local colleges or boot camps, and very often you don't need to be a student to go, so just, like, do your research and find them, because hackathons are a great way to get practice. They're super fun, and if you win, there's usually a few prizes, but even better is that you can put on your resume that you won a hackathon, which is awesome. So, on the first Monday of each month, I would map out all of that month's upcoming tech events around Southern California, so I'd always have a tech event to attend if I had the energy. Again, this is just, like, great advice, right? Look on meetup.com, do your research, find all the tech events, and if you have time in the evenings, you should be going. Your network will expand, you'll learn a ton, there's just really no reason not to do it. Obviously, Quincy was in California, that's a great place to be for tech, but even smaller towns have meetups, even if they're small. Ah, tonight is the Santa Barbara Ruby on Rails meetup, and I had already RSVP'd. I didn't know a lot about Ruby on Rails, but I completed a few small projects with it. I was much more of a JavaScript and Python developer, but I figured, what the heck, I need to keep up my momentum with building my network, and the venue was just a few blocks away. I walked in, and it was just a few devs sitting around a table chatting. It quickly became clear that they all worked together at a local startup, maintaining a large Ruby on Rails code base. Most of them had been working there for several years. Now, at this point, I had spent the past year building my skills, my network, and my reputation, so I was able to hold my own during the conversation, but I also had a feel for the limits of my ability, so I stayed modest, understated, the way I had seen so many other successful developers maneuver a conversation at tech events. It became clear that one of the developers at the table was the director of engineering, and he reported directly to the CTO. This is another important point. When I go to our local Go meetup, or our local Rust meetup here in Utah, there's 10 to 20 people, and half of them are managers or C-level technology executives. You get direct access to some of the most influential people in the area, typically, when you go to a tech event. Obviously, that's not true of every area, but it's just like, I cannot emphasize enough how important it is that you take advantage of meetups if they're available in your area. One more thing I'll mention is, if you live far away from somewhere where there are meetups, like say you live an hour outside of a city that has several events, maybe you don't go every week, but maybe you go once a month and make the commute. It really could be worth it for your career. Anyways, something to think about. It became clear that they were looking to hire Ruby on Rails developers. I was candid about my background and my abilities. My background is in adult education, teaching English, and running schools. I just started to learn to code about a year ago. But the man was surprisingly unphased. Well, if you want to come in for an interview, we can see whether you'd be a good fit for the team. That night, I walked home feeling an electricity. It was much more dread than excitement. I felt nowhere near ready, and I wasn't even looking for a job. I was just living off of my savings, learning to code full-time with health insurance through my wife's job. I was a compulsive saver. People would give me a hard time about it. I would change my own oil, cut my own hair, and even cook my own rice at home when we ordered takeout, just to save a few bucks. Over the decade that I'd worked as a teacher, I'd managed to save nearly a quarter of my after-tax earnings, and I would buy old video games on Craigslist, then flip them on eBay. That may sound silly, but it was a substantial source of income for me. What were we saving all this for? We weren't sure. Maybe to buy a house in California at some point in the future, but it meant that I did not have to hustle to get a job. I knew I was in a privileged position, and I tried to make the most of it by learning more every day. There are a lot of strategies when you're learning to code, right? Quincy's story, he was learning to code for about a year, and he was able to do it full-time because he'd been so aggressive with his savings. That's certainly one way to do it. Another way to do it, obviously, is to learn in your off time. I've seen successful cases, or I should say I've seen examples of success doing it both ways. Really, just do what works best for you. I think a year of learning and building is ... You should plan on at least a year of learning and building, no matter what you end up doing. If you're going to quit your job, you really want, in my opinion, at least 12 months of runway before you're expecting yourself to get that full-time developer job. This is just my perception. Same thing. If you're doing an online course like boot dev on the side, you should expect that you'll be doing it nights and weekends for probably at least a year. This is not something that happens overnight, and frankly, anyone that's selling courses or boot camps and promising jobs in 12 weeks, I'd be highly skeptical of that. This is a wide and a deep profession. There's a lot to learn, and doing it in 12 weeks is nearly impossible. Okay, where were we at? In short, I didn't think I was ready for my first developer job, and I was worried that if they hired me, it would be a big mistake. They would realize how inexperienced I was, fire me, and that I'd have to explain that failure during future job interviews. Of course, I now know I was looking at this opportunity the wrong way, but let me finish the story. When I scheduled my job interview, they asked me for a resume. I wasn't sure what to do, so I left all of my professional experience there, all the schools I'd worked for over the years. I left off my time running the drive through a Taco Bell, though. Of course, none of my work experience had anything to do with coding, but what was I supposed to do? Hand them a blank sheet of paper? Well, I did have an online portfolio of projects I'd built, and most importantly, I had a list of all the hackathons I'd won or placed at, so I included those. I spent the final hours before the interview revisiting all the Ruby on Rails tutorials I've used over the past year to refresh my memory, and then I put on my hoodie, jeans, and backpack and walked over to the office. The office manager was a nice lady who took me back to the developer bullpen and introduced me to their small team of devs. There were maybe a dozen of them, mostly dressed in jeans and hoodies, aged from early 20s to late 40s. Two of them were women. I took turns navigating the tangle of desks and cables, shaking hands with each of them and introducing myself. This is where all my experience as a classroom teacher memorizing student names came in handy. I was able to remember all of their names so that later in the day when I left, I could follow up with each of them, great meeting you name, I'd be excited to work alongside you. This is a big deal. This is like, soft skills do matter. When someone tells you their name in an interview, try to remember it and try to use it later. It just goes a long way, and I know it's not like technical advice on how to nail the technical part of the interview, but I can't stress enough how important the soft skills are. First, I met with the director of engineering. We went to a small office and closed the door. A whiteboard on the wall was covered in sketches of unified modeling language, UML diagrams. A rainbow of dry erase marker laid out the relationships between various servers and services. I kept glancing at the whiteboard, fearing that he'd send me over to it to solve some coding problems and demonstrate my skills. Maybe the famous fizz buzz problem. Maybe he'd want me to invert a binary tree. But he never even mentioned the whiteboard, he just sat there looking intensely at me the whole time. They were a company of about 50 employees with lots of venture capital funding and thousands of paying customers. Mostly small businesses. They prided themselves on being pragmatic. At no point did they inquire about what I studied at school or what kind of work I did in the past. All they cared about was, look, I know you can code, he said. You've been coding this whole time, winning hackathons, I checked out your portfolio projects, the code quality was okay for someone who's new to coding. So for me, the real question is, can you learn how we do things here? Can you work with the other devs on the team and most critically, can you get things done? Bootdev right now has six employees. These are the exact same questions that are going through my mind when I'm hiring. I don't have the luxury to care. I don't have the luxury to care about your degree. I don't have the luxury to care about if you can solve hard lead code problems at my stage of company. Right? Bootdev is not as big as this company, it sounds like, they've got 50 employees. But the idea is similar. Oftentimes at these small companies, we're asking very basic questions about can you just ship working code? Can you do it quickly? And can you learn the stuff that we're using? Can you follow our processes? Right? I gulped, leaned forward, mustered all the confidence I could. Yes, I believe I can. Confidence is good. It's good. He said, good, good. Okay. So I went downstairs. The CTO should be down there in a minute. So I talked with the CTO over noodles, mostly listened. I learned that people project intelligence, I learned that people project intelligence onto quiet people. Listening intently not only helps you get smarter, it even makes you look smarter. This is interesting. It isn't something I struggle with. I like to talk. But being a good listener and asking the right questions at the right moment, I completely agree with Quincy here, it does make you look smarter. The approach worked. The meeting lasted about an hour. The noodles were tasty. I learned a lot about the company history and the near term goals. The CTO said, okay, go back up and talk with the director of engineering. And I did. And he offered me a job. Now I want to emphasize this is not how most people get their first developer job. I get what Quincy is saying here. And who knows, Quincy might even have data on this that I'm not privy to. But I've been interviewing people on the Backend Bancer podcast. And I'm coming to believe more and more that weird stories like this are actually how most people get their first job. And that the traditional hiring cycle actually is more common for second, third, and fourth jobs. But that's just been my perception from the few anecdotes that I have insight into. Now you're probably thinking, gee, here, Quincy is forced gumping his way into developer job that he wasn't even looking for. If only we could all be so lucky. And that's certainly what it felt like for me at the time. But in the next section, I'm going to explore the relationship between employers and developers and how me landing that job was less about my skills as an interviewee and more about the year of coding, networking, and reputation building that preceded it. This wasn't a cushy job at a big tech company with all the compensation benefits and company bowling alleys. It was a contractor role that paid about the same as I was making as a teacher. But it was a developer job. A company was paying me to write code. I was now a professional developer. Again, if you're interested in the rest of the story and want to read the full book description, link in the description below, definitely go check it out. This is really important. This wasn't a cushy job at a big tech company with all the compensation benefits and company bowling alleys. It was a contractor role that paid about the same as I was making as a teacher. I was making less than a teacher in my very first developer role. But getting a developer job and being paid to write code is like this binary thing. You go from never having any developer job to having a developer job, forget what the developer job is for a second, but just having one is this huge switch in your life. And going from a mediocre developer job to a great developer job is much easier once you have that year of experience on your resume. Now, virtual meetups are also a thing, and they are definitely worth your time if you can't do in-person meetups. It's going to be one of those things that's better than nothing. The thing that I found with virtual meetups is they're usually more about the talks and less about the networking, just because often it's a lot harder to do networking. Just sit and chat with somebody over Zoom. But if it's all you've got, it's worth at least trying out. Next, I want to spend some time on online communities. We've talked about how you can go find Slack communities and Discord communities and find jobs there, but I want to talk about the networking that you can do in an online community. For example, here I've linked the Boot Dev Discord. That is an online community. There's also a free Code Camp Discord. That is an online community. There's a Golang Slack, like an official Slack for the entire Go programming language, and there's also a Discord for the Python programming language, which is very large. There's tons of these communities on Slack and Discord that are essentially just instant messaging platforms. There's a right way and a wrong way to network in these communities. The wrong way is showing up out of the blue and asking for favors. Don't do that. But similar to meetups, if you hang out in one or two, or I would say at most three, because you probably won't have time for more than three, you hang out consistently in these communities and become known as a regular. That's a pretty powerful thing. It's almost as good, probably not as good, but almost as good as being known as a regular in a physical meetup. Occasionally people come into the community and they're hiring, or occasionally someone else in the community's company is hiring. If you're good friends with them because you chat with them daily in Discord, you're much more likely to be considered for one of those opportunities. Once you get to know all of these people, they won't be bothered when you make a few posts about how you're looking for work. Maybe you turn it into a story so it doesn't just look like an advertisement for the fact that you're looking for work. Maybe it's, hey, I've been looking for a job. These are the places I've applied. These are the places where I've found more luck, or could you review my resume? There's ways to share the fact that you're looking for work. That's more of a feedback, learning-driven approach than just an advertisement approach. Asking for feedback on a project, or on a resume, or on your LinkedIn profile. Those are great ways to let your friends in the community know that you're looking for work. Again, if they like you, which is something that you can't fake, you just have to be likeable and hang out in these places and build real relationships, but if they like you and they know you're looking for work and they have an opportunity, they might share it with you. Several of the jobs that I've had in the latter half of my career have been due to my network. I'm going to recommend three types of communities that you'll want to think about spending a good amount of time in. The first is either the boot dev discord or the free code camp discord. These are like discords that are dedicated to learning code. These are not places to network for jobs. They are places to network for learning to code, but not for jobs. That's place number one. The other two places are going to be more useful for jobs. The first is official tech community communities. I don't know how else to say that, but the Python discord or the Go discord. Hanging out in there, that can be a great place to, over time, be exposed to opportunities. The second one is actually local communities on Slack or Discord, so virtual versions of local communities. For example, here in Utah, there is a Slack called Forge, Forge, Utah. It's a fantastic Slack for the Utah area that's all about tech and business in Utah. Hanging out on there, making friends there is a great way to get exposure to all the new jobs that are getting posted as they get posted. A lot of times when a company posts a new job on a job board, they'll immediately post it in these slacks and fast track those people that are applying through the Slack because they've found that higher quality candidates tend to hang out in there. Local area and tech project communities are great places to be. I'd be remiss if I didn't at least mention social media. Some people have a lot of success on social media. You can definitely think of some tech fluencers, for example, who probably get lots and lots of job offers because they have a lot of followers on Twitter or YouTube or LinkedIn or wherever. In my experience, those things tend to follow a distribution curve that's not looking good in the average case, I guess is what I would say. If you do really well on social media, if you have tens of thousands of followers, then a platform like Twitter might be a great place to advertise that you're looking for work. You have 10,000, 100,000 followers. You can probably find work on Twitter. If you have a couple hundred followers or less, it is extremely unlikely that you will find work by making posts on Twitter. I would say in the average case, social media is just going to be a waste of time. There are exceptions. If you have a decent following or good engagement on those platforms, then maybe it'll work out for you. I just want to caution and say if you notice you're spending a lot of time on social media and you're not getting any bites, it's probably not the best place. Online person meetups, online communities, niche job boards, those are the places that you're going to get better returns on the time that you invest. Before we move on from the networking chapter, I want to play you one more clip from the Backend Banter podcast. I had Don the developer on the pod. He talks about how there are good ways to ask for warm intros and there are good ways to DM someone asking them about a potential job or what it's like working in a company and there are bad ways. Let's cut to this clip and he'll tell us a little bit about the pros and cons or I guess I should say are the good strategies and the bad strategies for reaching out to people. This one could be a little bit more complex. I think the default answer is networking is king for a lot of people but this one has nuance as well. You can submit a templated DM to HR and a lot of people try to connect with, let me give this example. When I was a software engineer, it was my second company or a second dev position, I would have people reach out that obviously wanted to work at that company. They had been given the advice to reach out to a software engineer and have coffee. I would always make them commit to buying me a coffee to make sure they were committed. I would never actually make them pay for it. I wanted to get past the feeling of if I'm going to give you some of my time to talk about software engineering, at least take it seriously and that's what I was trying to weed out. As a hiring manager, you probably have to do that a lot. There were different engineers that were very upfront, very honest, very authentic and they were just like, I'm really interested in your company but I also want to really get a feel for what it's like to work at this company. I had a bad experience before and I honestly, before I even apply, I want to get a feel for it. Is that okay? I'll buy you coffee. That's fine. I love that. People that would have very lazy, tiny messages and expect me to take my lunch and have coffee I would actually take part of my lunch as a developer and go have coffee with them and they wouldn't even be willing to pay for the coffee. Again, I never made them pay but they weren't really committed. It felt like they did that for 50 different companies. I'm like, I'm not going to waste my time with you. This actually feels crappy that you're doing this. A lot of people have this misconception like reaching out to the engineering team or reaching out to HR, you always have to do it. Not necessarily if you're going to do it with that kind of strategy. If you want to do it, I think showing genuine interest when you're doing the cold application approach to then reach out to HR and say, hey, I'm actually really excited about this position. I love it for these reasons. I just want to let you know I did submit my resume and I am still interested. Just something casual. You could word it a little bit different. That can make your cold approach a little bit more effective but ideally the other approach and you've got to dedicate a little bit of time to this. I don't think you have to dedicate four hours every day to this but go to a meetup, participate in a hackathon, get involved with the developer community, meet other developers, not as a salesman saying, hey, can you get me a job? Don't ask for that value immediately with that person. Just treat it like any other interaction. Provide that value up front. Have a casual conversation. Make it fun to talk to you. Just ask what they're doing. Genuinely be interested in what they're doing. If you do that, an interactive fact is usually people want to hear what you're doing. They want to hear what you're going for but a lot of people take this approach and they just act like a salesman. They actually get a business card which is fine but their goal is to just give that business card out to everyone that they're a developer and if they're looking for a development. I think how you do it, you have to, I think a very warm approach that's very effective is to get involved with the developer community, meet people, talk to them, have an empathetic conversation with them and I see that naturally. It's a more long-term strategy in my opinion but that will naturally build up your network and even if you're doing it with other aspiring developers, that aspiring developer gets hired and the company before they even make the public job posting, they're like, hey, they should just reach out to the team. Hey, do you guys know anyone that might be a good fit for this? You already are standing out among so many other cold applications by that aspiring developer that likes you. They had a good interaction with you. Whether they, hopefully they can have a little assessment of where you are technically. Maybe they worked on a project but still, that's a cultural fit that's getting you in the door and now you have that in. Don't focus so much on trying to meet, go to networking events to meet the right people. Just talk with other people. Have those empathetic conversations. Build those connections and just be a human being and try to give back to the developer community. That eventually gets noticed when you're transparent enough to have all these conversations. A natural, warm approach is very effective in the long run and it typically can get you so many interviews, at least interviews, because a lot of people struggle getting interviews. That can get you in interviews so you can actually speak. You're not just a piece of paper and then you can warm up to them in the interview. Then it's the same approach. It's just an empathetic conversation, having fun, talking about Twitch and gaming, whatever you can relate to and what you love, what you're passionate about with coding and engineering. You got to let that conversation flow naturally and that warm, it's just about building connections with those warm leads. That's effective. I would argue you should probably spend, I don't know, I usually say spend maybe two to four hours per week just really trying to get connected with developers and building up your network and just creating relationships. I don't think, majority of your time should be spent towards project work, hands down, really building up your skills, but like a little bit of time extra and just getting involved in a dev community is huge. I think that the networking, the warm leads, it's a more effective approach, but it's a long-term approach. If you're struggling, you're like, I need a job right now, probably should consider picking up a part-time job or something else, get your income in order. It's building relationships and building that network can take a little bit of time. It's effective, but if you're doing it short-term, you're going a hard, cold application approach. It's time to talk about interviews, but before we talk about interviews, I want to set the stage and talk a little bit about how it's all just a numbers game. Once you understand that, it's a lot easier to make it about the long-term rather than the short-term and stop yourself from getting discouraged. Let me show you what I mean. Let's draw a sales funnel. What happens with a sales funnel is when you're a salesperson going door to door, it's a numbers game at the end of the day. You're going to knock on 300 doors. Of those 300 doors, 150 are going to answer. You immediately lose 150 people in this example funnel. Of those 150 people, maybe only 25 talk to you for more than five minutes. Of those 25, maybe only 10 agree to give you a phone number, and then of those 10, maybe only two pick up when you call, and then of those two, maybe only one buys your product. With that kind of a sales funnel, you know that if you talk to 300 people, you'll probably get one sale. If you want two sales, you need to talk to 600 people. The trick with applications is figuring out that it's really just a sales funnel. For example, let's say that you send out 100 applications, and then of those 100 applications, let's say that you hear back from 25 of them. Of those 25, let's say that you get, say, 15 phone screens. Of the 15 phone screens, say you get five interviews. These numbers, 100, 25, 15, 5, they might be different for you, but this isn't too unreasonable. Getting five interviews from 100 applications. Oh, and we should actually go a step further, because interviews aren't the end goal. The end goal is to get an offer or two, let's say you get two offers. You might not be in a place where you actually get two offers, you might get one offer, and it's just take it or leave it. If you get two offers, that's fantastic, because now you can make a choice, but you get the idea. From 100 applications, you might only get two offers. Your rate might even be worse, like who knows, I can't tell you for sure. I believe when I went through this process with my first job almost a decade ago, I believe I sent out around 100 applications, and I did around six interviews, so it actually would have been really close to this. I did not get two offers, I got one offer, but sometimes that's just how it is. The point though, is that after sending out 40 applications, you might only hear back a couple of times. My point with this whole thing, with drawing out this funnel, is just that you shouldn't be discouraged when you send 20 applications and don't hear back. Also those first 20 applications are probably going to be the worst ones, because hopefully over time, you're honing your applications, you're getting better at that whole process. This is something that as time goes on, we talked about this at the very beginning of the course, as time goes on, you want to be getting better and better at programming, and also better and better at applying and interviewing. These five interviews, maybe the first four you don't get offers from, but they're great practice. You're not going to knock your first programming interview out of the park, unless you're a prodigy, you're really lucky. Practice helps. So anyways, keep in mind that it's all just a numbers game, and you do have to apply and put yourself out there a lot before you start to see some results. Let's talk about interview tip number one, and that is to relax. You might be thinking, is that actually useful advice? It can be really nerve wracking to be in an interview, and I understand that just telling you to relax probably doesn't seem super useful. Let's talk about a couple of things that might A, help you relax, and B, realize why it's so important. The first thing is that you probably aren't getting the job. This is an unfortunate reality, but when you get an interview, I really don't want you to get your hopes up to the point of thinking, wow, they're interviewing me like I'm landing this job. It's the same thing as the funnel going from a hundred applications down to five interviews. Five interviews, you might get one offer. That means four interviews where you don't get an offer, and again, I don't know exactly what your conversion rate on interviews is going to be, but it certainly is not going to be 100%. Even as a senior developer, I'm not converting half of my interviews into offers. Understanding that you probably aren't going to get the job and realizing that this time you're spending on the interview is extremely useful for practice is kind of freeing in a way. If you think, well, I only have a 10 to 20% chance of getting this job anyways, hopefully that kind of calms your nerves. Get what you can out of the process. Do your best. Ask a ton of questions. Take notes and try to figure out how you can use the experience of practicing for this interview in your next interview. The more interviews you do, the better an idea you have of how these things work so you can get better and better at it. Now the next one is pretty similar, but it's just this isn't a waste of time. It can be really tempting and kind of discouraging to think to yourself, I've done seven interviews, I haven't gotten an offer yet, so I've just wasted all of that time. That's not a very useful mindset. If you go into seven interviews, completely bomb them, and at the end of the seven interviews, you have no idea what you did wrong, then yeah, I guess you kind of have wasted your time or at least you've wasted a significant portion of it. You really want to, once you have seven interviews under your belt, have a really good idea of how these interviews work and try to figure out what you're doing that's working and what you're doing that's not working. This shouldn't just inform your job application process. Everything you're doing while searching for a job should also inform how you're spending your time learning more about programming, honing your craft, and what projects you're building because you might just find that your portfolio projects are just a swing and a miss. They're not interesting, nobody's asking follow-up questions in the interviews, and so go build a different project. You can take this feedback that you're getting in the interviews and apply it into how you're improving as a developer. The last point I want to make here is just that you'll get more chances. If you're getting interviews through cold applications, for example, especially if you live in a tech hub, or if you're applying for remote jobs, there is an endless amount of jobs. There's tens of thousands of jobs out there that you can apply for and interview at, and so when you miss one, the impact that that has on your future ability to get jobs is effectively zero. It's not like there's only 10 available jobs, and when you fail with all 10, you're done there's nothing left. That's not how it works. The more else you take, the more interviews that you fail at, the more practice you'll have so your chances should actually go up over time, and again, that should just be a thing that makes you feel better about the whole process and hopefully stops you from getting discouraged when you do get some rejections under your belt. The next thing I want to talk about is having confidence in the interview, and again, I understand that this isn't just useful advice. Everybody knows that you should be confident in interviews. It's one of those simple things that's actually really hard to execute on, so I totally get that, but I just want to reiterate something that I said earlier in the course, which is that I've never met a true entry-level developer, so someone who has not yet had a programming job that had too much confidence or came across as egotistical. That definitely happens in the programming world. I've just never really seen it at the entry level. It happens at the junior level, like say once you have six months or a year worth of professional experience, I think that's a little more common, but what I've seen from entry-level candidates is that there's always this lack of confidence. There's always a sense of, I'm going to downplay my accomplishments. This is just a toy project. I just did that. I've only learned this. Please don't downplay your accomplishments with that kind of talk. It really is your job in the interview to talk yourself up, because nobody else is going to do that for you. This is going to come across as borderline facetious, but the number one tip that I have for being confident in the interview is to just be good. Be good at coding. That doesn't mean you need to be a senior developer in order to get an entry-level position. That's not what it means, but it does mean that as time goes on and you build more and more projects, you should be more and more confident saying that you can solve problems. If you've actually built a JSON API and deployed it end-to-end in the cloud with DNS and everything, then when someone asks you about that in an interview, you won't have to try. You'll naturally be much more confident, like, oh, yeah, I did that thing. Oh, yeah, I used AWS. Oh, yeah, I deployed domain name records. Oh, yeah, I hooked those up to a static IP. When you do that, you get so much more confidence just right out of the box. That's part of the reason why I say, as time goes on, don't stop learning and building because your confidence will naturally grow over time. I don't have any useful, like, self-help tips for faking confidence. Maybe you can read some good books that I'm not aware of to get better at that if you really struggle with it. But the best thing that you can do is actually ship code, either in your own personal projects or in open-source contributions or, like we talked about earlier, working for a nonprofit or something like that, doing that will naturally give you a lot more confidence in your abilities. Now, the other thing I want to say on this point is that the reason, the reason that you should have confidence is because people want to solve their problems, not yours, right? So we talked about how earlier... Well, we talked earlier in the course about how you don't want to come across as a charity case, right? That's a negative signal. You don't want to go around begging for jobs. That's not a good strategy. And the reason for that is that hiring managers, recruiters, like their lives aren't easy either, and they're looking to solve their problems, right? Marketing departments at successful companies are always putting out messaging about how their company can solve their customers' problems. It's not about what the customer can do for the company, right? It's about what the company can do for the customer. And when you're searching for a job, it's not about what the company can do for you, right, by giving you a job. It's about what you can do for the company. And even more specifically, it's actually about what you can do for the person across the table from you, right? It's important to remember that companies are this, like, made-up organization, right? They're kind of figments of our imagination at the end of the day. Really, when you're on the phone with a recruiter, with an HR person, with a hiring manager, they're a person and they have problems. And if you can align everything you're saying around how you can solve their problems, that's going to work out much better for you. So this brings me to my next point, which is just that companies don't hire people. People hire people. This is a really important idea to understand, right? Companies, again, are not living entities. They don't have their own intrinsic feelings and motivations and emotions and needs, right? People do. People work in companies. But when you take an individual team lead, right, the lead of an engineering team within a larger organization, they are somewhat aligned with the mission of the company, right? They want the company to do well. They want the company to make money. But at the end of the day, they have their own incentives. And when you're being hired by this person, you need to keep in mind that a lot of the way that you talk about what you can do, you should be talking about it in the sense that it solves that person's problems, right? The person who's actually going to make the decision about hiring you, it's that person's problems that you want to address as an employee in order to get yourself hired. So over in the text version of this course on Boot Dev, I mentioned that people hire people who solve their problems. They're not always looking for the absolute best developer, right? The most technically proficient candidate in the pool. That's not always the person that gets the job, right? Just because you solved the hardest lead code problem doesn't necessarily make you the best candidate. There's a lot of stuff that goes into it. So some of the points that are very common in companies is like the person that's hiring you, like they want their time saved. They don't want to have to put more time into training you, right? So reassuring them that you're a quick learner, that you're a go getter, right? That you're great at figuring things out on your own. Like those kinds of things can help alleviate concerns that you're not going to add to their plate, but instead you're going to take things off of their plate, right? People want to look good, right? Your hiring manager wants to have hiring you be a decision that makes them look good in the long run. So again, anything you can do to prove that point is great. They want their life to be easier, not harder. A lot of people just want to build out their team, right? A lot of managers are playing kind of internal politics within the company, and they're just trying to grow a team and have more people reporting into them. I don't think there's too much that you can do with that information, but just kind of recognize it as a reality. They want to deliver the project that will secure their next promotion, and they want you to be fun to work with. And this is actually a really important point, right? So I mentioned that it's not always the best lead code solver that gets the job. And part of it is that it's not always just technical proficiency, right? Oftentimes a manager just wants to know that you're the kind of person that can see a project through to completion, right? If I have one person that can code faster than another person, right? Maybe even code more accurately. But they're just not the kind of person that takes projects over the finish line, right? They're always kind of leaving it half-baked. There's always extra testing that needs to happen once they turn in their work. Those are things that managers are extremely wary of. Like, for me, it's okay if it gets done 10 to 20% slower, if it means that I don't have to be pulling in extra resources to get something done. So there's more at play, I guess is all I would say there. And then being fun to work with, this is a huge one. When someone hires you, they are going to be spending a lot of time with you, right? So even if you're the best developer in the world, if you're kind of a jerk and you're not fun to be around, you're going to have a much harder time landing a job. So anything that you can do to show some personality, to show that you're fun, to show that you're happy, right? This goes back to earlier when we talked about not being a downer, right? You want to come across as just a fun, energetic person to be around, that actually goes a long, long way. I have turned down candidates solely based on the fact that I thought myself and the rest of the team would not enjoy working with them, right? That's a totally valid reason to turn down a candidate. So just be very aware of that, right? The people assessing you are going to have to work with you all the time, so do everything that you can to make it look like you're going to be fun and pleasant to work with. So some of the questions that your interviewer probably has in their head are going to be things like, will I have to hold your hand constantly, right? Will you learn the code base and be able to contribute quickly, right? Am I going to spend 12 months getting you up to speed or three months, right? Do you bring new skills to the team, right? Do you just know all of the same things that we know or do you know something extra? Do you have some experience in your background that might be useful to our team? And sometimes that's not even coding knowledge, right? Maybe they have a team of three front-end developers, but like, I don't know, nobody's good at Photoshop, right? If you know Photoshop, that might be something extra that you bring to the table that might help sway everything in your favor. Will you be able to quickly learn the things you need to know but aren't yet familiar with for this role? This kind of goes hand in hand with how quickly you'll be able to contribute. But I can just tell you from experience, I've, have I ever, I don't think I've ever hired someone where I was confident they were like familiar and had used every tool that we used for that position. In other words, there's always been some amount of training that's had to happen, right? Like maybe I hire a back-end developer who's used Go, but they've never used Postgres with Go or they've never used our specific ORM, right? Or they're familiar with AWS. We happen to use GCP. If there's only a couple of those things missing, it's usually just fine. In fact, I've, like I said, I've never really had a perfect match on that level. But what that means is the interviewer is just thinking, how long is it going to take this person to learn all of those things? And the better job you can do of demonstrating that you're the kind of person that can learn, the better you'll be. And just remember with everything you do when you're applying or this honestly applies even more broadly to like all sales and marketing. And remember, you're kind of selling your services when you're applying for jobs. It's much more powerful to show than to tell. So saying, I'm a fast learner, it's like fine. But showing that you're a fast learner is something different, right? Showing that you shipped this really cool project in a month is a lot more powerful than just saying, oh yeah, I picked things up quickly. Now, I know we talked a lot about trying to have confidence in the interview and you should, but let's break it down a little bit because sometimes confidence. Sometimes it can be hard to know what we should be confident about and what we should be a little more humble about. Humility. Because this directly ties into that last point I made, which was you want to be fun to work with, right? And egotistic jerks are not fun people to work with. So, okay, what should you be confident about? Let's make a little list here. I think you should absolutely be confident about your ability to learn. This is like universally a good thing in a hire. So you want to be able to demonstrate that and you want to be confident in that. You do not want to downplay your ability to come up to speed quickly on things. So absolutely. Another thing you want to be confident about is your understanding of your projects. Right. So you've built some projects. You really should be confident in the fact that you built them, right? You don't want it. You don't want to make it sound like you stumbled through a tutorial. And by the way, you shouldn't have stumbled through a tutorial on these projects. You should have built them by yourself with a lot of research and, you know, doing a lot of things from scratch. But this is, this is an area you should be confident in. And if it's, if it's not, then like you should spend some more time on your projects. Um, something you should be humble about is your overall knowledge of the industry. Right. And this is, this is a key point because no one is expecting you to be familiar with everything. I know sometimes it can feel that way when you read job descriptions. It's like you need to know bash and you need to know AWS and you need to know go and you need to know Python, you need to know JavaScript and TypeScript. You need to know view. You need to know reacts CSS, right? Like there's this laundry list of items that you're supposed to be an expert on. The reality is by the time you get to the interview, especially, right? Once you've gotten past HR and recruiters, um, nobody's expecting you to know everything and no one's expecting you to be an expert on everything. Um, especially in an entry level position, right? You want to show that you're proficient in a couple of things, right? And that you learned quickly, that you were passionate about it, that you like doing it. Um, but don't try to fake knowledge of technologies that you haven't worked with. Right. Let me give you an example. Let's say in an interview that you're asked, um, how much do you know about Mongo DB? You may have never even heard of Mongo DB, right? But let's just say that you've used Postgres and because there's DB in the title of the name, this is Mongo DB, you can kind of infer that it's a database. So what I would say is something like, I actually haven't had a chance to use Mongo DB. That's a database, right? Which you hear that and you might think that sounds really dumb. Um, but they're probably gonna go, yeah, yeah, it's a database. It's the one that we use, um, on XYZ project. You go, okay, cool. I've used a lot of Postgres and I've read a lot about SQL and no SQL databases. I'd love to work with more different kinds of databases. So far it's mostly been Postgres and MySQL and frankly, both of those felt very similar to me. I know they both use a very similar dialect of SQL, for example, but like you want to be upfront about the fact that you haven't used the thing yet because that's not going to kill you in the interview for the most part. Um, but then try to tie it back into something you do know, right? So when someone says, have you used Mongo DB, your answer probably shouldn't just be, no, I haven't. That's not only unimpressive, it's also a little awkward. Like what's the follow up, uh, for, for that conversation. So you, what you want to do is say, Oh, I haven't used that. Or, Oh, I don't know, but, and tie it into something that you have done. One more thing I'd like to mention is you really should be confident in like, you should be confident in your passion for coding. Right. You should be really confident about the fact that you love to write code and that you learn, you love to learn new things. Um, but you should be really humble about the process. Right. So for example, agile versus scrum, test, test driven development versus literally anything else. Right. Like you're probably, you've probably been exposed over the course of your learning journey to a lot of these buzzwords, a lot of these processes that are used in the industry to actually ship software, right? Things like agile, scrum, Kanban, test driven development, domain driven development, right? Clean code. Like you'll have heard all of these things. Um, some of them are more controversial than others, but what I would say is when this kind of stuff comes up, you want to mention that you've heard of it if you have, but you don't want to take a hard stance on it. Right. You really want to be humble about the fact that you haven't used test driven development in production yet. Maybe you think it's interesting, right? Maybe you've done it on your own projects, but you're open to the, you're, you're really open to the idea of learning from the team and kind of adapting to their processes because at the end of the day, that's really what they want. When someone hires an entry level developer, they're not looking for hard opinions on how to improve their processes. They're looking on someone that they can train to do the things the way that they're already doing them. When they hire a senior developer, they're much more interested in that like industry experience, right? And they might want to have their quote unquote processes fixed, right? But, but when you're new, they're probably hiring you because they want to train you to do things their way. Let's talk a little bit about the actual interview process and right up front, I want to be very clear. This process will change from company to company. Every company has their own process, right? And it's something that you should be extremely comfortable just asking about up front, right? When you get on the phone, when you get on that very first phone screen with whoever it is, whether it's a recruiter or HR or even the hiring manager themselves, just ask like, you know, what does the interview process look like? What should I expect? What should I prepare for? Right. But it usually looks something like these five steps. So you've got a phone screen that happens after someone has reviewed your application, found it interesting. They just call you up, right? They want to hear your voice on the phone. They want to hear that you're a real person. They might ask you a few kind of follow up questions just to verify different things that you've listed on your resume. Make sure that they're legit, but the phone screen is not an interview. So like really, really, really don't be stressed. Like do not be stressed on the phone screen. They're just trying to kind of see that you're real so that they can get the rest of the process started. The next one might be a homework assignment. Not all companies do homework assignments. I have found it tends to be a little more common with entry level positions than not, but but really it's it's usually just like a one or two hour coding challenge. That's they're really trying to weed out like the low effort of pliers with homework assignments. You'll hear a lot of opinions out there about homework assignments, you know, whether you should take the time to do them. It's kind of unfortunate that like you're not paid to do this two hour coding challenge. My recommendation is just if you have the time to do them, do them, right? Like when you're an entry level developer, like beggars can't be choosers. It's no secret that the industry at the moment is not great for entry level developers, right? And it gets much better once you have some experience. But like the great thing about a homework assignment is if you do it well, drastically increases your chances of doing well in the interview. But also it's it's a challenge like it is coding practice. It's something that you should be spending your time doing anyways, right, learning and improving. So I don't really view homework as, you know, something that should be avoided at all costs. Although, of course, you do need to limit the amount of time you're spending on these things. If you've got 10 homework assignments to do, that can be unreasonable and you might have to turn some down. Now, next comes the actual interviews. There's typically a cultural interview and a technical interview. This could go in either order. It might just be one single interview. It might be multiple interviews. As a rule of thumb, the larger the company, the longer the hiring process with more interviews involved. Usually small companies tend to move a lot faster. But the cultural interview oftentimes is with somebody higher up than just like the technical team lead in my experience. Oftentimes, if it's a smaller company, you know, think 25 to 50 employees, it might just be the CEO themself, like just getting to know you and seeing if they like you. Right. Because the CEO might not be managing your technical abilities directly, so they are kind of outsourcing the vetting of your coding abilities to, you know, say the team lead or something, but they are very interested in whether or not you'll be a cultural fit. And cultural fit is just corporation speak for like, are you fun to work with? Are you hardworking? Are you driven? Right. And so there's there's usually not too much preparation to do here other than like beyond your best behavior and try to put your best attitude forward. Now, the technical interview, in fact, let me scroll down to to this section on the technical interview. There's usually several different types of technical interviews that you'll encounter. Whiteboarding problems are very common. That's where you essentially stand at a whiteboard or if you're doing a virtual interview, you might be drawing on some mirror board or sharing your screen while typing in a text editor. But usually you're given some sort of programming challenge, think like a almost like a lead code style challenge, and you're expected to kind of walk through the pseudo code or sometimes like the architecture of how you would solve the problem. Right. I personally, this is an unpopular opinion, I personally really like whiteboarding because it lets me show off how I think about problems without having to worry about, like, nitty gritty syntax or typing problems. Like typing while someone's looking, which is really hard for me, I do, I do really poorly in live coding. Some people really like live coding exercises, which are typically take the form of like a lead code or a hacker rank style challenge where you sit there and you actually write the code out and you compile it and you run it and you look at the results. Again, some people really like that. It's kind of one of the most raw ways to see like, can somebody solve a problem with code? The reason I struggle with it is because again, I really am bad at typing under pressure. I have no problem like thinking under pressure. That's why I do pretty well with with whiteboards, but like typing and fumbling around with my keys while everybody's looking on me and there's a ton of pressure I struggle with. The reality is that you don't get to pick what the interview format will be, at least I've never been able to pick. But that you shouldn't be discouraged when you get an interview of the type that you're not confident in. Like just don't let it get you down. For example, if I just did live coding interviews, let's say I did like three and I just felt awful because I was bombing them and gave up, that would be a huge tragedy because I've landed a lot of jobs through whiteboarding problems in interviews and through architecture and design patterns questions, like I do pretty well at those relatively speaking. And so if you get some hard interviews, just don't let it get you down. Realize that every company is going to have a different process, right? And you might be better at some than the others. And if you interview enough, you will get all different types. Architecture and design questions. These ones are fun. These are like, say you had to build a web app that did X. Like what kind of technologies would you use? Where would you deploy it? How do all of the different deployments talk to each other, right? Is it over HTTP? Are you sending JSON requests? What do the JSON? What does the shape of the JSON objects look like, right? I really enjoy those. Another one that I see a lot less of, but I wish I saw more of, is walkthroughs of past projects. So one of the interviews that I landed and got a job from was a technical interview where just basically for the entire hour, the interviewer said, hey, you listed this project on your resume. Let's pull it up. Let's pull it up on GitHub. Talk me through it. Like, why did you do this this way? Why did you choose this library, right? How do you deploy it? Why did you decide to make the command line flag this instead of that, right? That's a really cool, in my opinion, it's a really cool way to do an interview, but anyways, just realize there's a few different types. And this again, just goes to say, like, you will need to do a lot of interviews because you're going to need practice with each different type of interview. So expect to do, you know, five to 10 interviews before you're getting, you know, an offer or two. Now, there's really a few different types of companies that you can apply for and they all will have very different interview processes. So for example, if you mostly apply to fang companies, so Facebook, Apple, Amazon, Google, Netflix, these companies are famous for doing a lot of live coding exercises, lead code style challenges, algorithms questions. And so if you're primarily interested in those companies, those big sexy tech companies, you're going to have to spend a lot of time, like, grinding lead code and doing a ton of coding challenges to practice and prepare for those interviews. But not all companies are like that. Smaller companies, they're not just interested in bringing on people that can solve hard algorithmic problems. They're more interested in bringing on people that can solve their immediate problems, which in a startup is rarely that they need some tricky algorithmic thing solved, right? Like they just need someone that can ship to production and do it consistently and hopefully with few bugs, right? Generally speaking, they're looking more for generalists than specialists. So just understand that different companies approach things different ways. And I interviewed Melky, a friend of mine on the Backend Banter podcast recently about this exact topic where he talks about how he would approach preparing for in particular fang companies with lead code challenges. So let's cut over to that. And actually, before we cut to this clip, I just want to point out what Melky is responding to was a question I asked him about how would you recreate your current job at Twitch? He's an engineer at Twitch. If you had to start over again and he has some hot takes about lead code and about projects. So let's take a look. Essentially, the first up is buying 90 days, however you can do it. If you have to get a loan to get 90 days, then do that. If you have to just work for, I don't know, four months to buy 90 days, I would do that. The goal number one is to buy time, however you can. And then the first thing I would do is lead code. I would lead code every single day. When I got my job at Twitch, I was lead coding 12 hours a day every single day for, I think it was like four weeks. I stopped streaming. I take this shit seriously, right? Like there's no shortcuts. So I was literally like lead coding for 14 hours a day. All I did, wake up, lead code until I went to bed. Like my eyes would be in a basement, no sun, didn't go outside, didn't work out. Yeah, pale. Yeah, just pale skin, like everything like that, man. And like, I would like smoke jewels to like make sure like I'm, I'm like acting my brain's functioning. But yeah, I'd buy 90, I'd someone get 90 days and then I would lead code for at least, at least eight hours a day of lead code. So I'd wake up. Yes, easy, easy. I'd wake up and I put eight hours every, like seven days. There's no days off. I'll take maybe Sunday days off. Only Sunday would be the day that you can actually relax. So eight hours a day, like that would be your nine to five and then I would give myself two or three hours. So let's say that brings us to like eight or nine and then I'll do projects. I'll build projects using the latest technology. So if I want to be a front-end dev, I'm spinning up T3 stack and I'm figuring out what's going on here. I'm watching Theo. I'm watching Prime. I'm doing whatever I can watching YouTubers build projects. I'm mimicking it, right? I go watch advocacy media. He's doing a course on Mernstack. I'm learning Mernstack and that would be my evenings. That would be like from like nine to midnight or eight to midnight. That might have felt intimidating. Melky goes, goes pretty hard in the paint to say the least. I don't think that in order to get your first job, you need to grind this hard. I certainly did not grind this hard for 90 days, but the point that Melky is making is a very good one. And it's just to point out, look, this is not like this is not easy. There's a lot of competition for these jobs, especially at the fang jobs like the Twitch and the Netflix, which of course is where Melky works. So if you're going to go for a lot of those more highly competitive remote high salaried, right? Those jobs are going to be more competitive and you are going to have to grind and get really really good. So lead coding for eight hours a day is probably going to be useful. One thing that he goes on to say that I didn't include in the clip is just that at larger companies, the lead code thing is really important. At smaller companies, the projects tend to be more important. So as you're thinking about how you're going to divide your time and how you're practicing and preparing for interviews, I would recommend if you're mostly applying for like local jobs or small to medium sized companies that spending time building projects and deploying them and kind of solving real world tasks is going to be more useful. But if you're going to the big companies, then grinding lead code can certainly be helpful. I also just want to give my take on Melky's point about buying 90 days. That is a strategy. I think it depends on your personality. And so it really is just up to you. I wouldn't be so prescriptive as to say that you should quit whatever you're doing and find eight hours a day to just grind lead code and build projects. Not because I don't think that can work like I think it can work, especially, you know, in Melky's case, it obviously did work for him. I tend to be a very low risk person. And so, you know, when I was applying for my jobs, I had a job at a bank and I was coding in the evenings and on the weekends for, you know, maybe two or three hours every night and that worked for me. So find what works for you would be my advice and it's great to hear different perspectives, right? You shouldn't just listen to me. You shouldn't just listen to Melky, but it's good to listen to all of us and kind of synthesize it and figure out what's going to work for you. Now, let's talk about one of my favorite tactics for when you're actually in the technical interview, right? Obviously, you just need to be prepared and to be a good developer. But there are a few tactics that I think you can work into your process that will take you, at least give you a little bit of an edge. And one of them is that when you're doing the technical interview, try to make it feel like you're already on the team. This should feel less like a confrontation or an exam, right? Where the interviewers are like the professor in college and you're like the student. You want it to feel much less like that and much more like a collaboration where you're a junior dev and they're a senior developer trying to help you through a problem. The more you can make it feel like a collaboration, not only will you actually get more help and more hints from your interviewers, but it gives them more of a sense of what it's going to be like working with you and you want that feeling to be a good one, right? You want to show that you are a good collaborator. Okay, so let's give some examples. So a bad example of this would be the interviewer saying, write a function that takes in a string and returns the string in reverse order. And you just saying, okay, and then attempting to write the whole function from scratch and saying, here you go. That's not great. If you happen to nail it and get the function perfect, then that can go okay. But a better example and something that will go go better even if you don't quite get the function exactly perfect is to let's just run through the scenario again. It says, write a function that takes in a string and returns the string reversed. You say, instead of just okay, you say, got it. How concerned about memory are we? Should I try to reverse the string in place or should I try to create a new string, right? So rather than just making an assumption, we're going to ask about some of the constraints of the problem, right? Like this string could be an entire novel, right? It could be like the whole Frankenstein textbook or the whole, I guess, Frankenstein novel written by Mary Shelley, right? Hundreds of pages of text shoved into one string, in which case our solution might look a little bit different, right? Because we have different things we're trying to optimize for. So even if you're confident that you think you know what the interviewer is looking for, just the fact that you're asking follow-up questions actually shows a lot of good things about your problem-solving process. So I highly recommend asking follow-up questions, really good for collaboration. The interviewer then says, okay, let's say we're not concerned about memory. We just want a solution that works. That's great. That like makes the problem less unknown and actually makes it a little simpler, right? We can just like forget about keeping, you know, performance optimized, which is great because you might have sat there and struggled with trying to come up with the most performant way to reverse a string when really all you need to do is get something working. So moving on, after they give you that that little hint, you say you go ahead and write the signature of the function. So this would just be like in Python would be like death reverse and then like S is the input and like that's it. Just just the signature and you might ask a follow-up question. We just want a single string in single string out, right? And what this means is you're just writing a part of the function and you're making sure that you're on the right track because the last thing you want to do is get like 10 minutes into solving this thing only for the interviewer to be sitting there puzzled. Like what are they doing like that? That's not at all what I asked for. So you kind of want to be doing is prompting for feedback as much as you can as you work through the problem. It's not just good for you because you'll get more hints. It's good for the interviewer because it shows them how you think through this stuff, right? Which is actually more impressive rather than less. So we want single string in single string out, right? Interviewer says, yep. And then while writing the rest of the function, you might say, okay, so I'll just create a new string. Loop through the input string backwards and add each character to the new string. This should handle cases of empty strings automatically. The point here being rather than just like silently writing the code, you can break the awkward silence by in English kind of just explaining what you're doing. And again, there's a few advantages to this. The first is if the interviewer hears that your thought process is like way off, they'll probably try to steer you in the right direction before you've even written the whole code. But if you just sit there and write it in silence, you might sit there for five minutes, like struggling to put something together that makes sense. Only then for the interviewer to be like, oh, actually that code doesn't quite look right. Like maybe try this other thing. So if you if you kind of say what you're thinking up front, it improves the feedback loop and you'll just get those suggestions earlier and you'll have a better overall result. So some of the key differences are we want to ask a lot of clarifying questions, which means we're less likely to write any incorrect code, which is obviously great. We're communicating our thought process, which means the interviewer can help us when we get stuck, which is great. It means the interviewer gets to see what we think, which again, it provides more signal. The whole point of this whole process is the interview just wants to know, are we qualified and by us, audibly, you know, announcing our thought process, it tells them more about whether or not we're qualified. So that's good. It shows that you think through edge cases, something you'll need to do on the job, right? So a lot of times you can just say an edge case and the interviewer will tell you whether or not you actually need to write the code for it. Oftentimes just saying the edge case is is enough signal to the employer, like, hey, this person thinks through edge cases. We don't actually have to, you know, write all of that extra code, but now I'm glad to know that you thought of it. It also shows you're a great communicator, which is like super critical to being a developer. I think this is often overlooked. We think it's just about, you know, heads down being a code monkey, but actually so much of what we do as developers is communicating with the other developers on the team. It's communicating with stakeholders, with project managers, with designers. And so just showing that you're good at that whole process is extremely valuable. The last thing I'll say is you want to use words like we and us instead of you and me, right? So do we want this function to take a string and return a string is a lot better than do you want me to write a function that takes a string and returns a string? And it's actually just a really simple reason. It's it feels a little more helpful and friendly, right? It's a little it's a little warmer of an interaction. It also kind of implicitly assumes that you're already on the same team, which is I don't know if that's I don't think that I don't think that's sleazy, but it's like this, you know, this like little implication like I'd love to be on the team. But it actually goes a long ways and just in terms of making the whole process feel a lot more collaborative. So something that goes along with being on the team is asking a lot of questions. And when you're in school taking an exam, usually questions are not allowed, right? The professor doesn't allow you to just raise your hand and ask for the question to answer five or even to ask for help on question number five in an interview. It's different. Yes, you can't usually just straight up ask for the answer, but you almost certainly can ask for help and you can certainly ask for clarification. And it's really important to just understand that asking questions makes you look smart. It doesn't make you look dumb, right? Not asking any questions frankly makes you look a little incompetent because on the job when you're handed requirements from product like build this feature, it is rare that the requirements are in such pristine clear condition that you can just go code it without asking any follow-up questions, right? So you want to show that you're thinking about the problems and that you're thinking about edge cases and in order to deal with that you have to ask a lot of clarifying questions. So smart people ask a lot of questions, they're knowledge sponges, right? Smart people want to learn as much as they can and generally speaking people want to work with other smart people. So the first tactic I want to mention here is that you want to turn any question that you would response to an I don't know with into a conversation. So when you're presented with a question that you don't know the answer to, the absolute worst thing you can do is try to fake it. The worst thing you can do because if you're wrong and it's obvious that you're faking it, a lot of trust is lost, right? The interviewer kind of assumes that you're lying a little bit or you're exaggerating your abilities. The last thing you want to do is to say that it's X confidently when it's really not. So when you do know something, say it confidently, right? When you don't know something, it's really good to own up to the fact that you don't know it, but there's a good way to do that. If you just say I don't know, there will be an awkward pause, right? And we want to avoid awkward pauses in the conversation. So, hey, Lane, have you ever worked with Postgres or I guess that's not the right question. Let's try again. Hey, Lane, how does Postgres index rows on disk? I don't know, right? That's not the right way to answer. We want to give them a little bit more than that. So let's take a look at an example, a bad example. So the interviewer says, what is a closure and when would you use one? And you say, I think it has to do with functional programming, but I don't know. So that's not a great answer. Although it is a little better than just a, I don't know. That's kind of the worst case scenario. So a better example, what is a closure and when would you use one? You respond with, I learned about closures when I took a course on functional programming, but I don't remember all the details. I do remember using them in my link aggregator project. Did it have something to do with functions and state, right? So functions and state is actually pretty vague, right? Everything that functional programming aims to address has to do with functions and state. So even if all you can remember is that sometime in the past you heard about closures in your functional programming course, the better that you can do or the best that you can do to take a stab at a guess or try to relate it to a project you built, that's going to go a long way and like giving the interviewer a way to follow up and provide explanation. A lot of times they'll just straight up explain to you what a closure is and you can be like, oh, that's interesting. That sounds useful in XYZ case, right? So like once it's been explained to you now you can understand why that would be useful and you can tell them why you think it would be useful which does show, you know, a deeper understanding that you have a programming and then of course clarification questions. So let's take a look at another example. So the interviewer says, let's say you're designing a CRUD API to manage users and their photos. How would you design the endpoints? So you take a few seconds of applause and that's another point that's useful. Like don't be scared of a little bit of silence in your interviews. Take a second. Think about stuff and you just ask a follow-up question. Are users allowed to share the photos, right? Because that actually informs quite a bit how you would design like the data model, right? Whether a user has their photos or whether multiple users can have access to those same photos. So the interviewer of course says, good question. Let's assume that users can share the photos, but there's one primary owner of each photo, right? Just the fact that you asked this question is a win for you. Like you already look a little bit better in the interviewer's eyes. Okay, and then you can give a specific answer like, okay, well then I should probably have a slash users endpoints get information about specific users. And I would have a slash users slash ID slash photos endpoint to get all of the photos associated with each user. Would that work for our use case, right? And then of course, rather than just asserting the answer, you can say, would that work? It's just like a softer landing for your answer that I found helps a little bit. Let's talk about preparing for each individual interview. So we talked about how if you apply to a hundred jobs, you might land just a handful of interviews. And what that means is when you do get an interview, you should take it fairly seriously, because in order to get another one, you know, you probably have to apply to 20 or 30 places. So when you do get an interview, you want to kind of treat it with respect to deserves. That doesn't mean again, that like the pressure is on and that you shouldn't relax. You definitely should. In the interview, you should should kind of relax and try not to take it too seriously. But before the interview, you should take it very seriously and try to do some preparation, because just even just a little preparation, even just like an hour or two before the interview can have massive impact on your ability to land the job. So a couple of the things that I talk about are that the first things you're going to want to do is a little bit of research on the company. When you show up to the interview, you want to know what the company does, right? What they sell, right? They sell a software product. Do they sell programming services? Like how do they make their money? What's the thing that the team does? Just high level. This only takes like 15 minutes, right? You go to their home page, read their about page. This isn't a big deal, but it means a lot going into the company that you already know what they do. It shows that you actually care about this position. The next thing is you're going to want to know the names of all of the programming languages and frameworks and tools that are listed in the job description. So this is a really simple idea. The job description probably has like 15 technologies listed, right? We use JavaScript, we use TypeScript, we use Vue, we use Mongo, whatever. You don't have to master all of those, but you have to know what they are, or you should know what they are because it just takes half an hour of research to figure out what each one is. On that note, I'm going to cut to the primogen who I had on my podcast. And actually, this clip is not from the podcast. He was on my podcast, but this is unrelated. But this clip is where he talks about this preparation process and what he thinks you should be doing to maximize your chances in the interview. If I were or were not to get it. The reason being is that interviewing is a skill in of itself and it takes practice. So I would actually interview for practice if I get a bunch of jobs. Awesome. I can use those to negotiate with each other. My beautiful. And if I get none of them, I'm not heartbroken. I take the feedback. I figure out what I wasn't good at, how I didn't communicate well, and where the mismatch happened with the employer and improve on those things. Second, I would always be very careful about the jobs you're applying for and look at all the requirements. They want when you see all those use it as a cheat sheet to at least be able to intelligently speak about those. Now, you don't have to master those often. Those things are just wish lists. They're not requirements. And so that would kind of be how I would approach getting a job. Now, I love Rust. I think it's way, way more fun to program than TypeScript. But the reality is that if I were starting over, I would start where you get hired first. And then the moment you get hired, use that use that money. Use that income as just a way to be able to be stable and learn then what you want to learn. If you feel really passionate about compilers, it's really hard to get a job doing compilers, but you could get a job that will supplement you while you study, study, study, make blog posts, do all those things so you can move into that position. It's all about the long game and really it's all about making yourself better. And here's the fun part is you're going to take a job. You think I won't really like it. You might find you actually like something completely different than you thought. I'm 36 years old and I still keep discovering things. I didn't realize I liked to do just one more thing. I want to add on top of what Prime said there was that when I say surface level research on all of the stuff in a job posting, I really mean surface level. Like when you see Postgres listed there, just knowing that it is a SQL database, like that's basically all you need to know. And if you don't know what SQL is like, oh, it's a domain specific programming language for querying data out of a database, right? Like just very surface level things to get you to get you to a point where when someone mentions that term, so when someone says Postgres in the interview, you don't have a complete deer in the headlights look. That's all we're looking for really. Now, if you do have some extra time, like let's say you've got five days until the interview, you've got no other interviews lined up. I think it can be worth your time to build little projects with some of the technologies that seem more important to the interview and that actually can look really good in the interview. So let's say for example, that a company uses RabbitMQ for their back end, like asynchronous PubSub communications. So you saw that on the job posting, you've built a lot of back end services in different projects as you've been learning, but you've never used RabbitMQ before. So you do your little surface level research, you figure out what RabbitMQ is and you just spin it up locally. You spin it up locally, you build a few little command line tools or a little web app that uses it. Now, when you walk into the interview, not only do you know what it is, but you can say, oh yeah, it was really interesting to me when I was looking at this job, at the job posting, I didn't know what it was, actually spun it up, built a little project with it. Now, you can fairly confidently say that you have experience with Rabbit, but it also just shows that you have a lot of kind of go get it attitude, right? Like you were willing and interested in using one of these technologies that you'd never used before just to prepare for an interview, right? It shows a lot of good soft qualities. Welcome to the final chapter of this course. It's time to talk about relocation. So relocation is a funny subject. The world's changed a lot in the last five years. When I started getting into programming a decade ago, I was under no impression that it was even possible for me to get a remote job. And that's only 10 years ago, right? Today, it seems like everyone that's learning to code is under the impression that their entire career, they'll be working from their own house. Now, that can certainly happen. Most jobs at tech companies can be done remotely, and there certainly are a ton of remote companies. And in 2020 and 2021, where practically every tech company went fully remote, it was obviously possible. A lot of companies have gone back to on-site or hybrid, and a lot of new companies now in 2023 or going into 2024 are moving back to the office. So I don't think we're going back to nearly as on-site as the world was a decade ago, but we're also not as remote as the world was in 2020 and 2021. And here's my hot take. I think if you're looking for an entry-level position, your best bet is to go on-site. And that's really for two reasons. The first is that I believe for most entry-level developers, you will learn more and improve faster in your first couple of years at that company if you're on-site. So that's number one, it's just better for your long-term career. I also think that it is generally easier to find an on-site, in-person job than it is to find a remote job again as an entry-level developer. This all changes once you're a senior, right? And this all is kind of, the waters are muddied by influencers like myself, right? We all work from home, it seems. But that's not really reflective of the industry and especially not the entry-level industry. So first, let's dive into exactly why it's easier to get a job on-site. Let's start with a circle. This is the world. Sometimes it's tempting to think, well, let me start with some, we'll do some continents here. This will be the Americas, then over here we'll draw Europe, maybe Africa, we'll assume that Asia is on the other side of the planet. This is like really, really beautiful diagramming. Okay, cool. Here's the world. The assumption that a lot of entry-level developers make or new developers, especially after learning that programming can be done remotely, is the assumption that it's going to be easier to get a remote job because you can apply to jobs across all of these continents, right? Across the whole world, right? So for example, let's say that in the world, there are maybe, I don't know, let's just pick a number, 100,000 jobs that you can qualify for with your skill set. So for example, if you're looking for back-end development jobs in Go, let's just say there's 100,000 jobs in the world. Wow, that's not how we do 100,000. There we go. Okay. Where you live, let's say that you live, I don't know, here. Let's say that where you live, your city, there's only, I don't know, 200 jobs. All right, much fewer. So a lot of people will look at that statistic and say, okay, I should focus on remote jobs because there's 100,000 openings for remote jobs and there's only 200 jobs in my city, right? So just simple math, I should be applying for remote positions. Here's why this is tricky and why you shouldn't think about it this way. What that also means is that in the world, or I should say for each of those 100,000 jobs that's open to everyone in the world, there might be a million candidates and it is, right? Which means that those jobs have many applicants. Maybe each job is getting a thousand applicants, right? Anytime a company opens up a remote position these days, it's just flooded with applications, right? Okay, so say a million candidates and then in your city, the interesting thing is that in my experience, the ratio is actually better. So maybe in your city, there's only 200 candidates. Now again, I'm just making up numbers here, but the idea that I want to demonstrate is that in my experience, the number of people applying to any individual local job, so a job in your city that is not open to remote work, is going to have a lower ratio or a lower number of candidates applying for that individual job, right? So if I open a local job here in American Fork, Utah, I get 20 candidates, right? If I open it to the world, make it remote, put it up on LinkedIn, I get a thousand candidates, right? So hopefully this math is making sense, right? 100,000 total jobs in the world, 1 million candidates, 200 jobs in your city, 200 candidates. The idea is that you actually will have better luck with the 200 jobs in your city, right? It doesn't help you if there are 100,000 total jobs to apply for because in no world are you going to have enough time to actually apply to all 100,000 of those jobs. Now, if you happen to live in a city where there's very few programming jobs, it is like possible that you apply to every job in your city, you get rejected and now it's time for you to look remote. I just want to point out that if you are physically able to work in the office in your city, I would start there because I think you're actually going to have better luck. The odds are more in your favor. So let's take a few notes. The first is, we talked about this, but if you can work in an office, that's what I recommend. So prefer working in office for your first job. I think it's going to make it easier to land the job and I think you'll learn more while you're there, which is great when you're just starting out. Once you have a little more experience, I think it's fantastic if you go remote, like no problem at all. And then I do just want to caveat, if you have something in your life that makes working in office extremely difficult for you, right? If you have a kid at home, for example, or if you have some sort of health issue that makes it like really tough, I'm not saying that this is the only way, right? I'm just saying if it's an option that's available to you, I think it can make it easier for you. Okay, the next point I want to make is that, well, what should I do? Make this a question. What should I do if there are no jobs near me, right? You live in some like podunk town, not in San Francisco, not in New York, right? Like what are your options? So I have a little bit of insight here. I grew up in a town called St. George, Utah. It's in Southern Utah. It's about an hour and a half outside of Las Vegas. It is not known for technology companies, especially when I was there a decade ago. There was really like a handful, like two or three companies that did software development that I was aware of while I was living there. And that was it, like that was it. If you didn't work at one of those three companies, congratulations, like you're not working in tech. But little but notes to me until I actually did a bunch of research, there were some other opportunities at non-tech companies, right? So these three companies that like hired programmers, like one of them made a mobile app, right? So obviously hiring developers. One of them did a bunch of custom development with WordPress. So they'd take a WordPress site and they'd write a bunch of like custom PHP and they'd bill by the hour to do it. Another one of the software companies that's much larger now, but it was a SaaS company. They basically wrote cloud-based software that manages printers in offices. It was smaller than, it's much larger now. There's really only these few options. I did some digging, I did some legwork and I found a job listing. I can't even remember where. I know it wasn't on LinkedIn. It might have been on like Indeed or honestly even Craigslist, which is pretty sketchy, but that might have been where I found it. For a programming position, in fact a part-time programming position at a hardware company. They worked on, they put sensors on bridges, right? They had this little product where they'd throw up sensors on bridges, they'd collect data and their whole thing was like it was risk mitigation, right? They were trying to figure out if there were any problems with the bridges and they didn't even have a software product at the time. They just really needed some of the like write scripts and wrangle data, right? Run stuff against their SQL database, figure out what's going on with the data, parse it into JSON, hand it to the electrical engineer, just like little odd jobs. You kind of need to be a developer in order to be able to do efficiently. My point being like, are you sure? Are you sure there's no jobs near you? Even if they're weird. I worked at that company for a little over a year and like by industry standards, I was not paid well. I think at the time I was making like $15 an hour. I was just finishing my CS degree, but it was one of the best things that I could have done, right, because directly after that with one year of experience under my belt, I went and worked at a sexy SaaS company making a lot more money as a back-end developer. All I would say is, are you sure? Are you sure there's no like weird jobs at non sexy tech companies in your local area where you can get some programming experience under your belt while you're still in your kind of entry-level junior phase? Okay, so once you've looked in your local area, you feel like you've really spent some time and you're convinced that there just is not opportunity here. You basically have two options, right? You can either go remote or you can look to relocate. So going remote in my mind is like your last resort. If there's no other options, then go remote. It is certainly possible to get remote work. I don't want anyone to claim that I'm saying that it's impossible to find remote work as an entry-level developer. You can, I'm just saying it's kind of hard mode. So I'd save that for last. What I would do next is look into relocation and if that like works for you. So let me clear off the board and there's really two ways to think about relocating. So let's just talk about relocation for a second. The two ways to handle relocation are one, relocate. Then search for jobs. The other one obviously is to search for jobs remotely. The open relocation. Now of these two options, obviously option two is less risk, right? And so with everything I say in this chapter, I'm really just trying to help you understand some of the pros and the cons of different decisions you can make. I don't want to prescribe what you should do in your life. So with that in mind, option number two is going to be lower risk, right? It's really easy to look for jobs remotely. You can go to Indeed or LinkedIn or whatever and you can search by jobs in San Francisco, even if you don't live in San Francisco and you can apply to those jobs, right? And when you talk to the recruiter or the hiring manager, you can just say, oh, I'm not in San Francisco right now, but I'm excited about moving as soon as I get an offer in hand, right? And you can do this. You can do this right now. There's nothing stopping you. I will say it's a little harder. That's the price you pay for being risk averse, just in the sense that as a hiring manager, if you have two candidates that are roughly, you're kind of equally excited about both of them and one of them lives in town already and you can just go meet them for coffee. And if you hire them and then fire them two months later for whatever reason, because it didn't work out, like they didn't have to relocate and go into a bunch of debt or whatever, it's just easier for the hiring manager to work with someone that's already local. As opposed to, you know, they can't meet you for coffee if you live halfway across the country or halfway across the world. And obviously like H1B visas and everything come into play. I'm not even gonna speak to that because I know nothing about how that works because I've always worked in the US, lived in the US. If you wanna, you know, advise about that, you'll probably have to go to someone else. But just understand that if you take option two, it is definitely lower risk, but the price of that is it's going to be a little harder than if you were actually in the city. Okay, so option one, of course, is to just move. If you're not in a great place for jobs, just go somewhere where the job market is better and then look for work, right? And of course that will make it easier. You have to figure out what works for you in your life. My gut tells me, well, let me just give you my experience because again, I don't want to prescribe advice here. When I graduated college, I was married but with no kids. And my wife was an X-ray technician, so we could really live anywhere. So it wasn't a problem. So like I could just move from St. George up to Salt Lake, which is what I did, and apply for jobs there. There's a lot more jobs in Salt Lake, like a lot more. And it was fairly low risk. The cost of living in Salt Lake versus St. George is like marginally higher, and we were just renting. So like it really just wasn't that hard to, it just wasn't that hard to pick up our lives and move. My wife was able to find a job up here in Salt Lake quite easily as an X-ray tech. Contrast that with someone, right? Or rather contrast that with me right now in my life where I'm married with two children and we own a home. Relocating would be a huge deal for me right now. So to be honest, if I was learning to code right now where I'm at in my life, I would probably take option two. Even though I'm probably going to have to do more interviews, it's going to be more legwork before I get an interview, the risk of moving and not finding a job, moving to a new city with no salary, shopping for a new house, it's just not worth it to me right now. So if you are single, right? If you have the funds, then option one might be the better option. But if you have a lot of things tying you down to a location, then obviously number two could be what you're looking for. But I want to point out that if you're even open to the idea of relocation, option number two is going to be a lot easier than, let's go back to talking about remote, option number three, which is to only apply, only apply to fully remote positions, right? I would really only do option number three if I had some reason in my life, some thing in my life that was making it so that remote was realistically the only possibility for me. The very last thing I want to leave with you with in this course is go back to the very beginning where I drew this graph, right? I drew this graph and I said, along the X-axis on the bottom, we've got time. And along the Y-axis, we've got kind of likelihood, doing weird things with my arrow, likelihood of getting a job, right? And as time goes on, you really want to have a graph that looks like this instead of a graph, like so many students have that kind of looks like this as they're learning and then actually tapers off as they start their job search or in the worst case actually goes back down. And I know at the beginning of the course, I was emphasizing continuing to learn and build and that is accurate. You do want to do that. That can help kind of fix the shape of this graph, but there is one other thing and that is to be extremely, extremely, I'm not gonna try to spell extreme without spell check, be very critical and reflective of your process. Critical and reflective of your process, right? So tying this into relocation would be, I've seen a lot of students who make quick assumptions and have jumped the gun on what they think is the problem in their job search, right? So they start their job search, they're looking for their first job in tech, not an easy thing as we've gone over and they assume, oh, I don't have, I'm not a graduate. I don't have a bootcamp graduate certificate. I don't have a CS degree. That's definitely the problem. I'm gonna go take out a bunch of loans and go back to school or I'm gonna go do a bootcamp. I'm not gonna say those things can't help, they can, but was that the problem? If you already are confident in your coding abilities, was that the problem? Are we sure it wasn't that your LinkedIn and GitHub profiles are terrible? Are we sure it's not that your projects are really boring and nobody cares about them? Are we sure it's not that you fail every whiteboarding test or whiteboarding interview that you've ever done? You kinda wanna be sure of those things before you do a really high risk thing. Going back to school in your 30s or doing an expensive bootcamp in your 30s, those things are fairly high risk. Again, not that they can't work, but if it were me, I would want to be sure that that's the thing I lack before I take one of those larger risks and relocation falls into the same category for me. If you're having a really hard time in your local area finding work and you believe that relocation is the answer, it could be, I would just encourage you to check all the other boxes, right? Review the other chapters in the course. Is your LinkedIn great? Is your GitHub great? Are your projects awesome? Is it really just the location? And if it is, then look into solving your problem that way. But if it's not, maybe fix the lower hanging fruit first. Now, I just wanna reiterate that this is not a course on math, right? The things that I've shared in this course have primarily just been anecdotes and stories and things that I believe will help you in your job search. There is no correct answer for what's the best way to get a programming job, right? All there are are opinions and stories and experiences from people who have done it. And that's what I'm trying to synthesize and share with you here. I hope you found this valuable. Try your best to adjust all the things that we've talked about in this course to your life and apply them to your situation because your situation is different than mine. Again, if you want the text version of this course, it is fully free on boot.dev. Paid memberships on boot.dev are only required for all of the interactive features like the gamification, the progress tracking. If you just want to read and watch all of the content, that is fully free, so you can go check that out. Best of luck on your job search.

Channel: freeCodeCamp.org

Views: 2,401,550

Keywords:

Id: 6nz8GXjxiHg

Length: 239min 45sec (14385 seconds)

Published: Thu Jan 18 2024