Hire Ruby on Rails developers

Rails remains one of the fastest ways to build a web product, and hiring for it means finding people who use its conventions well rather than fighting them.

What Ruby on Rails actually is

Ruby on Rails is a web framework written in Ruby, built around convention over configuration: follow the expected structure and naming and a great deal works without being specified. It supplies an object-relational mapper, migrations, routing, view rendering, background jobs, caching and testing, all designed together, and it has maintained a clear opinion about how web applications should be built for two decades.

Its enduring advantage is speed to a working product. For a team building a data-backed web application with conventional requirements, Rails remains among the fastest routes from nothing to something customers use. A great many well-known products were built this way and many still run on it, which is worth remembering when the framework is described as legacy.

The hiring context is specific. The Rails market is smaller than it was and the developers in it tend to be experienced, because few people start with Rails now. That produces a pool that is smaller and stronger than average, and it means a job specification asking for a junior Rails developer is asking for something that barely exists.

The part that separates seniors from mid-levels

Active Record is the centre of the framework and the source of both its productivity and its performance problems. Models map to tables with almost no configuration, associations are declared in a line, and queries read like English. The cost is that it is extremely easy to issue a query per record without noticing. The N plus one problem is more prevalent here than in almost any other ecosystem, and the framework provides tooling to detect it that many teams do not enable.

Convention is the second thing to understand, and working with it is a genuine skill. Rails makes assumptions about naming, file location and structure, and code that follows them is short and readable to any Rails developer. Code that fights them is longer, stranger and harder for the next person. A developer who knows which conventions matter and which can be departed from is considerably more valuable than one who follows all of them or none.

The third area is what happens as an application grows. Rails scales technically further than its reputation suggests; what struggles is the codebase, because the default structure offers no strong opinion about where business logic lives once controllers and models are no longer enough. Mature Rails applications either develop a deliberate answer to this or develop very large model classes. Which one a candidate has experienced tells you a lot.

Where Ruby on Rails is used

The label “Ruby on Rails developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Product startups

Where speed from idea to customers matters more than anything else, which remains Rails's strongest case.

Established SaaS products

Mature applications, often a decade old, still actively developed and generating substantial revenue.

Marketplaces

Multi-party platforms with payments and messaging, which the framework and its ecosystem support well.

Internal business applications

Operations systems where conventional CRUD work is most of the requirement.

Content and publishing

Editorial platforms with custom workflow that a content management system would constrain.

Modernisation work

Upgrading long-lived applications across major versions, a substantial share of available work.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Ruby on Rails versions are still supported

Rails publishes maintenance and security support windows per release series, so whether an application is on a supported version is a matter of record rather than judgement.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 2 are still maintained and 6 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Ruby on Rails alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Ruby

The language. Its expressiveness is much of why Rails feels the way it does.

Active Record

The ORM. The thing to interview about if you interview about one thing.

PostgreSQL

The usual data store in current Rails work.

Sidekiq

Background job processing, effectively standard.

RSpec or Minitest

Testing. Rails has an unusually strong testing culture and an untested Rails application is a signal.

Hotwire

Interactivity without a separate front-end application, the framework's current answer to that question.

Bullet

Detects N plus one queries in development. Its absence is a meaningful finding.

Redis

Caching and job queues.

Related skills that frequently appear on the same specification: Python, JavaScript, SQL, React, AWS.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

The N plus one problem

More prevalent in Rails than almost anywhere, and the first thing to check.

• Strong answer: Uses includes and preload deliberately, runs detection tooling in development, and can describe fixing a real case.
• Warning sign: Has never inspected the query log for a page.

Where business logic lives

The defining architectural question in any mature Rails application.

• Strong answer: Has a considered position, whether service objects, form objects or another pattern, and can explain the trade-offs.
• Warning sign: Puts everything in models and controllers, or applies a heavy pattern uniformly without reason.

Callbacks and their costs

Active Record callbacks produce invisible behaviour that fires from unexpected places.

