Why you can't find a job as a junior (ruby on rails) developer

When I sat down to write this blog post, it was going to be titled "Tips and tricks to find your first junior (ruby on rails) developer role"

Aug 31, 2022

But, as I was writing it, I couldn’t shake off the feeling that I was repeating what everyone else was saying. They are common sense tips that you will probably read in every shape and form elsewhere.

Instead of recreating yet another easy-to-write, easy-to-forget blog, let’s explore why it’s currently difficult to find a job as a junior Ruby on Rails developer.

What can you do about it, hopefully giving you ammo on getting those first conversations?

What are those tips?

Before anything else, let’s make a quick list of the common tips you’ll find if you’re looking at getting your first junior developer job:

See, I told you, those tips are not groundbreaking. Again, I wouldn’t be surprised if you were to find those on every blog post about junior tips to get your first job.

Right, but why do I struggle to get the interview then?

Now we’re entering the actual subject. You’re ready. You’re prepared. You’ve got a small portfolio of little projects, but somehow, no jobs are coming your way. Why the hell is that?

It’s not you. It’s Rails

Unfortunately, at the moment, Ruby on Rails seems to be a double-edged sword. Ruby on Rails allows anyone and any team to write web applications productively. To achieve the same results, you then need fewer people. And needing fewer people is then having a direct effect on the recruitment rounds and most notably the juniors.

See, some recruitment manager or some teams only see in bringing juniors to their team the productivity impact this will cause (either because of the time they will take away from more senior folks, or because they could have hired a mid-level/senior instead).

Now, on this point, realistically, there’s nothing you can do to change their mind. It’s a difficult decision to reason because one side of the equation is true (yes, taking a junior in a team will have an impact on productivity), but the other side is entirely narrow minded (more on that later).

So, yes, it’s not you. It’s Rails. But, the community is becoming more aware of the issue. Most of us have a deep sense of pride and attachment to Rails as a framework but also realise that we need to solve this issue for Rails to strive in its renaissance. For Ruby on Rails to continue its journey, we need to get more people (juniors) to experience it.

It’s not you. It’s the (more) seniors developers

While this point is valid for Rails, it’s also true for any other language and framework.

Sometimes seniors might be excellent developers, but they can be terrible mentors.

A junior developer will inevitably need a mentor to grow and strive in his journey, and this mentor should, more often than not, be found in the team he spends his day with.

But when the seniors in the team don’t have that mindset, they sometimes can be blockers into bringing Junior folks into the team.

Unfortunately, this might be due to the strange progression expectations of our industry.

You see, I have more than 20 years of experience as a developer, and sometimes I struggle to call myself a senior developer. I’m still part of a specific journey, and I’m still learning.

But it’s not rare to see someone rise from Junior to Senior or sometimes even CTO in a very short (less than five years) career span.

This is something I find incredibly unsettling about our industry. Why are we looking to move so quickly to those senior positions? Yes, pay compensations and responsibilities are one part of the equation. Still, the reality is that when you get senior developers with five years of experience, they might not have the time to develop some of the soft skills needed to succeed as well-rounded developers. Mentoring/training is undoubtedly part of it.

It’s not you. It’s us

While (some) Senior developers have a role to play in the current situation, founders / recruiting managers should also look at themselves.

Based on what we said so far, we know that:

  1. It’s difficult to recruit
  2. Rails is a productive tool and will allow anyone to work faster with it
  3. Some seniors are not keen or ready to become a mentor

Taking all this in consideration, it’s easier to see why some of the people in charge will revert to the mid/senior roles only.

This is a false good idea.

By doing so, the team exposes itself to a various series of issues.

Hiring juniors well could combat all these points. Hiring juniors will give seniors an extra sense of achievement that will sometimes retain them in the current team for longer (as long as they are well supported in their mentoring journey). Juniors will bring a fresh new perspective and, if treated well, will stay loyal to the team that gave them a chance in the first place. Finally, while they will bring that fresh perspective, correctly mentored, they will be ready to mentor themselves for the next round of more junior folks coming in in a few years.

But don’t despair. Things are moving

While this is painting a pretty gloomy picture of the whole situation, some voices in the community are starting to emerge and are raising the same concerns I present in this article.

It will change, I’m sure. Things have to move as, without giving a chance to folks who want to join our community, Ruby on Rails might be the best framework in the world to build products, but it will then lack the talents to write the code.

We’re literally shooting ourselves in the foot if we are not welcoming and training the next round of talents.

Yes, it’s hard and will impact productivity, but there will be many more benefits and positives. And people are starting to either realise it or, at least, hear about it.

