“Why is it so difficult to find Junior Ruby on Rails dev roles?"

You have finished multiple online courses, workshops and might even read some books to learn Ruby. You start job hunting and you struggle to land a position because of your lack of experience.

So how do you get experience with large Ruby and Rails apps when no one wants to hire early-career devs?

It’s a tough market for any early-career dev with little to no experience, so it’s no different with Ruby. You’re not alone, my friend!

If you don’t know what else you can do besides doing another tutorial or starting another small Ruby project, here’s an idea for you: contribute to Rails.

“Wait, what? Me? Contribute to Rails? I’m just starting my career!”

I know. This is not usually recommended as a beginner-friendly open source project but here’s something you probably haven’t thought about yet.

What if you learned Ruby on Rails from the source?

Now that you have done tiny apps it’s time to try something different.

Rails can be daunting. It’s so abstract and complex. I feel the same!

However, just by lurking around you’ll see how a large project is designed and maintained.

This might not seem like it’s important but you’ll be learning how to:

  • read other people’s code;
  • read documentation;
  • write good documentation, commits, and Pull Requests;
  • navigate in a large codebase;
  • ask for and do code reviews;
  • improve your communication skills (super important for remote jobs);

Believe it not, these things are what you’ll be doing most of the time as a developer.

You will have a better understanding of the tool you’re using every day. Can you imagine how cool it can be to use those skills on your projects? Interesting topics to discuss on interviews, huh?

How does this approach help me get a job?

Although this won’t guarantee you’ll land a job soon, it certainly will help you develop competitive advantages. A few examples:

  • Apply your lessons on your projects (great for your portfolio!);
  • Write blog posts or present a talk teaching others how to understand a specific module;
  • You will feel like a badass! Plus, it’s a way to show you have good initiative;
  • Some companies allow skipping the whiteboard interview if you have interesting open-source contributions;
  • You’ll be connected with more experienced/expert Ruby devs;
  • You’ll be putting yourself out there instead of just learning on your own.

But first, you need to get started.

How to get started with contributing to Rails

Go to the Rails GitHub repository. Choose one module. ActionPack, for example, is a good option because it doesn’t require any database drivers configuration.

Choose one merged Pull Request (suggestions: this or this one) to get started. You probably won’t understand either of the PRs. Don’t panic, that’s expected! Keep reading.

When you take a look at the PRs, you’re not expected to understand the changes. The goal is to ask yourself: Why were the changes were made? How did the author approach it? How was the code review given? Was the author a regular contributor? Did the issue have reproducible steps?

What can you learn from it? Nothing is a valid answer although I’m pretty sure you at least learned that it’s not beginner-friendly. That’s something, right?

You can even go one step further: could you learn a thing or two about Ruby? Is it touching the controllers, the models, the views? What is the context?

Rinse and repeat until you feel like you’re starting to understand how things are done on the project. It’s going to take some time.

Eventually, you’ll feel more confident to work on an issue. However, when you go through the Rails documentation, you’ll know this is just one of many ways to contribute to the project 😉.

But Rails is scary! What if I get stuck all the time?

It’s going to be difficult. Remember: Rails is super hard. But the goal is not to aim to understand it for now. The goal is to get familiar with large codebases, learning how to find yourself in a new codebase, seeing how people ask questions, give code reviews, reading the docs.

These are normal things you’ll do on the day-to-day as a developer. It’s a good opportunity to practice asking good questions and learn how to get unstuck. These are valuable skills for your career.

Give it a try. Set an event on your calendar to do this for at least 1 hour every week. Write down your progress, celebrate every tiny lesson, and see what happens.


Did you like this article? Then you're gonna love these other ones: