How to find your first Rails job

Notes from a job hunt

• Why Ruby?
• Where to look for Rails job postings
• My job search: a bird’s-eye view
• Resume strategies
• What to ask in the initial interview
• Technical exercises
• Conclusion
• Appendix: Why a junior role?

I’ve just landed my first developer job, a U.S.-based (but remote) junior position in fullstack Ruby on Rails 🎉 Here are some reflections on the job hunt, along with tips on finding your first Rails job.

Why Ruby?

There’s a good chance that you pity me for going through the harrowing experience of looking for a junior Rails job. Why did I choose Ruby? Why not a JS stack where junior roles are more common?

For me Ruby was worth the risk of a longer job search because (a) I enjoy it a lot and (b) Rails is great for building up a portfolio quickly. If you’re still skeptical, here’s my post expanding on these two points.

Fortunately, my job search ended up taking only two months. But before that I spent a year and a half studying and practicing part-time, while working full-time in customer support to pay the bills. For details and recommended learning resources, see my ongoing study guide.

I also looked for a junior role specifically. If you’re wondering why, see Appendix: Why a junior role? below.

Where to look for Rails job postings

I found most of my job leads in the Ruby on Rails Link community on Slack, and on Rails Devs. I also found a few on Twitter and on the StimulusReflex community on Discord.

What about LinkedIn? Yes, be sure to have a LinkedIn profile, if only for recruiters to be able to contact you. But I found only a few junior roles on LinkedIn, and none that I applied for. Some other sites that might be worth checking just in case: Indeed, AngelList, Hired, RailsGigs, and the GoRails job board. If you live outside the U.S., be sure to look in local job boards if there are any in your area. (If you’re not sure, try asking in Ruby on Rails Link.)

UPDATE, July 2023: There’s also the Ruby Central job board.

My job search: a bird’s-eye view

Over two months, I applied to seven companies, most of them startups. I got a first-step interview or recruiter screening at six of those companies, and in five of them I moved forward to next steps.

(In the one where I didn’t move past the first interview, it was because I asked about the salary range and it was too low—or rather, the interviewer did the classic “Well, what do YOU want to be paid?” and my answer was evidently far beyond what they thought reasonable.)

Speaking of salaries, there’s a huge range in what people think a junior’s salary should be. Among the full-time U.S. junior job postings I came across, not counting internships, the range in advertised salaries was $40k/year to $120k/year.

The application process varied widely between the companies, from the simplest with just two interviews to the most complex with five interviews plus a take-home project. All of them had some sort of technical exercise, whether as part of an interview or as a take-home project.

I’ll describe the technical exercises in more detail, but first let’s back up to the resume and the initial interview.

Resume strategies

To get an initial interview, having an impressive resume is key. To give you some ideas on how to polish your resume, here are things that interviewers said they liked about my resume. By the way, it’s always worth asking in an interview, “What did you like about my resume? And how could it be better?”

• Lots of projects. In one of my early interviews, I got a helpful answer to the “how could it be better” question: “More projects.” So I built a series of small apps over the following weeks. These helped fill out my resume, and they were a great learning experience. I’ve also heard good arguments (though not from interviewers) on the other side: instead of building lots of small projects, buckle down and build one big and impressive project. That’s actually the path I started on when I first learned Rails, and I do plan on returning to my “serious” hobby app, but in these early stages of my Rails journey I learned more when I was building lots of small projects.
• Write a blog. One interviewer found me through a podcast episode where I was featured. I was invited to the podcast because of a blog post that I wrote (reposted on DEVso that more people would see it). Moral of the story: write a blog! But even if your blog doesn’t lead to any special opportunities, it’s still worthwhile. Not only will your communication skills get a boost, but you can even learn something more thoroughly just by writing about it.
• Keep a study guide. I got compliments on my study guide in two interviews, but it’s another one of those things that’s useful to do even if no one notices.

Here are efforts that I didn’t get comments on, but I’m sure they didn’t hurt:

