How to Hire a Ruby on Rails Developer in 2026: What the Role Requires Beyond Framework Knowledge

Rails is having a genuine moment. Not a nostalgia trip — a real one. Rails 8 shipped in November 2024 and meaningfully changed what a production Rails app looks like. The Redis dependency is gone for most apps. Deployment without Heroku is now approachable for teams without a dedicated ops engineer. The JavaScript SPA assumption is less true than ever for standard business applications.

But the hiring market has not fully caught up. Plenty of developers list Rails on a resume and can answer questions about MVC and Active Record while having no idea that Solid Queue exists. The screen that finds genuinely current Rails developers is different from the one that tests general framework knowledge.

Here is what it looks like.

What Rails 8 changed and why it matters for the screen

The biggest shift is infrastructure simplification. Rails 8 introduced three Solid adapters:

Solid Queue replaces Sidekiq + Redis for background jobs. Jobs are stored in your primary database. For most business applications, this is cleaner than running a separate Redis cluster.

Solid Cache replaces Redis-backed caching. Same principle: your existing database handles the cache store.

Solid Cable replaces the Redis ActionCable adapter. WebSocket connections go through the database.

None of this is mandatory, and Sidekiq is still the right tool for very high-volume queues. But a developer who has not heard of Solid Queue is living at least a year behind current Rails, and that gap compounds.

The second major change is deployment. Kamal 2 is DHH’s Docker-based deploy tool that ships as part of a new rails new app. It pushes Docker images to your own servers via SSH and manages zero-downtime deploys without Kubernetes or a PaaS. If the developer’s deployment knowledge stops at Heroku dynos and Capistrano, they need catching up.

The third is the authentication generator. Running rails generate authentication in a Rails 8 app scaffolds a complete, session-based auth system with password reset, remember-me tokens, and a clean directory structure. It is production-appropriate for many applications and removes the most common reason to reach for Devise on a new project.

The screen that separates current knowledge from 2019 knowledge

Ask the developer to describe how they would set up background jobs for a new Rails app today. Listen for:

• Do they mention Solid Queue or ask what Rails version you’re on before answering?
• Do they immediately default to Sidekiq + Redis without considering whether the scale warrants it?
• Can they explain the tradeoff between database-backed queues and a dedicated queue like Sidekiq?

There is no single right answer, but the thinking process tells you a lot. A developer who says “Solid Queue for this, but Sidekiq when job volume is high enough to stress the main database” is reasoning about tradeoffs. A developer who says “just use Sidekiq, that’s what everyone uses” without knowing what Solid Queue is has not read a Rails release note in over a year.

The N+1 screen

This is still the most reliable signal for database-aware Rails thinking. Show them a controller action:

def index
  @posts = Post.all
end

And a view that does:

<% @posts.each do |post| %>
  <%= post.author.name %>
<% end %>

Ask what is wrong. A developer who knows Rails will immediately identify the N+1: one query to load all posts, then one query per post to load the author. They will fix it with Post.includes(:author) and explain that this generates two queries total (or a JOIN if they use eager_load).

Then ask when they would use includes vs eager_load vs preload. This is where you get real signal:

• preload always generates two queries, never a JOIN.
• eager_load always generates a JOIN, which lets you where on the association.
• includes picks the strategy for you, usually preload, but switches to eager_load if you reference the association in a where clause.

A developer who can explain this without hesitation has spent real time debugging slow Active Record queries. One who cannot has probably used includes by habit and never thought about what it does.

Hotwire: the question that reveals their JavaScript philosophy

Ask how they would implement a live search that updates results as the user types, without a full page reload.

In 2026, a strong Rails developer has two good answers:

1. Turbo Frames with a form submission: wrap the results in a <turbo-frame>, point the search form at an endpoint that returns the partial, and Turbo handles the swap. No JavaScript.

2. Turbo Streams via Broadcast: push updates to the client over WebSocket when server state changes. More appropriate for collaborative features where multiple users see each other’s changes.

A developer who immediately reaches for React or Vue for this is not wrong, but it says something about their instincts. The follow-up question is “at what point would you add a JavaScript framework?” The answer should name a threshold: complex client state that cannot be expressed as server-rendered HTML, highly interactive data tables, real-time collaboration, rich drag-and-drop. Not “whenever I want a smoother experience,” because Hotwire with a good loading state handles that.

Questions worth asking

“What’s your deployment setup for a Rails app today, and have you worked with Kamal?”

Not a gotcha if they haven’t, but Kamal knowledge suggests they have tracked Rails’s evolution. The deployment question also reveals whether they have owned infrastructure or always handed it off.

“When would you use a service object instead of putting logic in a model or controller?”

There is no universally right answer here, but a thoughtful one will discuss the trade between Rails conventions (fat model/skinny controller) and the point at which models accumulate unrelated concerns. A developer who says “always use service objects for anything complex” has probably worked on over-engineered Rails codebases. One who says “I put everything in models, that’s the Rails way” has probably never maintained a model with 1000 lines.

“What callbacks on a Rails model would you avoid, and why?”

The common red flag is before_save for business logic that has side effects (sending emails, calling external APIs). after_commit is safer for side effects because it fires after the database transaction commits. A developer who has written an after_save that sent duplicate emails or fired in test rollbacks knows why these callbacks are tricky.

“How would you test a background job?”

Looking for: perform_enqueued_jobs in test mode, or have_enqueued_job matchers. The failure mode is not testing the job at all, or only unit-testing the job class without testing that it gets enqueued.

Red flags

No awareness of Hotwire is a real gap on any project that uses Rails for its HTML-rendering strengths. Defaulting to a full React or Vue SPA for standard business UIs says the developer has not embraced what makes Rails productive.

Defensive about performance (“Rails can be fast if you tune it”) without knowing how to tune it — specifically without being able to explain the N+1 problem or talk about query optimization in Active Record.

Deploying everything to Heroku and never thinking about cost or infrastructure is fine for small projects but signals limited ops experience. If the role involves any infrastructure ownership, probe here.

Green flags

Knows that the Rails 8 authentication generator is appropriate for most new greenfield apps. Has shipped a project using Turbo Streams. Has an opinion on when to use a gem versus building it in-house (Devise vs the generator, Pundit vs a simple concern). Has debugged a slow Rails app with Bullet or rack-mini-profiler and can describe what they found.

For roles where the developer will work on an existing codebase, also ask about their approach to upgrading Rails versions — specifically, how they would approach going from Rails 7 to Rails 8 and what they would check first.

The hiring guides for Python developers and full-stack developers cover overlapping backend concerns from different angles. If you are staffing a Rails project and want help structuring the vetting, tell us about the role.