DonTheDeveloper Podcast
DonTheDeveloper Podcast
Least vs Most Marketable Projects for Junior Developers
One of the more difficult things junior developers seem to struggle with is knowing what portfolio projects to build to be marketable and competitive in the job search. I went over a variety of types of projects and how much they help you stand out among your competition.
Not only that, but I went over the pros and cons of each, misconceptions of what is common but ineffective advice given around these projects, and how to be effective at making the more marketable options even more impressive.
If you're wondering what types of projects to build for your portfolio to stand out, this one's for you.
Discover how technology is reshaping our lives and livelihoods.
Listen on: Apple Podcasts Spotify
---------------------------------------------------
🔥 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. So let's talk about what types of portfolio projects you should be building to stand out as an aspiring developer in 2025. Now I'm going to go over several low-value projects that I see on many portfolios, and I'm also going to go over high-value projects as well, as how many of you are screwing up those projects and turning them into lower value projects. So I'm going to be very blunt with this, but we're going to go into code along tutorial projects. Right, they hit, hold your hand a little bit. They kind of give you steps. Maybe you do a few steps, build something, you build a feature, you check it. Is it working? Cool? No, okay, I need to figure out what I did wrong. These are really useful projects in reinforcing your skills and getting you to apply these. Currently, what seem as arbitrary concepts. You're like how do I apply it? Okay, I'm learning this. I'm learning a loop. What do I do with it? How is it applied? So you're using these fundamental concepts in something practical. That's fantastic. High value learning project. Extremely low value portfolio project. You're not really showcasing what you can do, you're just learning. These are okay, and you can still have these on your GitHub, for sure, but these are not the ones that you're going to be highlighting. Okay, and you can still have these on your GitHub for sure, but these are not the ones that you're going to be highlighting Clone projects. So clone projects are a really effective tool at getting you to kind of shut off the part of your brain that requires you to come up like, think like a project manager a bit and like kind of a user, a developer who cares about user experience. You get to turn, turn that off. You don't have to think about the design, how things look or whatever like that. You just find a tool, you find a website, you find something and you just rebuild it and sometimes, especially like css, if you're trying to get better with HTML and CSS you can take a Photoshop document or a JPEG or whatever else that just shows a layout and then you code it with HTML and CSS. That's a really good way to reinforce your CSS skills.
Don Hansen:You don't own the rights to claim that you own that project. You don't own the rights to claim that you own that project. You don't own the rights to make that project public. You don't, unless it's like open source or something else that gives you a license to do that and it explicitly states that.
Don Hansen:But a lot of your clone projects should not be on your portfolio. Stop it. They don't belong there. You don't own them. They're really good for reinforcing your skills. You just do it locally, right. You rebuild it locally. It's good practice. It's really good practice, but none of those should be on your portfolio.
Don Hansen:That's crazy that some of you are putting like Spotify clones and stuff like that. They're not even high value projects. You're just what building? You're turning half like half your brain off to just be a code monkey and apply concepts, and which is good. When you're learning, you want to reinforce these concepts, but they look you're not really problem solving. You don't have to think about how you're going to separate these features and organize this stuff. A lot of this just based on it being created already and how you've used it and how you know how everything works Like a lot of this has been solved for you already. There are just certain parts of your brain that you're not activating. There are certain parts of being a developer that you're not really showcasing that you're strong in certain areas. You're just able to look at, essentially, design and replicate it. So it's really good at reinforcing concepts, but again, this is just tutorial project essentially. Look at it like that. It's high value with the learning, low value with the portfolio.
Don Hansen:And then the third one is open-ended projects. We don't know by now. I mean, I've kind of fought for both bootdev and scrimpa. Bootdev is really good at preparing backend developers, scrimpa is really good at preparing front end developers. They're an affiliate partner of mine and I still, to this day, tell people like these open ended projects, like scrimpa will give you an open ended project where they give you like high level requirements And're just like yeah, build this, here's the design I'm gonna be at this point. Low code solutions can do that. Ai can do that. Right, I don't think ai is that impressive, but I could do that um, like just kind of taking a design with some open-ended requirements and then just building it yourself. It does require you to break those higher level requirements down into more specific requirements, which is a skill in itself breaking kind of a big concept down into smaller concepts and making it more technical so that you essentially have like a guideline that you've created for yourself to be able to go through these steps and build this thing. It's really good at helping you break those concepts down, but, again, like you're not really showcasing what you want to build, the kind of problems you want to solve. This problem has already been solved for you. You're essentially just being still a code monkey and building what you're told to build without much thought into it.
Don Hansen:It's a really low-value portfolio project, but it's still a very high-value learning project. All these, you get this like. You get this. You always get this like advice that lacks nuance on places like Twitter and Reddit and LinkedIn and it just it lacks context. These projects are really good to build. They're not bad projects to build. They're just horrible portfolio projects. And if you are shoving these projects on your portfolio, you're essentially telling employers you don't really have anything impressive to show. It's just a self-report. It's a horrible idea, and so what needs to happen is you got to dive a little bit deeper. So we talked about some essential projects for your learning, low value portfolio projects.
Don Hansen:Now we're going to talk about hireable projects and we're going to start with open source contributions. So a lot of people do open source contributions the wrong way. Here's the wrong way. I've heard that I'm supposed to make open source contributions because it looks like professional experience and employers will now pay attention to me and pay attention to my portfolio, because now I'm working on professional projects. So I can tell you very confidently, if you are just using open source as a check mark and then moving on, you're just wasting everyone's time.
Don Hansen:If you want to get some exposure to a larger code base, that's what open source is really good for you can download the code base, play around with it, break stuff, discover how it works. In doing that, like that's essentially what you're doing when you get hired as a developer. You're going to download it locally, get it working, maybe solve a couple of bugs. I got to figure out, like, where in the code base is relevant to even look for these bugs. And as I dig deeper, I start learning more about the code base and how it works and how things are organized and the conventions right. Open source is really good for that.
Don Hansen:But if you are just making a couple of contributions to a popular open source project or something like that, you're probably going to start off with really minor stuff. You're not really doing any intensive problem solving, solving minor bugs who gives a shit? You're not really showcasing what you can do, not showcasing your depth of skill as a developer. Just because you can eventually navigate a code base to make a couple of minor contributions is worthless. Who cares Like every junior developer is eventually going to be able to do that? Who cares Like no one cares about that? If you are putting, if you are creating a public repo on GitHub and adding an open source license and calling that open source, you're just full of shit. People who actually care about open source projects know you're full of shit as well. It's going to have really no activity. Full of shit as well. It's gonna have really no activity. Um, and a lot of hiring managers at this point are very aware of like coding boot camps, encouraging some students in a very dishonest manner, um, to just like label their projects as open source and just star each other's repos. Like. Hiring managers are a lot more aware of stuff like this. You're just making up a project saying it's open source and you're a contributor. You're full of shit. You're going to get found out.
Don Hansen:A really good use case of open source for making yourself stand out to employers is spending three to six months diving deep into an open source project you believe in. Open source is about developers as they gain skills and get better, and they've been helped themselves. They now want to give back to the developers that are now walking their path. It's a beautiful thing about open source and there's more mission. There's more values and mission among open source developers. But in terms of what you probably will want to focus on, open source with it's, you want to get more comfortable with a larger code base, but it's about like contributing to a tool that you've used in the past. You like it, you like the community and you want to give back. That's a really, really powerful story to bring into an interview. Um, that speaks way more than just making a couple of minor contributions. Um, that's a story that's part of your story. That's part of your story. That's part of your learning and the why of why you decided to spend a lot of time in that.
Don Hansen:Open source software matters, and it can appeal to certain hiring managers and certain teams that care about what you're doing. Sometimes they'll care about the project you're working on. Sometimes they just love open source right, and you can just spark up a conversation and connect with someone on the team in the interview. Because of that right, you get excited, developers get excited, they talk to each other, you make friendships, you vibe your story can help you do that in the interview process. It can help you get noticed. So open source is really powerful when you take it seriously, when you respect the open source community and when you don't just use it as a checkmark for your own selfish needs. That's when it becomes valuable.
Don Hansen:Most aspiring developers are not going into depth with that. Now be careful. Are not going into depth with that Now be careful. I had someone come to my meetup about like seven years ago and she contributed to something with Mozilla for like three to six months and that belonged on her resume 100%. But she was still due and what she should have done was pair it with a personal project so she can kind of like really reinforce the technology she wants to reinforce and apply for and she could have like showcased to employers. I have depth of knowledge when I have control over this and I have ownership over what I can build. Here are my conventions, because you have to adhere to whatever the open source project has. But with my personal project, here are my conventions. Here's what I believe, here's how I would organize my code right and that tells the employer more about you. It's about painting that story and it's really hard to do that when you're contributing to others' projects.
Don Hansen:So, again, contributing to open source can be great as an aspiring developer if done in the right way, but it's not needed. It's another thing. There's no nuance and advice going around. It's like you don't have to contribute to open source. It's like if you want to, that's great. There are different paths to go down as a developer, and this is one where you could go heavily into open source contributions.
Don Hansen:Okay, so hackathon projects are fantastic. You got to use probably some source control, not step on each other's toes. You have a time limit. You have a group. Maybe you have a fun story of a developer that you just clashed with, but you still got it to the finish line. That's fantastic, right, and a lot of hackathon projects where they're hosted like larger hackathon projects, where they're hosted by companies. Maybe you're solving real problems. Maybe you get paid a certain amount or get interviews with the company or whatever. Um, if they like your idea. Uh, that like working on something practical, solving real problems, is great. It's really valuable. Companies want to hire developers that can solve real problems and you can showcase that with a hackathon project. Um, now, even if you, if you don't think you can build something practical or anything like that, you could still participate in hackathons and beginner-focused hackathons.
Don Hansen:I think it's still a really good experience to meet people. Sometimes you get recruiters even at smaller hackathons, but hackathon projects make really good friendships. You got to realize when you go out to meetups and you meet people with hackathons and stuff like that, if you form friendships they get hired. Even though they can't hire you, then they're trying to get a job just like you. They're your competition. But when they get hired, if they vibe with you, you made a friendship and that company asks that developer as well as the rest of the team hey, who should we interview before we put this job posting out publicly? They're usually going to take personal recommendations first, because it kind of like weeds out a good culture fit too, like if they're willing to put themselves out to recommend you. That's a big deal. Companies like personal recommendations like that. That's how you can kind of start building up your network just by working with other developers and talking with them and building friendships. You never know what can happen with that.
Don Hansen:So hackathon projects are really really good and I think group projects in general kind of almost force you to well, hopefully, you guys do this but it forces you to get a little bit more comfortable with the scrum process and even just bare minimum writing out requirements and communicating those requirements effectively and what you're working on and checking in with people. And what's cool is some of these hackathon projects can go public and really get some social proof behind them with that. But hackathon projects are really good, just like group projects are really good. You can build more impressive tools when you have a team behind you and just being able to work with other developers and source control. It's like how many merge conflicts are you dealing with when you're just working solo? I can tell you right now I work on solo projects. I have not dealt with a merge conflict in years. You should get comfortable dealing with merge conflicts and group projects and hackathon projects can help you do that. But also larger hackathons have recruiters, have eyes paying attention and when you do build something impressive, um, that can get you a little bit of an in right Um, you're not just a resume. At that point You've showcased what you can do and you build something real. You'd be surprised. Hackathon projects are really powerful for making you stand out.
Don Hansen:So now we're going to talk about freelance projects. Some of the worst advice I hear is a blank prescription that you should build freelance projects because that gives you professional experience and will make you stand out Horrible advice, just absolutely trash, garbage, horrible advice. And let me tell you why advice. And let me tell you why. Most people that are going to be working on freelance projects are going to start with really small challenges maybe a landing page. The features are going to be very unimpressive. There's not going to be any complexity, no depth to it.
Don Hansen:It takes a lot like you're as a freelancer if you're trying to actually make money. That's entrepreneurship. You're learning way more than coding way more. You better expand your time significantly if you want to make any meaningful progress at getting progressively more lucrative clients and more complex projects to be able to put on your portfolio. That takes time. Most people are going to fail at that and that's kind of the route that starts to make you look impressive. But a lot of freelance projects again, a lot of companies just want you to build a solution. They don't care about your stack. They don't care that it takes you longer to work with your stack to build what they want. A lot of clients also just like to not be tied into the developer making a bunch of updates and they want a content management system.
Don Hansen:So if you want to do freelance, I highly recommend you get more comfortable with PHP and WordPress and you can go the Shopify route. You're going to start moving away from kind of that traditional software engineering position that you might have been aiming for previously. Now, if you want to get into that and you want to work with content management systems, there's nothing wrong with that. There could be a lot of work for you down the road. That is a path. That is a career path. Nothing wrong with that. There could be a lot of work for you down the road. That is a path. That is a career path.
Don Hansen:But it's actually kind of separate from going for your typical product role or building internal tools or whatever. Take you away from diving deeper into building very complex products with a ton of features. It's really good if you want to do agency work, where you get hired at a company and you can get paid a salary. But you get hired at a company to then, which then partners you with companies that they find and you build an application, you build a website for them. So there are full-time positions available at the end of that freelancing route if that's what you're using it for, um, but a lot of the work that you're going to be doing to kind of prepare you for that, it's a lot of surface level work that you're going to be doing.
Don Hansen:A lot of freelance developers, you know with like under two years of professional freelance experience where they're getting clients all the time, a lot of people that maybe have gotten a client or two or something like that. Their skills are just so lackluster and surface level they're not competitive with a lot of other people that have deepened their skills. It can show initiative. I've even given the advice. One thing that you can try is go to local businesses and build their websites. It's a little bit of social proof, but I've warned them it's still kind of surface level stuff. You want to try to get more complex projects, build trust with them. So maybe you can build internal tooling, you can build features. Maybe it's not just this marketing page. Now you're building kind of like a crud application that now you've got to deal with authorization, you've got to deal with whatever else that they need, and it becomes more of a complex project and you could showcase moving it off from social media, where maybe they were marketing a little bit. Maybe you were able to optimize it for search engines to be able to bring them much more traffic. You can highlight that on your resume.
Don Hansen:You hear this kind of stuff, with the freelance route being a more marketable route. Almost no one does this effectively. A lot of people that try to pick up a few freelance projects most of them are just people who build some surface level apps and that's all they really achieve with it. It almost makes it not worthwhile. If you're not going the agency route, if you're going the traditional software engineering route, it's a detour For most people and I think that's the best description for it. For most people the freelance route is a detour. It doesn't help build you up. It doesn't provide the social proof that people claim it does. For most people it's just a detour and your skills wither away because you're not really applying them in a very hard problem. So you're reinforcing some skills to be able to do that kind of work, but it's very surface level and I see it hurting people quite a bit.
Don Hansen:I think freelance is just one of those things. It's like open source contributions, huge misconception about it and just like build freelance stuff, professional experience and like again, it depends on how you go about these things and what I would even start considering as I'm going through. This is what sounds appealing to me. Do I kind of like have the salesman? Do I wouldn't even say salesman attitude, but do I have this initiative, this resourcefulness and this charisma to go to local businesses and sell my services? Do I have that in me? Hell, if you're like a car salesman and you are getting into development work, you might have that. This is ingrained in you at this point. You might be really good with a freelance route. You can make that very effective and even with a freelance background, you can get into product work. I just think it's more marketable for agency type work, especially before that. Two years of professional experience as a freelance developer. So start thinking about what appeals to you, because what, ultimately, is going to make you stand out and deepen your knowledge is you diving into a path that gets you incredibly excited to continue just grinding this out, and that's what it is. It's a grind, and so you got to deepen your knowledge at some point, but you got to find a path that appeals to you, so you really build up an impressive portfolio.
Don Hansen:So I have been talking about um projects that almost like don't really sound that marketable, right. I've kind of been squashing the value of a lot of these projects. So I'm going to squash the value of one more project I'm just going to make a note of it, actually and then we're going to talk about two projects that I think are extremely effective. And so there we go. So we have personal projects. Personal projects are what you should be building most of the time, and you're able to focus on the technologies you want to grow. You're able to build cool stuff for yourself. If you can build cool stuff for yourself, it can be valuable to other people, but you can build stuff that just sounds fun to build. I always wanted to try building this Now. I have the skills now. Now let's reinforce those skills and let's try building this thing.
Don Hansen:There are a lot of personal projects that end up being pretty impressive, and there are a lot of personal projects that make me think that you are like years away from getting a dev job. No one gives a shit about your cat gallery. No one gives a shit about your Spotify like clone. I'm building like a different version of it and I'm building it with the most basic feature ever and, um, it looks like shit. I don't like didn't really put a lot of time into the user experience of it, or I'm not. I have no idea what to build, so I'm just building a bunch of random shit for no reason at all.
Don Hansen:Now we're just getting back into the realm of tutorial based projects where it's like you're kind of just reinforcing your concepts at this point a little bit. Hopefully, and hopefully you find a project where you can deepen that with features. But a lot of personal projects are just incredibly unimpressive, boring, provide no value and just end up as graveyard projects where you didn't even finish it. You got bored of it. Listen, I've gotten bored of projects. I have a lot of graveyard projects and at this time of recording this they are still up on my GitHub. I don't think I've deleted anything.
Don Hansen:A lot of really bad projects. A lot of really bad projects. These projects make you feel like you are making progress. These projects where you're kind of just building something because you don't know what to build and you haven't taken the time out to figure out what kind of problems you want to solve these projects are just they're reinforcing your skills a little bit, but they're dopamine hits, like so many aspiring developers are just building lackluster projects that know that just don't make you competitive. It's not that you're not getting a little bit of value out of them or that they're not valuable at all, it's just you have very high competition at the entry level of everyone else doing the same damn thing, building the most unimpressive personal projects ever. So I'll give a little bit more contrast towards a personal project and compare it with a personal project. That is really impressive.
Don Hansen:But before I do that, I want to talk about one really useful thing that you can do right now. A really useful project. If you are in a different industry let's say you're not even in a tech industry but you use software, especially if it's web-based software and you're trying to become a web developer, or if you're trying to get into Java, can you build something with Java? Think about what you can build, the tools, the application that you could build that your team would actually use, that your company would actually use If you spent time outside of work doing this thing for you to build even an internal tool that optimizes things for your team, for your manager and you had regular users that would give you feedback and then you would iterate, you would get, you would apply that agile process and you would iterate and push out your updates and get feedback and assist this cycle. Right now we're getting involved with the agile process, going to assist this cycle. Right Now we're getting involved with the agile process.
Don Hansen:Those projects where you can build internal tools are it's like a hack. You're not given a developer position, but if you are willing and hopefully have a good manager with this, I can maybe like give you ideas of what you could build. Um, but if you are willing to invest the time into a project like this that now gets professional proof, you're not necessarily a software engineer at that company. If you build a tool and people use it, but you're building a professional, you're doing professional dev work and that's something to add to your story about how you took that initiative to replace your shitty web software with your own that now is utilized by your team. That is a really powerful hack to just kind of getting professional-like experience on your resume. It's really powerful on your resume. It's really powerful. So I you know some of you might not have a job where or a company where you could do that. But if you are in that position, I would try to take advantage of that. Like today, tomorrow, talk to your manager about this and hopefully your manager is looking out for your best interest. But like you're like, hey, you know, I think maybe in a couple of years I might want a dev position, and hopefully there are dev positions at your company too. Right, you can kind of word it. Like you know, I think I want to move into a dev position within this company and here's my idea and present that to your manager. In that way Maybe you'll get more support over it. But it's a really powerful hack of getting that professional-like experience that is a lot more valuable than a random crud project that becomes a graveyard project.
Don Hansen:So now let's talk about the most powerful portfolio project, and I know it's maybe about 30 minutes. In so far it's kind of been leading you on a little bit. Wouldn't that be kind of funny if I just said that's it? That'd be cruel, that'd be really cruel. I'm not going to do that to you. But this project almost everyone gets wrong. This type of project almost everyone gets wrong, and I've seen some coding boot camps in the past do this extremely effectively with their students and this is where I got it from actually was coding boot camps, where they actually had high standards in the past. Some of them, a few of them.
Don Hansen:Just let me clarify that a capstone project is what you want to aim for, for a personal project. So, to me, what is a capstone project? The ideal project, a capstone project is a project that it's a tool that you build. It's an app that you build that solves your problem. A lot of companies are founded on a capstone project. They build a tool that solves their problem and if it solves your problem, it probably solves other people's problems.
Don Hansen:You're not unique in the world, not in that respect. The problems that you face are not unique, I hate to say it. You're not this unique butterfly, which is awesome because you can eventually find people to relate to your problems. But you can also build solutions for your problems and then share that with other people and that solution can evolve into a really impressive capstone project. So I say, solve a problem for yourself. You don't necessarily have to do that, but I think you don't really have to do any user research. You don't have to scan around and go through a bunch of subreddits and try to figure out what people need. Like it actually doesn't even matter if you're trying to find a good market fit or not. Like someone will use your product.
Don Hansen:But you're not trying to reinvent the wheel necessarily and it could be kind of like a slightly different variation of a tool that you use that you just it's not very effective, right, you're like why it's been six months? I still haven't, like flushed out these features that everyone's asking for. I'm just going to build my own software. Like fuck it. Right, you are building a project that solves a real problem. You are flushing out the requirements. You decide what an MVP is for that project. So, minimum viable product what is the minimum viable product that I can build that provides some value to someone? A feature You're building out a single feature.
Don Hansen:You start your app with a single feature that solves a problem and you put that out in front of people. You get feedback. You go to subreddits. Build something in a hobby community you're involved in, maybe a local community that would use it. Think about, now that you have the skill level, what can you actually build that is purposeful, that's meaningful to people, that people would use? We want to simplify it to that. Build that, finish the MVP. Don't let the scope creep. Just completely tear your project down, which means don't think about the other while you're building your MVP. Don't think I need to build this feature and now this feature and this feature until it's done. No, no, no, you've already decided on the feature that you're going to build. Finish it. Build good habits. You flush out the requirements, you document that.
Don Hansen:You build that feature, you push it out in front of people, you continue working on another feature and then maybe feedback comes in, maybe a bug comes in, or you discover bug. You work on that. Push that out. Now you got to start prioritizing. Okay, I got this feature working, but my friend or this person in this community just spotted this bug. This is kind of a serious bug. I should probably pivot, pause this feature. How do I pause this feature? Go and fix this bug, push that up, push it out as quickly as possible and then go back to this feature.
Don Hansen:Now you're thinking like a real developer. Now you're going through the chaos of what it is to be a developer and juggle these things and so you push out to more people and more people. You get more feedback, more feedback. Now you have to start prioritizing stuff that comes in and you don't have to charge for this. I highly encourage you to try. You don't have to charge for this.
Don Hansen:You treat it like a real product. You treat it like something professional. It doesn't have to turn into a company. You don't have to bullshit your way and say you were the CTO of your project which come on, stop that Like. You don't have to do that. You're just. You don't have to do that. Let the project itself, let the users that you're going to highlight on your resume, speak for the professional value that this project solves, for the social proof that this project provides by having a user base and you being that solo developer working through that.
Don Hansen:So this isn't some amateur looking project. So you have to gain some user experience. Fundamentals. Stop being lazy with inconsistent spacing. They're just really amateur. They're not even amateur. They're just lazy mistakes that new developers make. And it's just attention to detail, it's consistency in what you do, it's caring about the quality of your code. It's caring about how you organize this.
Don Hansen:And then, as this project grows, really cool opportunity happens where you have to figure out how to scale it, because now you keep going back into your code and six months later, I don't know where the fuck I am. I don't know what this app is doing. Maybe I should have documented that well. And do I just like write comments in my code? Do I write better function names? Do I organize the files in a different way? How the hell do I do this so like if I can't even come back in here and understand my code? How do I expect other developers to do that? And so now you have to start thinking about how to structure your app in a way that makes that easier, makes your code more readable. Now you are starting to focus on more complex problems that professional developers have to deal with, and you only start getting to this point when you don't give up on that project. It's a real problem that continues building into something much more impressive and complex, and it's not just complexity for the sake of complexity. It's because you have users giving you real feedback and it evolves. That's what a company does.
Don Hansen:I come from the startup world and that's exactly how a lot of startup founders start. They solve a simple problem and it snowballs when they don't give up on that idea. That is the type of personal project that now is very professional-like. You build a landing page with it. Maybe you have to build an FAQ section. Maybe you have to build an faq section. Maybe you have to build help docs with it.
Don Hansen:Um, you know, maybe you want to flush out, maybe it turns into kind of a crud project and you're working on the front end and the back end and now you want to flush out documentation and now you you're applying for back-end positions. Maybe you add open api documentation or you know, like that. I'm not saying you need to do specifically that, but now you can start evolving the project into something where you can start replicating the processes that you're going to be going through as a professional developer and you can look up some of this stuff and you look at job postings and what they care about and you have to figure out does that actually make sense to implement in my project? If not, don't just add it arbitrarily, necessarily, but this project will evolve over time and it becomes your capstone project where you can literally continue working on this project until you get a developer job, a developer job and this is a misconception.
Don Hansen:A lot of people think they need a variety of projects to stand out. No, no, no, no. There are multiple methods to getting that first position and I'm telling you the complexity from this type of capstone project, this professional project, professional-like project. I want to be clear about that. It is really impressive to employers and what I see is a lot of employers rejecting a lot of new developers because they just don't go deep enough. They're way too surface level. Their work represents their surface level knowledge and their conversation in the interview showcases that as well. They don't have a good story. They don't have a good uh, they don't have a lot to talk about with their journey of growing because they've just tackled a lot of surface level things. And I'm like you just have nothing impressive to talk about when you just keep bouncing from project to project to project every week. I don't, I don't care what you think, you're just not really building anything impressive.
Don Hansen:So I highly recommend you really consider a powerful capstone project and you have to start training yourself, because some people don't know what to come up with. You have to start brainstorming, training yourself. You could even use AI to help you, like, solidify an idea or whatever. But you have to start training your mind to become more of a user-centered developer. A user-centered developer identifies problems and empathizes with users and solves their problems. And a lot of times I think it's a lot easier to start within your own community, within your hobby community, because you already know the software that could probably benefit them, and so I think that's probably the easiest place to start. So that's it.
Don Hansen:So we went over some misconceptions. I think the capstone project is something most people get wrong and I think it's the key. I honestly think it's the key to truly standing out. Now there's more to the job search than just your portfolio. It's a piece of it. It's actually I wouldn't say it's a small piece, but it's not a big piece of it. There's so much more to it. So I totally empathize with the struggle and the frustration with going through it. This is just a piece, but hopefully you can get better at a lot of other areas.
Don Hansen:But I really want to emphasize and this is kind of like one last message that I think you should get down. You can't do everything in the job search and you are going to hear a ton of advice, a variety of advice, and you need to figure out what advice you should follow, what advice you can reasonably apply in your schedule to consistently follow to make meaningful progress. There are a lot of different paths to becoming a developer. You can't follow all of them and there is nothing that will hurt you more than splitting yourself up, tearing your hair out and trying to do every single path and just trying it a little bit and getting rejected or not getting the feedback or not getting responses back, and you try this and you try this, and you try this and you try this and then nothing's working. And then now you feel like you have no control over it because you're not really doubling down on anything. And if you're going to double down on something, I highly highly recommend it be your capstone project.