#300 - Build a Product, Not a Portfolio

The hiring bar for junior developers has changed, and pretending it hasn’t will only slow your career. 

Let's break down a simple strategy to beat the “no experience” trap: 

Ship a small product you intend to sell, get one or two real users, and use those lessons to tell stronger stories in interviews. Instead of another tutorial portfolio, you’ll learn to show autonomy, reliability, and ownership—the exact traits teams are optimizing for in tighter markets.

By the end, you’ll know how to replace vague “potential” with proof of autonomy: shipped features, hard-earned trade-offs, and stories that map directly to the realities of modern teams.

Resources:

Side project planner: https://docs.google.com/document/d/1uJ5Bom0WmS410K5B2m5TkbZ7d1G9BdTaX4nKprYschI/edit

Side project video: https://youtu.be/2TWioJCIaxE

Shameless Plugs

🧑‍💻 Free 5 day email course to go from HTML to AI

🤔 Got a question you want answered on the pod? Drop it here

Apply for 1 of 12 spots at Parsity - Learn to build complex software with AI integrations.

AI Bootcamp - for software developers who want to be the expert on their team when it comes to AI

Chapters

• 0:00 Why Junior Hires Feel Risky
• 0:38 The Market Shift Toward Autonomy
• 1:50 Why Portfolios Fail To Stand Out
• 3:13 Build For Sale To Think Like Owners
• 4:12 Get One Real User And Iterate
• 5:48 Turn Side Projects Into Experience
• 7:06 Finding Niche, Painful Problems
• 8:44 Cheap Tools, Clear Next Steps, CTA

Transcript

SPEAKER_00: 0:00