• Strong answer: Uses them sparingly, knows they fire from tests, seeds and imports, and has removed one that caused trouble.
• Warning sign: Implements significant business behaviour in callbacks.

Migrations on real data

Where Rails work causes outages rather than slowness.

• Strong answer: Knows which operations lock, adds indexes concurrently, and separates schema changes from backfills.
• Warning sign: Has only run migrations against small development databases.

Testing approach

Rails has a strong testing culture, so weak testing is a deliberate departure.

• Strong answer: Tests behaviour through requests, keeps the suite fast enough to run, and is clear about what is not tested.
• Warning sign: Quotes coverage as a goal, or works in an untested application without concern.

Upgrading across major versions

Most Rails work involves applications with history.

• Strong answer: Has taken an application across majors, and can describe gem compatibility problems and how they were resolved.
• Warning sign: Has only worked on applications that stayed on one version.

Front-end approach

A live decision, between Hotwire and a separate application.

• Strong answer: Can explain when each is appropriate for the team and the product.
• Warning sign: Assumes a separate single-page application is always the modern answer.

Warning signs in a Ruby on Rails codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

The N plus one query

• What you see: A view iterating records and touching an association on each.
• What it costs: Hundreds of queries per page, with latency growing as data grows.
• The fix: Eager load explicitly and run detection tooling in development so the problem is visible when written.

Fat models

• What you see: Model classes of a thousand lines holding most of the application's business logic.
• What it costs: Nothing can be understood or tested in isolation, and every change risks unrelated behaviour.
• The fix: Extract into service or command objects with clear inputs and outputs. Keep models for persistence and their own data.

Business logic in callbacks

• What you see: Important behaviour triggered by saving a record.
• What it costs: Effects firing from tests, fixtures, imports and the console, producing results nobody expected.
• The fix: Call the behaviour explicitly. Reserve callbacks for narrow concerns tied to the record itself.

Blocking migrations

• What you see: A migration altering a large table applied directly during business hours.
• What it costs: A table lock and an outage during what was planned as a routine deploy.
• The fix: Know which operations lock, add indexes concurrently, and split schema changes from data backfills.

Stalling on an old major version

• What you see: An application several versions behind because upgrading was deferred.
• What it costs: No security support, incompatible gems, and an upgrade that grows harder each release.
• The fix: Upgrade one major at a time with the test suite running. Staying current is routine; catching up is a project.

Unbounded queries in views

• What you see: Collections rendered without pagination or limits.
• What it costs: Pages that work in development and time out once real data exists.
• The fix: Paginate by default and treat an unbounded collection in a view as a defect.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Rails developer.

Junior

Rare in this market. Builds CRUD features following conventions, with review on query patterns.

Mid-level

Owns a feature including its background jobs, tests and migrations. Recognises an N plus one problem unprompted.

Senior

Owns application architecture, the answer to where business logic lives, the upgrade path and performance under real data.

Staff

Owns the long-term shape of a mature codebase, the extraction strategy if services are being split out, and the case for staying on Rails.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New product build

• Usual team: One to two developers.
• What governs it: Rails reaches a working product quickly. The data model is the thing worth taking time over.

Major version upgrade

• Usual team: One developer.
• What governs it: Scoped by gem compatibility and test coverage. Several majors behind with thin tests is a project.

Performance remediation

• Usual team: One senior developer, time-boxed.
• What governs it: Almost always queries. A query log and an afternoon identifies most of it.

Architectural refactoring

• Usual team: One to two senior developers.
• What governs it: Extracting logic from fat models. Scoped by test coverage, which determines whether it is safe at all.

Team augmentation

• Usual team: One to three developers.
• What governs it: The pool skews senior, so augmentation here tends to be productive quickly.

Migration work you may actually be hiring for

A large share of Ruby on Rails work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

An older Rails major version to current

• Why teams do it: Security support and gem compatibility.
• What to watch: One major at a time with the test suite running between each. Gem compatibility is the usual blocker, so inventory dependencies before committing to a timeline.

jQuery and server-rendered views to Hotwire

• Why teams do it: Modern interactivity without adopting a separate front-end application.
• What to watch: Incremental by design; convert page by page. It is a genuine change in how state and requests work rather than a templating swap, so start with a few low-risk pages.

Fat models to extracted service objects

• Why teams do it: Testability and the ability to change one behaviour without risking others.
• What to watch: Only safe with tests in place. Write characterisation tests around the behaviour first, then extract, and do it one responsibility at a time.

A Rails monolith to extracted services

• Why teams do it: Independent deployment or team ownership, usually organisational rather than technical.
• What to watch: Rails monoliths are frequently better left whole than most people assume. Where extraction is genuinely needed, the database is the hard part, as always.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Rails developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which Rails and Ruby versions the application runs, and how far behind current that is.
• How old the application is, since most Rails work involves years of accumulated history.
• What the front-end approach is: server-rendered, Hotwire, or a separate application.
• What the test coverage is genuinely like, because it determines whether refactoring is safe.
• Whether background job processing is in use and who is responsible when jobs fail.
• Whether the work is new development, an upgrade, or architectural refactoring.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Ruby on Rails work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Rails developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Rails developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Ruby on Rails frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

A smaller hiring pool than a decade ago. Real, and partly offset by the remaining pool being experienced. Expect to pay for seniority rather than find juniors.

No experience of large mature codebases. Most Rails work is on applications with years of history. Ask how they approach a large model class.

No SQL depth. Active Record hides the database thoroughly. Ask what SQL a given query produces.

Applications far behind on version. Establish the current version before hiring, since an unsupported application changes the job.

Hiring Ruby on Rails developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Rails developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Is Rails still a reasonable choice in 2026?

For building a data-backed web product quickly, yes, and it remains one of the fastest options available. Its conventions mean a small team produces a great deal, and the ecosystem covers most conventional requirements. The considerations against it are the hiring pool size and the fact that it is less fashionable, neither of which is a technical argument.

Can Rails scale?

Technically, further than its reputation suggests, and several very large products demonstrate it. What struggles sooner is the codebase, because Rails has no strong opinion about where business logic goes once models and controllers are insufficient. Applications that address that deliberately age well; applications that do not accumulate very large model classes.

Is the Rails hiring pool a problem?

It is smaller than it was and it skews experienced, because few developers start with Rails now. In practice that means you will find capable senior people and very few juniors. Budget for seniority, and expect strong candidates to have been doing this for a decade.

Why is our Rails application slow?

Almost certainly N plus one queries, which Rails makes unusually easy to write accidentally. A page can issue several hundred queries while the code looks clean. Enabling detection tooling in development prevents the entire class of problem from recurring, and it is not enabled in most applications we see.

Should we use Hotwire or a separate front end?

Hotwire when the team is Rails-first and the interactivity is moderate, which covers a lot of applications; it avoids a second codebase entirely and is the framework's own direction. A separate front end when the interface is genuinely application-like or when you have dedicated front-end engineers. Choosing the latter by default is a common way to double the work.

How hard are Rails upgrades?

Manageable between adjacent majors if the test suite is real, since Rails deprecates clearly and documents upgrades well. The blocker is nearly always gem compatibility rather than Rails itself. Applications several versions behind with thin test coverage are a genuine project, and that combination is common.

Should we rewrite our old Rails application?

Usually not. Rewrites of revenue-generating systems have a poor record, because the existing behaviour is never fully documented and must be reproduced exactly. Upgrading, adding tests around what you are changing, and extracting logic incrementally is slower to feel satisfying and much more likely to succeed.

Ruby or Python for a new web application?

Rails is more opinionated and gets you to a conventional web product faster. Python is a broader language with a much stronger data and machine learning ecosystem, which matters if the product will involve either. If the application is straightforward web work, Rails is usually quicker; if data work is in the future, Python has the stronger case.