A guide to hiring Ruby on Rails developers
Ruby on Rails is a web framework written in Ruby. It gives a team a standard way to organise a web app, with models for data, controllers for requests and views for pages. Many companies built their first product on Rails and still depend on it today. This guide explains what Rails developers do, how to judge them and how to set up the work so it goes smoothly. Founders starting fresh and companies with apps that are many years old can both use it.
What Rails developers work on
Rails work falls into a few groups. New features are the most visible: a sign up flow, a booking screen, a payment step or an admin tool. Upkeep keeps the app healthy: bug fixes, speed work, security updates and cleanup. Upgrades move the app to newer versions of Ruby and Rails so it stays supported. Integrations connect your app to payment, email, maps and other services. Some developers like all of these; others are happiest on one, so say which you need most.
How this role differs from nearby roles
A Rails developer is a back-end specialist who knows one framework in depth. Our back-end developers page covers other languages and frameworks too. A full stack developer works on both the server and the screens, which suits teams that want one person across the whole feature. If your system also uses PHP, see our PHP developers. Use this page when your code is in Ruby on Rails, or when you want to start a product in it.
What to decide before you hire
- Your Ruby and Rails versions, and whether an upgrade is planned.
- The main work: new features, upkeep, an upgrade or all three.
- Your database, hosting and how code is released today.
- How well the app is tested, and who reviews code changes.
- Whether the front end is Rails views, Hotwire or a separate React app.
Reading a Rails developer’s work
Ask to see code, not only a list of projects. A pull request shows how someone names things, splits logic and writes tests. Look for small, clear changes, tests that describe behaviour and sensible commit messages. Check how they handle queries: a loop that asks the database for the same kind of record again and again is a sign of a common Rails mistake. Ask what they would do about a controller that has grown to far too many lines.
Interview questions to try
- A page is slow. How do you find out why, and what do you try first?
- Where do you put business rules: in the model, a service object or somewhere else? Why?
- How would you add tests to a feature that has none before you change it?
- An email must be sent after a payment. How do you do it so a failure does not lose the order?
- Tell us about an upgrade you did. What broke and how did you find it?
Real answers include a story about something that went wrong. Be wary of anyone whose upgrades always went perfectly.
Run a small paid task
Set each finalist a small job based on your own app: speed up a slow page, add a small feature with tests, or review a pull request that hides a few problems. Pay them for their time. Then compare the code, the tests and the questions they asked about your product.
Match experience to the work
For a first version of a product you need someone who moves fast and keeps the code simple. For a mature app you need a developer who reads before writing, protects what works and makes changes in small steps. For an upgrade, look for someone who has done one before and can explain the order of the steps. Titles differ between companies, so ask what each person owned.
Give them tools and a rhythm
Open the repository, the task board and a test environment to your developer, and keep every other door closed until it is needed. Hosting, domain names and third-party accounts should stay registered to you. Early on, meet weekly and read every pull request. Once trust is built, a written weekly update and a monthly review of open tasks are usually enough.
Working with the rest of your team
Rails developers work most effectively when tasks are clear and product questions get quick answers. Designers need to know what is easy in Rails views and what needs more code. If you also have a separate front end, agree the shape of the API together before building. A short weekly demo helps everyone see progress and catch misunderstandings early.
Mistakes to avoid
- Letting an old app fall many versions behind because upgrades feel risky.
- Adding features to code that has no tests and no review.
- Running slow tasks inside the web request instead of a background job.
- Choosing a developer by title and not by the code they have written.
- Letting a contractor own your repository, hosting or accounts.
Your system may need more than Rails. Our guides on how to hire a back-end developer or a full stack developer, and a hiring walk-through cover those roles.