Lately I read a lot of people complaining about the lack of job offers for juniors, or about all the requirements they’re being asked for, and yeah, the market isn’t as easy as it was in 2020, but just sitting around waiting and venting on social media isn’t going to change that.

Every time I’ve talked to junior devs, they always have tons of project ideas, and that’s not a bad thing. I know that when you first get into tech you fantasize about building the ultimate solution to something, having your own startup and raising millions. Some people get lucky and have a good eye for finding problems and coming up with solutions, and now with vibe coding, shipping a prototype is way easier. But I wouldn’t say that’s the best path for juniors. Having your own startup can wait until you actually know a lot more.

A while back, building small projects like a to-do list used to help. But honestly, today I’d say don’t waste time on those projects that obviously came out of a tutorial you watched. It’s super obvious, and you don’t really learn anything that helps you professionally. They’re good practice, but not something to show off.

But I’m not here to just point out problems, I’m also here to share a solution, or what I think is a really good option to get started in the industry, especially now that there’s kind of an open source boom.

Contributing to open source? Isn’t that hard? Well, it depends on the project you pick and the issue you decide to tackle, but I wouldn’t say it’s hard.

But do they pay you or is it free? Well, logically, at first it’s free. If you’re really good, who knows, but most of the time it’ll be free. But hey, nobody’s paying you for that to-do list you vibe-coded either, right?

Open source contributions are contributions that, at interview time, will add way more value than any private personal project you could build. Let me explain some of the reasons:

1. Maybe you’re expecting me to start with something code-related, but no. When you move into the professional world, writing code isn’t enough. You need to know how to work in a team, collaborate, expose yourself to feedback, and use different tools. When you build a project alone, you stop developing those skills, but in open source you’re completely forced to put yourself out there, receive feedback, use tools like git and GitHub (sometimes at a bigger scale than at a company), follow workflows, and communicate with different people. All of this gives you a lot of soft skills that are really necessary in the industry and that you just can’t develop on your own.

2. Now, something about code. At first it feels embarrassing to have other people look at the code you write, but open source is full of people with different levels of experience who are willing to review the pull requests you open and give you suggestions to improve. It’s going to be the best way to improve your code quality: putting it out there and getting feedback.

3. Another thing open source gives you is adaptability. In personal projects, we get to pick the tech stack we like. It’s normal at the beginning to pick based on taste and trends rather than evaluating what’s best for the problem. But in open source, most of the time you don’t get to choose. You have to adapt to whatever’s there, learn a lot as you go, and slowly start understanding the reasoning behind certain decisions. Which leads me to my next point.

4. You don’t need permission for any of this and you don’t have to wait for anyone to contact you. It’s not super easy and like everything else there’s frustration along the way. You might get a lot of pull requests rejected before your first one gets accepted, or they might just ignore them, and that happens. But even so, you learn in the long run, and all of this is completely valid work experience.

Now, as I mentioned, you don’t need permission to start contributing, but here are some tips to get going:

• First, look for projects you like, and if you actually use them, even better, because then you already know as a user what you’d like to see added or fixed. Like I said before, contributions are often unpaid, so it’s better to invest that time in projects you care about and that align with your interests.

• Start by reading the README and the contribution guidelines so you understand how they handle contributions. That way you already know not to send a pull request with no description and messy commits, or a 1 million line PR changing everything from Zig to Rust. That kind of thing isn’t going to fly as a new contributor.

• Look through the open issues for tags that indicate something is a good first contribution. Those are usually easy and help you read through the project and understand things as you go.

• Even though it’s not super common, several projects have Discord servers or groups on some platform. That’s useful for asking questions, but be careful what you ask. In this industry you have to know how to ask. What do I mean? Nobody likes being interrupted with questions that are completely Googleable. So always try to figure things out on your own first, and if you really can’t find anything, list what you searched for, what you tried, and then ask the question.

• This next one is really important: you (and everyone really) are learning. I know devs have a reputation for being arrogant, but here you have to be humble and treat people the best way possible, especially because everything is online. If we want a project to thrive, everyone has to do their part. People won’t always respond to you nicely, but don’t take it personally. Let’s avoid repeating those patterns.

But are there chances of making money? I was being realistic at the start, a lot of it is going to be unpaid, but bounties do exist (small tasks that pay). Not all projects have them, and you’ll come across really badly if you show up at a project demanding money when nobody’s forcing you to contribute. You do it because you want to, always keep that in mind.

And how is this supposed to help me get a job? Think about it: you went from zero work experience and personal projects where you probably didn’t even use branches, to real experience, to being able to talk about collaboration, to explaining decisions, and to showing code in real projects where you expose yourself in a lot more ways. With just that, you’re already way ahead of other juniors with no experience competing for the position you want. And it’s not dead time on your CV.

So think about it. Instead of being on social media complaining about the market, look for ways to get the experience you’re missing. Open source is that opportunity that doesn’t ask for a CV or 5 years of experience, just proof of work.

PS: this is my first article, please be kind with the writing.

My GitHub so you can check out my work: https://github.com/AndreaDiazCorreia