JT Book a call

Blog

How to Hire Ruby Developers for Your Next Project

Published

6 min read

How to Hire Ruby Developers for Your Next Project
In this post

A Ruby developer who interviews well and a Ruby developer who can fix your production app are not always the same person. The gap shows up when you hand them a real bug, so that is where this guide spends most of its time.

Ruby, Rails, and what to put in the job ad #

Ruby is the language. Rails is the framework most Ruby jobs are actually about, and it organizes code as Model-View-Controller: models manage the data, views render responses, controllers handle requests (Rails Getting Started guide). When you say “Ruby developer” in an ad, you almost always mean “Rails developer”, so say so.

Then name the things that decide whether a candidate can start on Monday:

  • Versions. As of 30 October 2026 the current Rails release is 8.1.4 (rubyonrails.org) and Ruby 4.0.9 is a stable release (ruby-lang.org). If your app runs something older, say which version. “Upgrade experience” is a skill worth asking about.
  • What the product does and who uses it. A developer who has built billing code reads a billing codebase faster.
  • How you test. Minitest or RSpec, and whether there are tests at all. Candidates will ask, and a missing answer is itself an answer.
  • Who reviews their work. If nobody on your side can, say that too and say what you plan to do about it.

Where to look #

Ruby meetups and conference hallways, the contributor lists of gems you already depend on, freelance marketplaces for short jobs, and agencies if you want a team rather than a person. Each has a different failure mode. Marketplaces give you the most profiles and the least context. Contributor lists show you who can read other people’s code, at the cost of finding out whether they are available at all. An agency gives you a replacement if someone leaves, at an agency’s margin.

Test with a real bug, not a puzzle #

A whiteboard puzzle measures puzzle practice. Give the candidate 30 minutes with a small Rails problem they will meet in your app, and watch how they read, run and change code. The research on hiring backs a structured approach: in a 2022 re-analysis of selection studies, structured interviews ranked first among the methods compared (Sackett et al., 2022). Same exercise, same scoring sheet, every candidate.

Here is one we ran in a scratch directory to check it works (Ruby 4.0.6, ActiveRecord 8.1.4, Minitest 6.0.6, SQLite in memory). It is the most common Rails performance bug, an N+1 query. The page lists posts with their author names, and the slow version fetches each author separately. The test counts SQL queries with ActiveSupport::Notifications and pins the budget: one query for the posts plus one per post for the slow page, two queries total for the fast one. Save it as one file and run ruby n1.rb:

require "active_record"
require "minitest/autorun"

ActiveRecord::Base.establish_connection(adapter: "sqlite3", database: ":memory:")
ActiveRecord::Schema.verbose = false
ActiveRecord::Schema.define do
  create_table(:authors) { |t| t.string :name }
  create_table(:posts)   { |t| t.references :author; t.string :title }
end

class Author < ActiveRecord::Base; has_many :posts; end
class Post < ActiveRecord::Base; belongs_to :author; end

3.times { |i| a = Author.create!(name: "Author #{i}"); 2.times { |j| a.posts.create!(title: "Post #{i}.#{j}") } }

def count_queries
  n = 0
  cb = ->(*, payload) { n += 1 unless payload[:name] == "SCHEMA" }
  ActiveSupport::Notifications.subscribed(cb, "sql.active_record") { yield }
  n
end

def page_slow = Post.all.map { |p| "#{p.title} by #{p.author.name}" }
def page_fast = Post.includes(:author).map { |p| "#{p.title} by #{p.author.name}" }

class QueryBudgetTest < Minitest::Test
  def test_slow_page_issues_n_plus_one_queries
    assert_equal 1 + Post.count, count_queries { page_slow }
  end

  def test_fast_page_issues_two_queries
    assert_equal 2, count_queries { page_fast }
    assert_equal page_slow.sort, page_fast.sort
  end
end

Running the file extracted from this post:

2 runs, 3 assertions, 0 failures, 0 errors, 0 skips

Hand the candidate the slow version and a failing “two queries” test. Finding includes is the easy part. Listen for what comes next: whether they ask how many rows production has, whether they check the second assertion still holds, whether they mention that includes can load more than you need. A candidate who rewrites the loop by hand, or cannot say why the count matters, has told you something too. If you cannot judge the answer yourself, ask a senior Rails engineer to sit in for the session.

For references, ask what the person shipped and who reviewed it. A reference who can only say “great to work with” has told you nothing about the code.

What to pay #

Do not rely on a rate someone quoted on a forum. The U.S. Bureau of Labor Statistics reports a May 2025 median annual wage of $135,980 for software developers, with the lowest 10 percent under $82,460 and the highest 10 percent over $214,670 (BLS Occupational Outlook Handbook). That covers all languages and all U.S. locations, not Ruby specifically, and it excludes equity. Treat it as the shape of the range. For a contractor or an agency, get at least three written quotes for the same exercise and compare them.

A salary is also not the whole cost. BLS puts benefits at 30.0 percent of employer compensation costs for private-industry workers in June 2026 (Employer Costs for Employee Compensation), so the loaded cost of a hire sits well above the number in the offer letter.

Three mistakes that cost founders months #

  • Hiring for the language, not the product. Ruby skill is the floor. Experience with your problem (payments, multi-tenancy, a legacy upgrade) is what shortens the first quarter.
  • Skipping the work sample because the résumé is strong. A résumé lists what someone worked on, not what they did to it. The exercise shows what they do to your code.
  • Hiring the cheapest candidate with no reviewer. The invoice arrives later, as a rewrite. Our post on why cheap developers get expensive without a technical review goes through how that happens.

If you would rather add a vetted Rails team than run a hiring process, see how we work. JetThoughts is rated 4.8/5 on Clutch.

If you are weighing platforms, see Why Hiring Senior Developers on Freelance Platforms Fails. For the contract side, What SLAs to Require From Your Dev Shop lists what to require from a dev shop.

Sources #

Read next

Tell us what you need built

JetThoughts has been building software since 2008. Book a call, or write to sales@jetthoughts.com. You'll leave the call with a written one-page scope within 2 working days.

#01 Paul Keen
Paul KeenFounder & Open Source Contributor

A 30-minute call; pick a time.