Welcome to the Develop Yourself podcast, where we teach you everything you need to land your first job as a software developer by learning to develop yourself, your skills, your network, and more. I'm Brian, your host. Junior developers are inherently risky hires. This doesn't mean you shouldn't become one. You just have to understand that in order to have a better chance in the market, you need to kind of understand how to reverse the risk of being an outsider. And I want to show you how to do that by building a real product rather than a portfolio. And even if you're a developer who already has a job and maybe you're interested in how to build a product or build a side project that you can potentially sell, then you may find this interesting. But if you're a coding bootcamp grad or a recent college grad, you've probably noticed that the hiring bar has risen and it's not going to come back down anytime soon. Companies are hiring fewer software developers, they're expecting more autonomy and increasingly optimizing for experience over potential. We used to hire developers for their potential. We'd get them, train them, they'd stay on, we'd hire them at a really low rate, stay into the company, become mid-level developers, and now you essentially have a mid-level developer for a little more than what you'd pay for a junior developer. But now there's a massive shift. And unfortunately, most developers are preparing for a market that doesn't really exist anymore. Now here's something that's even weirder. Tech hiring has picked up just really unevenly. The reality is that more companies think they need senior developers, so all the hiring is going towards seniors, but this is often misguided. What they actually want is autonomy. Can you just like get shit done? Can you deploy the code, work within team norms, maintain a reasonable quality bar, and don't need constant supervision? Is this fair? Not really. Is it reality? Yeah. Teams are smaller, we're being expected to do more with less. And this means they kind of want you to hit the ground running. You might be making one of these mistakes. Maybe you're building a portfolio, even though everyone has one. And these portfolios are mostly front-end cruft in a market that doesn't have a ton of front-end openings. In fact, in Stack Overflow's yearly survey, less than 10% of developers even identify as front-end developers. This kind of hurts me a little bit, but it should tell you that most companies aren't hiring for strictly front-end developers. Also, if you're building tutorial projects like calculators, weather apps, or movie finders, these are fine for learning for sure. There's nothing wrong with building really anything if you want to learn. It's a great exercise to build something that's already been built. You can look for all sorts of cool examples. The problem is this is completely irrelevant to any hiring manager, and it's almost impossible to stand out because everybody's built the exact same thing. You also may be avoiding putting yourself out there. I know developers hate to do this, but you're not asking to get users on the apps that you're building. You're not sharing progress publicly. You don't want to attach your name to your code. You don't want to put yourself out there. And I get it. It's risky. People are stupid on the internet. People are mean. It's also a great way to stand out in a really loud marketplace. And because you don't do these things, you never really experience the parts of software development that actually matter to employers. Deployments, iteration, maintenance, ownership. If you have a movie app, it's really hard to experience these things. But here's how you can fix it. Step one, build something for yourself with the intention to sell it. This is the most important thing. This is really important because the intention to sell forces a mental shift. You stop thinking like, I'm just going to complete this exercise, and then you think like somebody who wants to solve a real problem that people might pay a dollar for, right? When money is even theoretically involved, you start considering the usefulness, the reliability, the trade-offs, long-term maintenance, things like registration, how you're going to collect money. You start asking better questions. Even if the project never earns a dollar and most don't, you've built it with customers in mind. I have a video and a worksheet in the show notes that's going to help you scaffold a really good side project. I'm obsessed with side projects. I had one that made around$10,000 a few years ago where I was teaching software developers how to pass tests. First project I made that made some money. And I've had too many other failed startup attempts to even count. But I use those to learn different tech stacks and get into positions at companies that also use those tech stacks. I effectively switched from a C sharp Angular developer into an AWS React Node Express developer, into TypeScript, into AI, into all sorts of things by just building side projects, gaining real experience, putting that on my resume, and then going into companies that wanted people with those skills. And like most of you, I still build side projects all the time, and I'll have a video on that coming out shortly. Step two, try to get one or two real users. Yeah, just one or two. It's going to be much harder than you can probably imagine. Getting even a single user changes how you think. You can use this experience as content if you want to write on LinkedIn or Twitter to explain what you're building and why. I think this is a great way to start sharing in public about what you're doing because now you're not just talking about your side project, like, hey, I'm looking for people to use this. It can lead to feedback you didn't anticipate, aka trolls online, can also read to real valuable feedback. And then you start fixing real problems instead of hypothetical ones. You start thinking about onboarding, support, billing, edge cases. A portfolio project could never, it could never, right? This is also where many developers realize the difference between a demo and an actual product. When you have a demo and you're using it, you understand the intricacies of the app and exactly how to use it. The moment you give it out to the world, people start using it in weird, weird ways. And you start to realize oh, maybe I should make this more intuitive. Maybe I need a better user interface. Maybe this backend system actually needs to handle a lot more stress and pressure and data than I originally thought. Maybe people are uploading tons of CSV files, or they're going to use it in ways that you find probably unique, you could say. Step number three, turn this into real experience. Here's the thing: you can just do stuff, you can do whatever you want, right? You could create an LLC and list it on LinkedIn. You could talk about the project as a real business because it is one if you actually get one or two paying users, right? Or even if you don't get a paying user, many companies are pre-revenue, meaning they haven't made money at all. Or you can build something for an existing business for free and use that work as legitimate experience. If your project makes money, you now have income. If it doesn't, which is the most likely outcome, you're still gonna win. Most startups don't make money at all. In fact, many of them lose money. And if you work there, the experience is still real. No one's gonna say, well, that doesn't count. That company didn't make money. But the most important thing is if you actually build stuff, get users, deploy it out to the web, have it at a publicly available URL on a normal sounding domain, you've reversed the risk. You've done what software developers do. You don't look like an outsider because you're not an outsider. You're a solo developer on a team of one cranking out products that people might want to use. Now you can share the pain of what it's like deploying a Lambda on AWS and cold starts and how you had to figure that out, or you can talk about a Next.js security vulnerability issue that you had to quickly fix for your customers, or you can talk about how your login was using your own at first, and then you decided to use Auth Zero or Clerk because you didn't want to maintain it. Now you have a bunch of experiences that you can talk about intelligently that map to the experiences that other professional software developers have also encountered. It gives you immediate buy-in. It makes you sound like one of us. Now compare that to the person that built the movie finder. And in any interview, you're gonna inevitably get some version of this question. Tell me about a technically complex project you worked on. And they're gonna say, Well, I built a movie finder. And they're gonna say, Cool, what was so technically complex about that? Well, I had to learn TypeScript. Much less compelling story than saying, Yeah, I launched this product that helps people find dog walkers in San Francisco and then pairs them up to go on dates or something like some weird thing like that, right? That's a much cooler story. Now, this is hard, obviously. This is why most people will not do this, but it's not impossible. I've seen people at Parsody do this, I've done this. The nice thing about software is that you can just build whatever the hell you want. You can over-engineer stuff, you can find a problem that you care about that can't be solved with a Claude Pro subscription that requires some time and thought. A winning problem to solve is something that involves hours of work, requires intimate knowledge of a particular industry, or costs a lot of money to do correctly. Thinking of what to build is usually the most challenging part of creating the side project. If you look for user feedback on popular apps that you use, maybe you can provide an alternative or build a solution for that. If you check out sites like acquire.com for SaaS apps, you can find ones that have made money and are being sold. And maybe you can come up with a similar solution for your particular market. For example, I saw this app that was being sold, I think, in Kentucky, where the customers were bail bondsmen that could look for people that had basically skipped their court dates and hadn't paid bail, and they could find out what their last court date was and like figure out a way to track them down. Really, really niche, really interesting and kind of creepy. But I thought, huh, that's in Kentucky. Could you make the same thing in California? I mean, obviously they decided to consolidate on that one tiny market, but it makes sense. I'm sure it's really, really time consuming to get all that court data for that particular city or that particular state or whatever. Maybe you could do that in Ohio or California or Arizona or something like that. Or you could look internally, look at the archaic processes in your own company. If you work for a big company, I'm sure there's tons of them, and then think how could I make this less dreadful? How can I make this suck just a little bit less? Could I create a script or a user interface or some sort of tool that could help me and my job and my colleagues make our lives a little bit better? Could I sell this? Could I just show this to the company and have them use it? This is often pretty low-hanging fruit. For example, there was a student at Parsity that works for a smoothie shop and had an inventory management. They were using old school Excel sheets and pieces of paper. And he thought, well, we can probably automate this and get like alerts and have an easy way, a simple interface for us to enter in these things rather than relying on pen and paper. Simple solution, simple problem, really cool thing that he could show off and actually helped out people at his job. Now that's a much more interesting project to talk about than the movie finder that he also built in Parsody. I mean, we do movie finders and all these kinds of projects too, because they help you learn. But this is not the thing we want you to show off or talk about or the experience we want you to ultimately have. If you do one of these things, you'll have three outcomes. You'll learn a lot, you may make some money, or both. You'll notice I didn't talk about specific technologies or languages or things to learn. You can mix and match them. At the end of the day, no one really cares about what you use to solve the problem. They care about is the problem solved. And if people will pay a dollar for your product, you have a business. And if you want to use that business to talk about it online and then get more buy-in and have less of a risky profile as a software developer, this is by far the best way to do it. The cool thing is you can deploy a project on AWS mostly for free. You can have a SQL database set up mostly for free. You can have authentication mostly for free. You can have your first hundred customers on a site making money mostly for free. And you can build all these things without having to ask for any permission at all. This is not like being a car mechanic where you have to have engines and car parts, or even a barber where you have to have people that come in to experiment on their hair, or a doctor where you have to have cadavers. This is software, it's really cheap to build. You can just go out, build whatever the hell you want, get the experience, and then talk about that experience online. As usual, I really hope that's helpful and I hope you take some of this advice. And also in the show notes, you'll see my step-by-step guide to build a side project. And there's a video probably somewhere around here that will also guide you through how I think through a side project when I have no freaking clue what to build. Anyways, hope that's helpful. See you around. That'll do it for today's episode of the Develop Yourself podcast. If you're serious about switching careers and becoming a software developer and building complex software and want to work directly with me and my team, go to parsity.io. And if you want more information, feel free to schedule a chat by just clicking the link in the show notes.