• Polish your GitHub portfolio. Here’s mine: github.com/fpsvogel. Make sure each of your pinned projects has a nice README including a summary of why it’s on portfolio. If you want to spend even more time perfecting your READMEs, here’s an awesome README list to give you ideas, and here are a few that are built specifically as part of a learner’s portfolio of Rails apps: lortza/tarot, lortza/sorrygirl, lortza/therapy_tracker.
• Make a web version of your resume. Here’s mine: fpsvogel.com/about. This is in addition to (not instead of) the PDF version that I submitted in applications. Here’s my resume in PDF as of January 2022. I made it with LaTeX, but a plain old word processor would work too. Try to keep it under one page.

What to ask in the initial interview

Once your resume is polished up, you’re more likely to be invited to an interview. We tend to think most about giving good answers in an interview, but asking good questions is just as important—after all, you are interviewing the company as much as they are interviewing you. Your goal, besides making a good impression, is to find out whether that company would be a good fit for you. Here are the questions I asked in my initial interviews, along with my motivation for asking some of them.

• “What extra onboarding and support would I have in the junior role?”
  • This helped me gauge whether it’s truly a junior role where I’d get better learning opportunities, or just a regular role with lower pay and lower expectations.
• “What kind of code reviews do you all do?”
  • Even outside the junior role, developers should be helping each other learn, and code reviews are one way that’s done.
• “How is your testing suite these days? What is your test coverage?”
  • I wanted to be sure to work at a company that follows best practices, especially automated testing.
• “How often do your developers have to work odd hours or take care of unexpected issues?”
  • Some companies require their developers to be on call during off hours. And in some companies, developers frequently have to put out fires in production. I wanted to avoid these as much as possible.
• “What is the salary range for the position?” (if a salary range was not advertised)
  • If they straightforwardly tell you the salary range, it’s a good idea to double check it in a follow-up email, just so you have it in writing.
  • If they don’t give a salary range and instead ask what salary you’re looking for, that’s a mark against the company in my book, because it makes me feel that they were too lazy to research salaries and they want to pay me as little as they can get away with. Try to resist the pressure to give a low number, and instead name the optimistic/best-case salary that you’re aiming for, and add on “but I’m willing to negotiate.”
• “Is this a W-2 or contract position?” (if it’s not clear already)
• “What kind of health insurance do you offer?”
  • I live in the U.S., with its *ahem* unique approach to healthcare, so I wanted to make sure that I’d get good health insurance through work.
• If you’re not sure what the company’s product does: “I looked through your website and I see that you all do X, but I’m still not clear on Y. Could you fill me in on the details?”
• If you’re not sure why the company exists, or what gap they’re filling: “I’m curious to hear how your company started. Could you give me a quick rundown of that?”
• If the interviewer is a developer (though this is more likely to be the case in a second or third interview): “Where did you work before this company, and why did you move? How has this company been better, and what are some areas where the company could improve?”

There are lots of other questions you could ask in the initial interview. Just be sure to ask about anything that will give you a better feel for whether the company will be a good fit.

Technical exercises

Of the five technical exercises that I did, three were take-home, and two were live coding exercises, where an interviewer watched as I wrote code and as I explained what I was doing and why. For the take-home exercises, I explained my thinking in a follow-up interview after I’d finished an exercise.

Side note: If I could have a do-over of my job search, I would be more persistent about finding out the salary before doing a technical exercise, so as not to do so many of them. Remember what I said earlier about asking for the salary range in the first interview? I was a bit lax on that until the last weeks of my job search. At least now you get to learn more about technical exercises…

Here are the five technical exercises that I did, one for each company.

• A take-home exercise where I built a Rails app that provides a user-friendly search interface to an API, and shows the search results. No time limit was given.
• A take-home exercise where I built a Rails API based on a JSON dataset. I was asked to spend one hour on it. Bonus points were given if I wrote automated tests.
• A timed (two-hour) HackerRank take-home exercise where I wrote a Ruby script that gets data from an API, processes it, and outputs the results to a file according to specifications given in the instructions. Automated tests were also provided, so that my goal was to make the tests pass.
• A one-hour live coding exercise where I got partway through solving the Gilded Rose Kata in Ruby. In this version of the kata, automated tests were provided for me in order to save time. Again, my goal was to make the tests pass.
• A half-hour live coding exercise where I wrote a command-line hangman game in Ruby.

Here are a few skills that I could tell the interviewers were looking for:

