298. How to Transition from Tutorials To Getting Hired

Watching tutorials isn't enough to get you a job. Most jobs want work experience. But you need a job to get that work experience. So how do you transition from watching a tutorial to getting hired for those skills? Whether this is your first job or your next job, what are the steps you need to take? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Just watching tutorials won't get you hired. In fact, watching too many tutorials will probably reduce your odds of getting hired. So, how do you take the leap from learning something to being hired to do that thing? Whether you're looking for your first job or looking to get a better job, there's an art to adding new skills and then getting employers to acknowledge those new skills. Let's talk about it in today's episode of DevQutions.

SPEAKER_00 0:34

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:38

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about transitioning from watching tutorials to getting hired. As you probably know, my full-time job is teaching software development. I release about 100 videos per year on YouTube, plus about six new courses. So I think that it's even more important that you hear this from me. Watching videos does not make you a developer. I can do my part by creating the videos, but you have to do your part as well. If we both do our parts, you can absolutely become a great developer or take your development career to the next level. But it takes work. So let's talk about the work that you need to put in. Number one, follow along with while you watch. So when I give you a tutorial on a new technique that you're wanting to learn, don't just passively watch. Me the first time if you're going to watch it multiple times. I'm not encouraged, you don't have to watch multiple times. But if you're going to watch it just once, then follow along while you're watching the first time. If you're going to watch it more than once, you get to choose. But follow along. Do what I do. Try to recreate what I do. I provide the source code for a lot of my videos in the description, but that's more for, hey, you got stuck, or hey, I had a starting point that was not just file new project. And so you want to start from something else. I would encourage you, don't just download the source code and go, yep, that works, because that's not the value for your time. That's not what's going to give you enough learning experience. Follow along, redo it, type what I type, see how it works in the code, see it work. And then number two, practice what you've just learned. If you wanted to get better at, let's say, lifting weights, you could watch a YouTube video about how to lift weights the right way, making sure that your form is correct, and making sure that you're lifting the right amount for your level currently. But watching those videos isn't going to actually help you put on muscle. What you need to do is start lifting the weights. So why is it that that's obvious when it comes to working out, but yet it's not obvious when it comes to software development? When you watch a video, you're watching me show you how to lift the weights, how to do it right, how to have best practices while you do it. But now you have to lift those same weights. You have to not just type exactly what I typed, but do things a little bit different. Try things out, practice things so that you get that muscle memory. You get those muscles from doing the projects yourself, from practicing small little practice projects, nothing big, nothing real, but just something tiny to show off what you've learned. Do that a few times to get those repetitions in, to get that comfort level to say, yes, I can do this. Then number three, incorporate this new thing into existing code. So this is where having a portfolio is really helpful because you can take an existing project you already have and say, hey, this would benefit from this asynchronous way of doing things or this new way of doing dependency injection. Let's integrate that into the current code and redo it. So you're not doing a whole project, but you're integrating it into an existing project, making that project better and giving yourself something to point to when an employer asks, Hey, have you ever done this before? You can say, Yeah, right there. So integrate it into existing code. Number four, document what you've learned. This is where you can say, hey, I'm making progress. You can also show it off to your current employer and say, these are the things I'm learning, and show it off to a potential employer saying, This is my most recent six months worth of learning and the things I've done. So when I say document what you've learned, this is not a comprehensive thing. You could make it comprehensive if you wanted to, but I really see this as I learned about dependency injection in.NET 10. And then have a small paragraph that talks about the things that you've learned to do in dependency injection. And then your next thing, I learned about logging in.NET 10, and have a small paragraph about the things you learn about logging in.NET 10. Maybe even if you wanted to, link to your portfolio item that uses that. But this way you have a list you can hand to someone, say, this is the progress I'm making. Put dates on it. Say, this is what I learned in March, this is what I learned in April, this is what I learned in May. That way they can see progress. They can see that you're growing and changing over time. Number five, if you have a job right now, try to use a new feature at work. So learn something, hopefully it's relevant to your work or close to relevant, adjacent, and try to use it at work. Maybe you're learning something that's totally different than what you're doing at work, but maybe you could do that in a side project at work. Figure out some way to incorporate into your current job because now, if you do that, now you put in your resume as something you've done at that job, while at the same time you can show off your current boss and say, hey, I'm learning and growing, and this is how I am improving. Help your current employer, help your current project, and help yourself on your resume. Now, if you don't have a current job, put it into a real app. So maybe an open source project that you do. Maybe it's a project that you're trying to build something out to either sell or to give away that solves some kind of problem. Put it into a real app. This is maybe bigger than a portfolio item, maybe it's a portfolio item that's also useful. That can be great as well. But either way, integrate this into a real project. Number six, and this is something that maybe get enthusiastic about at first, but you need to be consistent about, and that is blog about it. Now you might say, Tim, no one's gonna read my stuff. That's okay. That's not the point. The point about blogging is not about everybody else, it's about you. By putting it into written form, you have to explain how it works. You have to basically document what you have learned in more detail. You have to figure out how to identify exactly the pieces that go into place. It does not have to be perfect, does not have to be pretty, does not have to be something that anybody else reads. But blog about it. That way you have something, again, to point employers to to say, hey, here's the progress I'm making and here's what I've learned. But it also kind of, for whatever reason, people look at a blog and think of it as an elevation above just a normal person. I don't know why, but they do. Which means it can set you apart, saying, these are the things I've learned, and show off that blog, especially if it's consistent. If you have the, I'm gonna blog about things and then have three blogs in three days and then nothing, maybe you don't show that off. But if you are consistently putting blog posts once a month, it doesn't have, it doesn't matter. But being consistent about that and being consistent about learning new things, documenting them and clarifying what you've learned, then first of all, you're going to learn that topic better because you have to clarify it by putting it into writing. Uh, oftentimes our brains kind of skip over steps and go, one, two, four, five, got it. And you're like, wait, wait, where's where's three? When you write it down, you go, wait, I'm missing three here somewhere. And then you go, oh, I have to figure out what three is. And so by doing this, you are solidifying what you've learned. You're making sure you're not skipping steps, you're reinforcing the topic, you're giving yourself a thing to look back at later where you go, oh, that's how I do things. Because you will forget. And you're showing off both the world, but more specifically to future employers. This is what I can do. So really valuable. And then number seven, update your resume. Make sure that your keywords match. Again, resumes we customized per job. I've said a numerous times in the past, but this goes in your master resume where you then pair it down to the current job and the keywords that that job is looking for. But by having these new things, you can have more keywords to pare down to where you can say, yeah, they're looking for dependency ejection. Yep, I've got that. And add that to your specific resume, your customized resume. But also you can point back to, and I used it at this job because you've integrated it into your current code. Or I've integrated it in this application, and you can point to that portfolio item. So you're not just watching tutorials anymore and going, yeah, I got that, and trying to add it to your resume. That's skipping from step one to step seven. Instead, go through all of these steps, build those skills, integrate those skills, document those skills, show off those skills, and then show them off in your resume and portfolio and tell employers. So there's multiple steps along the way. If you skip over what's going to happen is you're just not going to get interest from people. Employers are asking for work experience for a reason. The purpose behind asking for work experience or years of work experience is to get someone who can do the job well, who has done more than just gone through a tutorial. Show off what you can do in your projects, in your blog posts, and other things. Prove your ability through those portfolio items, through the blog entries, through putting out saying, hey, I did this at this job. And then use your years of work experience and software development in general, coupled with your proven abilities in those new areas to put yourself ahead of your peers. It takes more than just watching tutorials. It takes putting in the effort to do the hard work that gets you to elevate from just watching to actually being paid to do that thing. Thanks for listening. As always, I am Tim Corey.

SPEAKER_00 11:32

Thank you for joining us for this episode of DevQuestions. When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.