all right let's talk about why your personal projects aren't getting you hired now you 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 boot camp self-taught people and uh 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 um 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 um 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 that's the problem right there right it's not focused it's not targeted uh a good targeted approach is to apply for companies where you're building [ __ ] 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 as 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 expose or to essentially use what you're learning in a different context to help reinforce that concept
a little bit deeper 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 build a bunch of shitty projects first we 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 web- 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 it's easy to start new green projects it 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 in 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 when you have a dozen
projects none of which are complete that signals that maybe you let impostor syndrome overwhelm you you give up too easily you have commitment issues you can't follow through you're just chasing those dopamine hits like it could be any of the above or even other things right don't give that signal finish your [ __ ] but more importantly I think a lot of people why I would say some people a 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 a 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 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 now I think it's okay to 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 your true purpose of having all of these unfinished projects it's probably the former 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 that's 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 um 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 people that are just tinkering to code build products all the time they might not call it a product but you know they 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 um especially if there's not a lot of complexity to it and it's not like serving a lot of people but you can 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 you might have heard of some coding boot camps that hyperfocus on like a One Singular cap Stone project that they spend months on and they they polish it up it looks like a professional product because you're 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 you
know 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 friend positions in fact you should question if you should dive into the back end at all but documentation is something that will also make your product your 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 I got to stress this again 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 [ __ ] what the hell do you 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 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 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 it's just going to end up as a graveyard project that's how a lot of graveyard projects uh become graveyard projects is because you didn't really have enough interest in the first place right to follow through with it 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 chbt or another AI model to help you brainstorm some ideas but give it as much context as Pro uh possible about like what you've been learning what you want to be challenged with um what sound sounds interesting maybe a fun project you built in the past could it be related to that what did you like about it 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 um but eventually with that Capstone project I went you to start thinking about it like a real professional product cuz 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' 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 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 this social proof that then you're showing employers that hey I can build [ __ ] 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 but taking that initiative to try to get your app in front of other people um you know whether maybe it's product huntt 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 employer eyes than all these other random personal projects that serve no purpose so you can also um well yeah I I think I'm going to leave it with that I 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 Pro project that final project that is useful that provides real value to people gains a user base where it looks professional it 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 the scrum process you write tickets of
features and bugs you got to fix and then it you just launch you know new fixes very quickly and push it out and get more feedback and this is a cycle so now you've involved yourself in a a 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 two day 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 what would that product be