Ok, so how do I get my first interview?

Right, that was quite a lot of introduction to the problem. But you might wonder what difference it makes to you and how you’ll get that first interview.

Well, the job as a developer is about solving problems, and you trying to get a job is currently your first problem to solve. It’s going to be time to be creative.

And to solve a problem, you need to understand your users. You need to understand and reflect on what they are experiencing, how they are currently solving their problem, and the possible solutions you can bring to the table.

In that scenario:

Great, now that we’ve assessed the problem and, if you’ve read the rest of the post, you should understand more about the various mindsets at play. We must concentrate on the few tactics that will separate you from the pack.

Unfortunately, there will not be any secret recipes ensuring that every junior dev will have found their new team tomorrow. It doesn’t work this way.

It’s still a very competitive market. But, now that you’re armed with knowledge, we can make a difference for your next job application.

Also, hopefully, since you understand that it’s not you. It’s [Rails/us/them] you’ll take rejection less harshly and rebound faster.

Select passionately

If you’re struggling to find your first job, it’s tempting to “spread and pray” your CV to every recruiter and respond to every job application.

Unfortunately, this is doing more harm than good. Let me give you an example, and let’s consider this email:

Subject: Ruby on Rails developer application

Dear Sir/Madam

I'm writing you regarding your job application for a Junior Ruby on Rails developer role.

I'm a junior developer from So and So university and would like to be considered for the role.

I am sharing my CV with you for consideration.

Kind regards

Jack

Now let’s have a look a this one

Subject: Would you like me in your team?

Hi Nic,

I'm currently looking for my first role as a Ruby on Rails developer, and your current job application caught my eye.

I'm interested in learning more about age tech because I had to deal with the problem first-hand when I saw my mum having to act as a carer for my grandad.

I've looked at Amba and the software you're building, and I truly think it could be a big part of the solution.

I'm currently looking for my first role, and a team like yours seems like it would be a fantastic opportunity to learn from.

While I've got a lot to learn, I'm currently considering specialising on the backend side because I love the problem business logic/problem-solving part of development.

My CV is attached, but you can look at my github profile here (a link) and, more specifically, at this small code I recently wrote as I learned how to write Rspec specs (link to repo).

I'm free any day for an interview, except on Tuesdays and Friday morning.

I hope we'll get a chance to catch up.

Kind regards

Alice

I hope you can see the difference between the two approaches. Jack feels uninspired. And it will be since it’s probably an email blasted to everything single email they can find their hands to.

Alice’s approach is a lot more personal. They can’t blast these emails (even if you can reuse a lot from one email to another). They seem to have taken a bit more time and careful consideration on who to apply with.

As a person in charge of recruitment, I receive at least a dozen emails like Jack’s a week when we say we’re hiring.

I don’t often receive some like Alice’s, but when I do, I look at them differently and will give them a stronger consideration. If they don’t match what we’re looking for right now, they can be sure to at least receive a reply (it’s the least I can do as they put in the effort), and I will keep their email in a special folder where I can go back to when the time is right.

You have to select who you’re applying with and know why you’re applying to this team. But what about the passionately?

The word passionately is here not to say that you’ll fall in love with the selecting company process but because you’ll have more chances to speak the truth when you’re applying at companies where you have a natural bond.

Let’s imagine you’re a surfer and that’s how to spend your weekends. Taking the time and putting a lot of effort into trying to impress the recruitment manager for YourBestSufingSpots.com is probably going to sound more genuine than if you were spending time trying to impress the manager at another random company.

But it’s not just about your hobbies. It’s also about your world views. For example, we’re currently trying to help the ageing population regain more independence. You might not give a toss about the ageing population but might have been more attracted to the younger population. Trying to apply to work with us will feel forced, and you’ll have difficulty convincing yourself and yourselves that you’re the right person for the role.

Have something to show

I know what you think. How can I possibly have something meaningful or worthwhile to show if I’m just a junior?

But, having “something to show” doesn’t mean something crazy and super innovative to show.

It means be prepared to share one or two examples of codes you’re proud of.

When we look at this code, our aim is not to judge the “cleverness” of the code. We (or at least I) will be looking mainly at:

  1. The fact that you’ve taken the time to master your craft
  2. The general structure of the code
  3. If you wrote any tests for it

But more importantly, we can use this code during our next chat as an anchor for the conversation. Sometimes it’s difficult to discuss the abstract of development, and being able to focus the discussion on a piece of code you’ve written, you will feel more comfortable, and it will feel like a genuine discussion rather than an interview or, worst, an interrogation.