• Code readability, which involves naming things well, using object-oriented design, and avoiding code smells.
• Refactoring and short feedback loops were important in both live coding exercises.
• Automated testing. After the first two take-home exercises listed above, interviewers appreciated that I wrote tests even though it wasn’t required, and in two of the other three exercises I had to interact with pre-written tests.
• Getting a lot done. This is a catch-all for being fluent enough in Ruby and Rails to build something in a short amount of time. For take-home exercises where no time limit is given, the reality is that “getting a lot done” means spending a lot of time on the exercise. If possible, choose a weekend or a less-busy-than-average few days where you can dedicate large blocks of time to it. If you have time, write on your blog or in the GitHub README about how you did the project. Here’s my blog post about how I did the first take-home exercise listed above.

If you’re wondering how to build up these skills, take a look at my Ruby study guide which I’ve recently been working through.

Conclusion

Going into the job search, I had grim expectations for what lay ahead. I hadn’t heard good things about the junior job market in Ruby. But I was pleasantly surprised in a couple of ways:

• I got an interview at every company that I applied to, except one.
• My job search lasted only two months.

On the other hand, I see how my job search could easily have taken longer, since most junior positions don’t pay as much as I was looking for.

The most difficult parts of the job search were how much was expected on my resume, how intentionally I had to ask questions in interviews, and how nerve-racking the technical exercises were. If you’re a junior Rails job-seeker yourself, I hope you’ll find some use in my notes above on each of these areas. Good luck on your job search!

Appendix: Why a junior role?

Junior roles are a funny thing. Most people appreciate why they exist, but I’ve also sensed an undercurrent of contempt for them. I’m not saying most developers bash on junior roles. Nine times out of ten, I got helpful replies when I asked people for tips or leads about junior/entry-level jobs.

What I mean is that it’s common to admire developers who skipped being a junior and figured everything out “in the real world.” Some people take this admiration so far that they discount junior roles entirely. I’ve been told that I’m “projecting a position of weakness” by saying that I’m looking for a junior role, and that I should instead build a product and start my own company so that maybe in a year I’ll be the boss hiring people.

(￣(エ)￣)ゞ

Let’s set aside the facts that I don’t want to start my own company, I do try to convey competence and not helplessness to potential employers, and I don’t need and am not looking for extra hand-holding on every little thing—I am self-taught, after all.

Those facts aside, here’s why I applied to junior roles almost exclusively:

• Because that’s how I think I’ll grow the most. I was a teacher in my previous career, so I appreciate the power of learning by example. As a new developer, I’ll learn most quickly and most thoroughly if I’m working with experienced developers who exemplify best practices. I could probably (painfully) learn all the same things on my own over time, but it would take much longer. So I don’t believe I’m holding myself back by going for a junior role—quite the opposite.
• Because I didn’t have time to apply to everything. During the job hunt I was already working a full-time job in order to pay the bills. Also, I spent most of my free time filling in the gaps on my resume, which I felt was a better use of time than filling out dozens of long-shot applications for mid-level positions. Even the few applications that I did undergo were time-consuming in themselves, due to their sometimes long process of multiple interviews plus a take-home programming exercise. So I wanted to maximize my chances of getting a job by applying to my top (and most realistic) choices while continually improving my resume. This approach was also a lot more enjoyable than making job applications my new default evening activity.

But one time I did apply for a mid-level position with not-too-daunting qualifications. It didn’t turn out well. I passed the recruiter interview and the technical exercise, only to be shut down a few minutes into an interview with the CEO and lead developer, when they realized I was looking for my first programming job. I’m sure this only happened because of poor preparation on their part, but still I couldn’t help being discouraged from spending more of my limited free time on mid-level applications.

Also, I didn’t apply for just any junior position. I wanted to find a job where I could stay for a good long while, so I ended up not applying for most junior positions that I ran across.

• I stayed away from internships, contracts, and other temporary or low-pay arrangements.
• I stayed away from tiny startups where I would be the only developer—that’s not a junior role.
• I stayed away from positions that involved other back-end frameworks besides Rails. I’d like to stick to Ruby, at least on the back end, because that’s what I most enjoy.

So yes, I looked for a junior position and I’m proud of it!