You have learned yourself some Ruby on Rails.
Perhaps, you’ve also done some just-for-jun projects while learning to practice your skill.

At some point, you might be starting to wonder if you are ready for a job as a Rails developer?

1. A project to show off

Not having previous work experience, a project built just for the purpose of showing off you are capable of working can come in really handy.
It can be literally anything.
It’s not the idea, but the execution that matters (code, tests, commits, etc).

Don’t go for quantity, go for quality. One strong project is better than 3 mediocre.

2. Commit like in a team

You should use source control.
Your commit messages reflect the changes and are formatted properly.
“Fix a failing Order spec” and “Make Order button actually work”, not “fix”.

Commits should be focused, not huge: all 148 features shouldn’t be included in one commit.
On the other hand, they shouldn’t be very atomic.
148 commits with one-character change in each won’t do, too.
Feel the boundary.
A single ‘entity’ you are delivering — be it a bug fix, or a new feature — can be its own commit.

3. Code like in a team

But also don’t overcomplicate your code with abstractions that provide no benefit

Be confident with unit tests. They are there to guide your design and ensure you don’t break things

Really write these high-level feature/acceptance tests

4. Not afraid of raw Ruby and OOP

Rails will take you great lengths, but from time to time you are going to be writing plain Ruby classes to perform some processing that wouldn’t otherwise fit into the Rails MVC structure.
That’s perfectly fine.
Don’t be afraid of that!

Know your Ruby beyond the Rails boundaries.

5. Practice code challenges

Code challenges often are a part of the interview process so be prepared for them!

Both Codility and HackerRank provide some nice challenges to tackle.
Not every challenge there is suited for a junior position, so don’t feel bad about yourself if you can’t solve a pro level task.

Note how it includes explanations of binary trees — so that lack of binary tree knowledge shouldn’t come off as an issue.
Just stick to the described problem.
Your solution might not be the most performant and that’s okay!

The point is rarely to see you perform on one as quickly as possible.
Instead, the point is to see how your thoughts flow and combine to solve a given problem.

(Some, if only brief, understanding of computer science fundamentals can obviously be helpful.
Basics of binary trees and reaaal simplistic understanding Big-O will never hurt.)