DonTheDeveloper Podcast
DonTheDeveloper Podcast
Why Your Personal Projects Aren't Getting You Hired
Are your personal projects failing to get you hired? In this video, I break down the common mistakes aspiring developers make with their projects and why they aren't standing out to employers. Many think that just building a variety of projects is enough, but the scattershot approach often misses the mark. I’ll guide you through a more strategic way to approach personal projects that will resonate with hiring managers.
We’ll dive into the importance of targeting your projects towards the industry you care about, building meaningful and professional-looking projects, and understanding the Minimum Viable Product (MVP) concept to know when a project is truly "done." I'll also discuss how unfinished projects on your GitHub can send the wrong signals about your commitment and consistency.
Throughout the video, I encourage you to think beyond just coding for the sake of it. You need to create something that solves real problems, adds value, and even gains users. I'll share tips on showcasing your projects effectively to signal your potential as a valuable developer who can contribute real results.
If you're tired of your personal projects feeling like wasted efforts, watch this video to learn how to build projects that actually catch the eye of employers. Don't just build—build with purpose, build with strategy, and start turning your ideas into assets that move your career forward.
---------------------------------------------------
🔥 Webdev Career Help - https://calendly.com/donthedeveloper/coaching
🎮 Join Discord - https://discord.gg/TpQe2k8Ab3
❤️ Support What I Do - https://www.patreon.com/donthedeveloper
Disclaimer: Some product links are affiliate links which means if you buy something I'll receive a small commission at no extra cost to you.
===========================
WEBDEV COURSES I HIGHLY RECOMMEND:
🎓 Learn Frontend - Scrimba (20% off): https://scrimba.com/the-frontend-developer-career-path-c0j?via=donthedeveloper
🎓 Learn Backend - Boot.dev (25% off): https://boot.dev/?promo=DONTHEDEVELOPER - Get 25% off your first payment with code "DONTHEDEVELOPER"
🎓 Already Experienced? Level Up Here - Code Crafters (40% off): https://app.codecrafters.io/join?via=donthedeveloper
All right, let's talk about why your personal projects aren't getting you hired. I hear this all the time. You got to build personal projects to show your experience, to be marketable to employers when you don't have experience. This is all true, right? I think people just do it the wrong way, and you know, understandably, because there's a lot of advice on personal projects. There's a lot of different types of personal projects that you see come out of CS degrees, coding bootcamp, self-taught people and different courses and, like you know, should you build or include your tutorial based projects in your courses? What about that mini project you built to get a little bit more comfortable with JavaScript? Should it include a framework? Like, it's really hard to know. And you know why it's so difficult, because I think people have this misconception that, quite frankly, that you even need a personal portfolio to showcase your projects in this traditional sense, right, a lot of people think they need, like, a variety of projects to apply to a variety of companies and maybe one of those projects will stand out to one of those companies and you're kind of just throwing spaghetti at the wall and that's the problem, right there, right, it's not, not focused, it's not targeted. A good, targeted approach is to apply for companies where you're building shit that they're building right, um, at a more basic level. But you care about the industry, you, you want to work there and you're probably going to fit into the culture because, like you, you just care about the problems that they're solving. You care about the users that are going to use that product and I I think this whole spitfire approach of just you know, building is a variety and as much as you possibly can to see if one thing sticks is what's hurting you, right. So I want to encourage a more targeted approach, um, but a lot of people will build a variety of projects and for a second I'm going to contradict what I just said and you should. You should build that variety of projects to reinforce what you're learning, to get exposed or to essentially use what you're learning in a different context to help reinforce that concept a little bit deeper.
Don Hansen:You should build a bunch of crappy stuff Initially. You shouldn't be focused on this capstone project. I'm going to build this. You know, over the next six months I'm going to build this really impressive project. Why that's putting a lot of pressure on yourself and a lot of people that do this end up just overwhelming themselves with that project.
Don Hansen:Build a bunch of shitty projects first. You don't have to show these employers these shitty projects, but a lot of us, a lot of people that have made it into the dev industry we built a lot of really bad stuff initially. Now we built a little better stuff, a little bit of better stuff, and then better stuff, and then better stuff and then better stuff over time and we were able to build more complex projects and then finally, we might have a project that, like, really speaks to us. Like this would be a really cool tool to build for developers. Or if I had this-based software in my old industry, like it would have made my job way easier. What if I could, like, just try to build the basic version of this, put some pricing on it, make it look professional and try to sell it to some people like that is a phenomenal personal project to list on your resume and you are capable of that. You are. It's going to take more time than a lot of your crappy projects, and the problem is that when people tackle stuff like this, they give up. They don't come back to the project.
Don Hansen:It's easy to start new green projects. It's good, it just feels good to get that dopamine hit, to not struggle and just like, get into a little bit of a state of flow. And you got to struggle, man, you got to struggle. One thing that hurts a lot of new developers is you look on their GitHub and they just have a graveyard of unfinished projects. What do you think that tells employers? Like, if I'm reading into it, that tells me that you don't really have much commitment. You don't really know what kind of problems you want to solve. It's okay for a project to be small and done, but the problem is that signals that maybe you let imposter syndrome overwhelm you, you give up too easily, you have commitment issues, you can't follow through, you're just chasing those dopamine hits. It could be any of the above or even other things. Don't give that signal. Finish your shit.
Don Hansen:But more importantly, I think a lot of people I would say some people, portion of those people that don't finish their projects. They don't finish them because they don't know when done is done, and this is a skill that you need to build up as a new developer. It's what is the mvp minimum viable product? What is the base version of this thing that I'm trying to build without adding a bunch of bells and whistles. What is the base version of this? Let me go ahead and create a checklist of technical requirements and when I finish this checklist, this project is done and make it so you can build this project within a month, three weeks, two weeks, and then you could build on top of that. An MVP is just the initial launch of something right. It's just the initial usable thing of whatever you're trying to build. That solves this really simple problem. A lot of companies are built on this concept and then they build features on top of that. When they get feedback, because they gain a user or two, that gives them that feedback, because they gain a user or two, that gives them that feedback. So, if that helps, consider like coming up with a checklist of things that you should, uh, that you need to complete before you move on to the next project.
Don Hansen:Now I think it's okay to have a few like functions, random functions you build to test a certain concept, or just smaller projects where they're not that meaningful. You were just trying to understand a certain concept, that's. That's okay. I don't think you have to complete every single project, but you just want to be careful if your github is littered with a bunch of unfinished projects, you really have to be real with yourself. Are you creating a bad habit here or is there true purpose of having all of these unfinished projects? It's probably the former.
Don Hansen:Another thing is, like I talked about making your projects look professional, right, if you're building even a simple tool that all aspiring developers can build, eventually that is usable to someone, which you could build, a tool that's usable to you. Right, it does a little bit like if it's a fitness app. It does some things a little bit differently than your current fitness app, but you can build stuff for yourself and you are the initial user and that's a great product to build because you don't need to go out and do a bunch of user research. You know what you want and you could expand that into other users and see you know if they want things a little bit differently than you and how you can adapt your product and build more features to to help other developers and I keep using the word product and I feel like a lot of people get overwhelmed with this Like they can't build a product. Yes, you can.
Don Hansen:People that are just tinkering to code build products all the time they might not call it a product, but you know, they build a website for their church, they build a tool for their guild in World of Warcraft. They build something that is useful to them. Now, is that going to be the most marketable personal project? Probably not, especially if there's not a lot of complexity to it and it's not serving a lot of people. But you have the capability of building a real product and you should start thinking of yourself as a product builder, as a developer, even without a dev job. Holding yourself to that standard with that main capstone project that you're eventually going to build, that makes you stand out to employers. You know, like that's where people stand out. It's.
Don Hansen:You might've heard of some coding bootcamps that hyper-focus on like a one singular capstone project that they spend months on and they they polish it up. It looks like a professional product because they're capable of it, just like you're capable of it. And they also will take time to create good documentation on how to boot this app up. Right, if another dev wanted to spin it up let's say, another dev on the team wanted to spin it up they should have clear instructions on how to do so. And if you are heavily focused on backend positions. There's just niche, niche things that you can do, like having whether it's like a self documented situation or you got to build, like manually build a documentation for your API, like having documentation for your API for backend developers is really powerful. I don't think you have to go to that extent if you are applying for frontend positions. In fact, you should question if you should dive into the backend at all. But documentation is something that will also make your product, your professional looking project, feel more professional, and that's what it's about. It's making it feel more professional to employers. And so I got to stress this again.
Don Hansen:Like a big thing is and I hate this question it's when people ask others what they should build. You got into coding for a reason. Don't tell me you don't want to build cool shit. What the hell do you want to build? If you look at other apps like what would even sound cool to work on and build, you can get ideas from other people for inspiration, but you should not be asking people to tell you what you need to build. You need to find that within yourself. What kind of problems do you need to build? You need to find that within yourself. What kind of problems do you want to solve as a developer? And this a lot of people are uncomfortable with this because they haven't trained their mind to think about this.
Don Hansen:You can brainstorm. There are YouTube videos that will help you form a brainstorming process if you feel like you need a system in place to do that. But a lot of times it's just like you know, if I could build something for myself, what would it be? Let's start with that. Start with something right. But I don't think you should just be building a random thing because someone else told you to build it. A lot of times it's just going to end up as a graveyard project. That's how a lot of graveyard projects become graveyard projects is because you didn't really have enough interest in the first place. Right to follow through with that.
Don Hansen:And so focus on, like, what you can build. Start with yourself, but what you can build for your friends, your family, your gaming community, your local community, your previous industry. And if you struggle with brainstorming, like, use chat, gbt or another AI model to help you brainstorm some ideas, but give it as much context as possible about, like, what you've been learning, what you want to be challenged with, what sounds interesting, maybe a fun project you've built in the past got to be related to that. What did you like about it? Right Was right. Was it gamified? Include that in the context you provide to ai. Right. So that's how you can really utilize ai to basically be like a second brain that just makes yours better and it helps propel you in the right direction by giving a lot of great context that is very unique to you.
Don Hansen:But eventually, with that capstone project, I want you to start thinking about it like a real professional product, because I've seen this type of personal project make so many aspiring developers stand out and the final thing would be like a failure to demonstrate, kind of like an improvement with efficiency or addressing user needs. Right, so you've built something that can help people. What have you done to put it out there in front of people? What have you done to gain a user base? Even having five people using your app actively is way better than so many of these other personal projects that serve no purpose. You'd be surprised how easy it is to stand out among many other aspiring developers when you build something that's useful and people are using it.
Don Hansen:You can list those user statistics. You can list revenue that you're getting. It doesn't have to be revenue, it could just be usage. Maybe build a mobile app and you list the downloads in the app store, right, but if people are using it, you're giving this. Well, you're getting the social proof that then you're showing employers that, hey, I can build shit that provides real value to people and if it provides real value to people, you can gain revenue off of it. You can monetize that. You might not be good at monetizing that, but it has the potential to. And now you're just signaling to employers that, hey, maybe this developer that we're hiring can build. You know that they know enough to be able to build something of real value for users and they could build real value for us and our users and gain us revenue. Right, you don't have to be an entire marketing department to know how to do this.
Don Hansen:But taking that initiative to try to get your app in front of other people um, you know, whether maybe it's product hunt or another website like that posting it on twitter, linkedin, saying and posting it and asking mods first, but posting it in subreddits of different communities of where this app would actually be useful, um, you got to take that initiative. But if you can gain or if you can mark down certain statistics like usage for your app, that I'm telling you that personal project gets bumped way higher and it's way more competitive in employers' eyes than all these other random personal projects that serve no purpose. So you can also well. Yeah, I think I'm going to leave it with that.
Don Hansen:I think the big message that I'm trying to deliver right now is it's okay to start with a variety of projects. It's okay to build a bunch of crappy stuff, but eventually I want you to start focusing more on the model of building that capstone project, that final project that is useful, that provides real value to people, gains a user base where it looks professional, feels professional on the source control side you have a proper readme it feels professional on that end as well. You care about the code quality, because now you're scaling the app, because you're asking for user feedback. So you're going through the agile process of wanting to iterate on your app and you get user feedback and you adopt a scrum process. You write tickets of features and bugs you've got to fix and then you just launch you know new fixes very quickly and push it out and get more feedback, and this is a cycle.
Don Hansen:So now you've involved yourself in a professional process the agile and the scrum process right, professional process, the agile and the scrub process right, you're not going to do this the right way the first time. Right, and maybe what I've described to you sounds a bit advanced and overwhelming and you got to try it. And it starts with just building that one tool for yourself and expanding from there. If you're intimidated by everything else, what like today, if I could start a new project and finish it in a month and produce an mvp, and then I'll think about, like, pushing it out to other people, then if you could build one project today for one month and you have to launch it at the end of that month.