If you’re looking for inspiration on what to build, I usually recommend building a small “e-commerce” idea. Think of a store with a list of products, a filter by categories, an add-to-basket functionality and a fake checkout flow if you wanted to push it (don’t bother with payments and such; fake is all good).

I recommend building that e-commerce because the UI is simple and known by everyone. It can allow you to express some of your personalities with the products you decide to “sell”. Finally, it’s a good exercise as you’ll have a couple of show pages and some create functions.

If building an e-commerce is not your thing, I recommend checking this post by Nikki Siapno with her own ten recommendations https://medium.com/geekculture/10-fun-coding-project-ideas-to-get-hired-as-a-junior-engineer-86c3bacf7ea7

Don’t be scared to apply

That’s typically when I hear an “easier said than done, Nic!”. But trust me.

While it’s difficult to tentatively apply to companies that are not hiring right now, if you “select passionately”, it should reduce the scope of those companies.

Secondly, if you see some that have open positions for a more qualified role (like the dreaded minimum three years of experience), I would urge you still apply.

But, don’t apply by sending a generic three lines email. As we’ve discussed earlier, if you want the job in this company and are punching above your weight, take the time to craft that first intro email showing them you’ve put some careful consideration about applying there. Acknowledge that you’re less qualified than the desired experience, and get your code example in that email.

It won’t work all the time, but I can assure you that if you were to take your time when you craft your email and make it unique-ish, it would make the person on the other side of the screen stop and read your email. You’ll already have a better application than 95% of the more experienced developers.

I know it’s scary, but do it a few times, and you should have at least some positive feedback that will keep you going.

Agency / Consultancy / Products

The kind of companies you will be applying to will most likely fit one of those three categories—each with its pros and cons.

Agencies

Here, the company builds products for other people. They are paid to write code for a client, usually for a fixed amount of time.

Agency work is great for junior developers because you will see a lot of different products as well as a lot of different codebases and possible coding styles.

The downside is that agency work tends to be highly deadline driven and can be more stressful.

But, given that agencies make their money by selling people time, they are more prone to hire junior developers because they are cheaper. Make sure you’ll find an agency with enough seniors to support their junior ratio (typically, one senior for three juniors would be the very maximum I recommend in an agency). I would tend to favour ten or 15+ people agencies as they are the most likely to need your skills and have the backbone to support you.

I’m completely biased here, having spent more than ten years running one, but I think an agency is a fantastic way to start as a junior developer (if you find the right one for you). The breadth of experience you’ll get, and the variety of problems to solve will be extensive. You’ll also learn to work under some pressure (deadline) and typically with some rapid external feedback (clients).

Consultancies

Typically, in the Ruby on Rails world, you will find Agencies and Consultancies bundled into one company. Consultancies are still paid to write code for other people, but this time they are not writing a new product but improving an existing one.

These improvements can be code related (working on some legacy system upgrade, performance or DevOps etc.) or process related (Helping a team to run better stand-ups, retrospectives or write better tests).

Because consultancies are hired for their brain and expertise, and because it’s typically a very client-facing role, it will be difficult, as a junior, to find your way in.

Unless they have an opening stating they are looking to hire junior developers (usually in cohorts), I would not waste too much time trying to apply here. While your profile can be interesting, they may struggle to fit you in realistically.

Products

Products is a vast title here. Some products will be public-facing and tools are written as part of a larger entity (think gov.uk website, for example, or a quote calculator on a website).

Some products will be the company, for example, SAAS products.

And finally, some products are internal tools only used by the company.

Unlike agency work, product work tends to be less stressful. Deadlines still exist, but they are fixed internally and tend to be less dramatic. So the product work environment tends to lead to a simpler / calmer experience.

On the other hand, while products grow and evolve, they tend to follow a path on a conveyor belt. Where with agencies, one month, you’ll work on a food delivery startup and the following month, work on a new interactive video streaming platform.

With product teams, you’ll probably work on the same product for the next couple of years.

But, you will also probably be able to dig much deeper into problems because, unlike agencies, you will have the time to do so.

Welcoming product teams can also make a terrific first step in the industry for junior developers.

Closing words

Sorry, I didn’t intend to write something that long, but if you’re still there, it is probably worthwhile.

I know that some of these points go against what people would like to read or even how our industry should work, but they are the reality for the moment.

Don’t get discouraged if you are looking for a (Ruby on Rails) junior position.

Our industry needs you.

But more importantly, when you’ve found your position and grown in seniority, don’t forget, at some point, to give their chance to that younger, hungrier you. You could be surprised by who they become.