How to Hire the Best Ruby on Rails Developers in 2026

Most companies post a generic Rails job, interview the wrong people, and spend months debugging slow queries the new hire can't diagnose. We've seen this pattern across 150+ Rails hires and 1,500+ interviews.

This guide covers the whole process, from how to define the role, what to test, what to pay, where to find good candidates, to how to spot a real Rails developer versus someone who used the framework once on a side project. Let's get started.

TL;DR: What You Need to Know Before You Start Hiring

• Rails developers split into distinct specializations - Full-stack (Hotwire + Turbo + Stimulus) and API-only (JSON endpoints for React/mobile) are different jobs with different skill sets. Specify which you need before posting.
  
• ActiveRecord mastery is the non-negotiable filter - Every production feature touches it. Test query optimization, N+1 prevention, eager loading, scopes, and transactions. Developers without this depth ship slow apps and fight the framework.
  
• Rails 7.1+ is the 2026 floor - Rails 8 changed infrastructure defaults with Solid Queue, Solid Cache, and Kamal. Pre-Rails 7 experience means the candidate missed the Hotwire-first era entirely.
  
• Hotwire vs API-only determines what your developer ships daily - Hotwire developers build rich UI through Rails. API developers ship JSON. Hiring the wrong type wastes months.
  
• Remote works better for Rails than almost any other stack - The community has been async-native and remote-first for over a decade. Eastern Europe and Latin America offer senior talent at 40-60% of US rates with no quality gap.
  
• Test Rails patterns, not algorithms - Your technical assessment must include ActiveRecord with realistic data volumes, a background job, and either a Hotwire interaction or API endpoint depending on the role. Under two hours. No generic coding puzzles.
  

Ready to skip the hiring headaches? Book a free consultation with Remote Crew and get your first qualified Rails candidates within 48 hours.

Full-Stack Rails vs Rails API: The Decision You Must Make Before Posting

Most bad Rails hires happen because teams skip this decision. They post a generic "Rails developer" role and attract candidates with incompatible skill sets. Full-stack Rails developers build monoliths with Hotwire. API Rails developers ship JSON endpoints. These are different day-to-day jobs, and hiring the wrong one costs you months.

Make this call before you write a single line of the job description.

Full-Stack Rails Developer (Hotwire Monolith)

This is the most common Rails role. The developer builds traditional Rails applications with views, controllers, models, and modern frontend through Hotwire.

Their day-to-day looks like this: writing ERB templates with ViewComponent, building Turbo Frame interactions that make pages feel like SPAs without JavaScript frameworks, wiring up Stimulus controllers for lightweight client-side behavior, designing ActiveRecord models with clean associations, writing RSpec tests, and shipping background jobs with Sidekiq or Solid Queue.

This role is right for SaaS products, internal tools, e-commerce platforms, marketplaces - anything where the UI should live inside Rails and the developer should own the full vertical slice from database to browser.

Example job title and opening line: "Full-Stack Rails Developer (Rails 7.1 + Hotwire) - Build B2B SaaS Billing Platform. You'll ship Hotwire-driven features on our Rails 7.1 monolith serving 15K daily active users, with PostgreSQL and Sidekiq processing 200K jobs/day."

Rails API Developer (Backend Services)

This developer runs Rails in API mode. No views, no Hotwire, no ERB. They ship JSON endpoints consumed by React, Vue, mobile apps, or other services.

Their day-to-day: designing RESTful endpoints, choosing serialization strategies (Alba, Blueprinter, or Jbuilder), implementing authentication and authorization (Pundit, Devise, JWT), handling API versioning, setting up rate limiting, and writing RSpec request specs. They're often paired with a separate frontend team and spend more time thinking about payload shapes and response times than view rendering.

This role is right for mobile app backends, SPA backends where a separate team builds the React or Vue frontend, and microservices in a service-oriented architecture.

Example job title and opening line: "Senior Rails API Developer (Rails 7 API mode) - Mobile App Backend. You'll design and build the API layer for our iOS and Android apps, serving 50K daily active users with sub-200ms response times."

Pro Tip: API-only Rails developers often can't transition to full-stack Hotwire work. The view layer, Turbo Frames and Streams, Stimulus patterns, and ViewComponent architecture are skills that require dedicated practice. If your roadmap might require full-stack work within 12 months, hire full-stack from the start.

Part 1 - What to Do Before You Post the Job

Build Your 1-Page Recruitment Plan

Every successful Rails hire starts with one sentence that describes the actual system being built, the scale, and the framework version. Two examples:

• "Build a Hotwire-driven SaaS billing platform on Rails 7.1 with Sidekiq processing 200K background jobs/day"
  
• "Build a Rails API backend for our React mobile app with 50K daily active users"
  

Not "need a Rails developer." That sentence tells you nothing and attracts everyone.

From there, separate your requirements into two clean lists:

Must-haves: Ruby 3.2+, Rails 7.1+, specialization (Full-Stack OR API - pick one), ActiveRecord mastery, PostgreSQL or MySQL, background jobs (Sidekiq or Solid Queue), testing (RSpec or Minitest), Git, Docker.

Nice-to-haves: Hotwire experience, ViewComponent or Phlex, Kamal for deployment, Sidekiq Pro, AWS/GCP, Redis tuning, Rails upgrade experience.

One more thing to nail down: why would a strong Rails developer choose your team? Rails developers value modern Rails versions, well-tested codebases, room for refactoring, the chance to use Hotwire on real products, and teams that respect conventions instead of fighting them. If your codebase is on Rails 5 with no upgrade plan, say so - the right candidates will appreciate the honesty, and the wrong ones will self-select out.

Download our free 1-page recruitment plan template to structure your requirements before posting.

Understanding Seniority Levels

Rails seniority is not the same as years-of-Ruby seniority. A developer with five years of Sinatra and pure Ruby is not a senior Rails developer. Here's what each level actually looks like in Rails-specific terms:

Warning: Test ActiveRecord and Rails conventions specifically during your hiring process. "Five years of Ruby experience" on a resume tells you nothing about whether someone can prevent N+1 queries or design a clean has_many :through association.

Rails Developer Salary Ranges in 2026

Rails developers command solid rates for three reasons: the senior pool is smaller than JavaScript or Python, the framework is dense enough that a strong Rails developer replaces two or three average ones on a monolith, and most Rails apps are revenue-generating production systems where mistakes cost real money.

The average Ruby Rails developer salary in the United States as of April 2026 is $122,113 per year, according to ZipRecruiter data. The average senior Ruby on Rails developer salary is $157,724 a year, with the majority of senior salaries ranging between $142,500 (25th percentile) to $175,500 (75th percentile) and top earners making $192,000 annually.

Specialization affects rates significantly:

• Senior full-stack with Hotwire and performance experience commands a 10-15% premium over general backend roles
  
• Proven scaling experience (apps with millions of users, complex sharding, large Sidekiq workloads) commands a 15-25% premium

Remote hiring is where the math gets interesting. Eastern Europe and Latin America have strong Rails communities, and you can hire senior developers there at 40-60% of US rates without a quality gap. The Rails community has been remote-first since 37signals wrote Remote in 2013, so Rails developers already know how to work async, document well, and collaborate over pull requests. Sourcing only locally means paying more for a smaller pool.

If you need help with hiring remote Ruby on Rails developers from Europe or Latin America, book a free strategy call to see how we would approach it and deliver you high-quality candidates in under 48 hours.

How to Write a Job Description for Ruby on Rails Developers That Actually Delivers High-Quality Candidates

Your job title and opening line should do half the filtering before anyone clicks "Apply."

Good: "Full-Stack Rails Developer (Rails 7.1 + Hotwire) - Build B2B SaaS Billing Platform"

Bad: "Rails Developer"

The bad version attracts full-stack engineers, API-only developers, Ruby generalists, and DevOps engineers who once touched a Capistrano script. Different specializations, different skills, one pile of unqualified applications.

Lead with Rails-specific impact: "Ship Hotwire features that reduce page load times by 40% and replace our legacy jQuery code." Not generic output metrics that could apply to any web framework.

Structure the posting itself with clear sections:

• Must-haves: Ruby 3.2+, Rails 7.1+, your chosen specialization, ActiveRecord depth, PostgreSQL or MySQL, background jobs, strong testing habits, Git, Docker
  
• Nice-to-haves: Hotwire, ViewComponent, Kamal, AWS/GCP, Sidekiq Pro, GraphQL, Rails upgrade experience, performance profiling
  
• What you'll build: Describe the actual product and technical challenges
  
• Salary range: $X-$Y. Include it. Always.
  

The fatal mistake is not specifying Full-Stack vs API-only, and not testing ActiveRecord beyond basic CRUD. Both of these cause the exact same outcome - you hire someone who can write Ruby but can't ship Rails features at the level your product requires.

Part 2 - How to Find and Evaluate Ruby on Rails Developers

Sourcing Rails Developers on LinkedIn and GitHub

The concentric circles method works well for Ruby on Rails sourcing. Start narrow and expand outward only when the pipeline is thin.

Start narrow on LinkedIn:

• Title filters: "Ruby on Rails Developer" OR "Rails Engineer" OR "Senior Ruby Developer"
  
• Skill filters: ActiveRecord, Hotwire, Turbo, Stimulus, RSpec, Sidekiq, PostgreSQL
  
• Recency signal: Rails 7+ mentioned in current or recent job descriptions
  
• Layer in: Seniority level + location or remote-friendly regions
  

Expand progressively if needed:

• Accept any modern Rails version (6.1+)
  
• Widen experience range by one level
  
• Expand geography to remote-friendly regions (Eastern Europe, Latin America, Portugal)
  

Target companies for sourcing: Shopify, GitHub, Basecamp, GitLab, Procore, Zendesk, Hey, Doximity. Any YC startup founded pre-2018 is a strong signal for Rails-heavy codebases and experienced Rails developers.

Check beyond LinkedIn. GitHub is a strong signal source: look for Rails contributions, gem maintenance, and Rails-related repositories. Published gems on RubyGems.org are even better. Conference talks at RailsConf, RubyKaigi, and Rocky Mountain Ruby indicate community engagement. Ruby Weekly contributors and dev.to Rails writers are often senior developers with strong communication skills.

Ruby on Rails outreach hiring message that works:

Hi [Name], saw your work on [specific gem/project/talk] and noticed you've been doing Rails for [X] years. We're building a [Hotwire-first SaaS / Rails API for mobile] on Rails 7.1, looking for a senior developer who actually likes Rails conventions instead of fighting them. Salary is [$X-$Y], fully remote. Open to a quick chat?

Three things make this outreach effective:

1. it references something specific the candidate built,
2. it names the Rails version and specialization,
3. it states the salary upfront.
   

Generic "exciting opportunity" messages get deleted.

Eight Interview Questions That Separate Strong Ruby on Rails Candidates from Weak Ones

Most interview processes test generic Ruby or algorithms. The questions below test Rails-specific patterns that show up on day one of production work.

1. "Walk me through how you prevent N+1 queries in Rails. Show me three different approaches."

Strong answer mentions includes, preload, eager_load, the bullet gem for detection, and explains when each approach is appropriate. They should know that includes delegates to preload or eager_load depending on query conditions.

2. "Explain the difference between includes, preload, and eager_load. When would you use each?"

This tests ActiveRecord depth beyond surface knowledge. Most mid-level candidates only know includes. A strong candidate explains that preload uses separate queries, eager_load uses a LEFT OUTER JOIN, and includes chooses between them.

3. "How would you structure business logic in a Rails app as it grows? When do you reach for service objects, concerns, or POROs?"

Tests architectural thinking and opinion on Rails conventions. Look for nuance - not "always use service objects" or "never use concerns," but context-dependent reasoning.

4. "Walk me through how you would design [specific feature from your domain] in Rails. What tables, associations, and routes?"

Tests practical Rails design. Use a feature relevant to your actual product. Watch how they think about the data model first and the controller logic second.

5. "How do you handle background jobs in Rails? When would you use Sidekiq versus Solid Queue versus ActiveJob alone?"

Tests background processing knowledge and awareness of the Rails 8 infrastructure shift. A strong candidate knows Sidekiq's Redis dependency and throughput advantages versus Solid Queue's database-backed simplicity.

6. "Explain Turbo Frames and Turbo Streams. When would you use each?" (Full-stack roles only)

Tests Hotwire knowledge. Should explain that Turbo Frames scope page updates to a specific area while Turbo Streams can update multiple parts of the page and work over WebSockets. Skip this for API-only roles.

7. "How do you test Rails code? Walk me through your approach to unit, integration, and system tests."

Tests testing maturity. Look for clear separation between model tests, request/controller tests, and system tests with Capybara. A strong candidate has opinions about what to test at each level.

8. "How would you approach upgrading a Rails 5.2 app to Rails 7.1? What are the main risks?"

Tests senior-level practical experience. Should mention the dual boot strategy, running deprecation warnings first, updating one minor version at a time, the Hotwire/Webpacker transition, and specific breaking changes in the ActiveRecord layer.

Green Flags and Red Flags in Ruby on Rails Candidates

This table covers the skill areas that matter most when you hire Ruby on Rails developers. Use it during interviews and technical assessments.

Candidates showing seven or more green flags from this table pass probation at a 95%+ rate in our experience. Fewer than four green flags is a strong signal to pass.

Technical Tests That Reveal Real Ruby on Rails Ability

The test must stay under two hours. It must include ActiveRecord and a real Rails feature. No generic algorithm questions - those tell you nothing about how someone will perform in a Rails codebase.

Take-home test spec:

Give candidates a starter Rails 7.1 app (not a blank slate) with a domain model that has at least three associated tables. Include:

• One feature that requires query optimization - Provide seed data with enough rows that N+1 queries are visibly painful. 5 records won't surface the problem. Give them 10,000.
  
• A background job using Sidekiq or ActiveJob
  
• Tests with RSpec or Minitest
  
• For full-stack roles: A Hotwire interaction (Turbo Frame or Turbo Stream)
  
• For API roles: A versioned JSON endpoint with serialization
  

Evaluate on:

• ActiveRecord usage (eager loading present, scopes used, zero N+1s)
  
• Rails conventions (proper MVC, no business logic in views)
  
• Testing quality (meaningful tests, not just coverage percentages)
  
• Code organization (service objects where useful, not sprinkled everywhere)
  
• Error handling and edge cases
  
• Hotwire or API design quality depending on the role
  

Alternative test formats if a take-home doesn't fit your process:

• Optimize a slow query - Give them code with N+1s and missing indexes, ask them to fix and explain
  
• Refactor a fat controller into service objects
  
• Add a Turbo Stream feature to existing code
  
• Live coding (45-60 minutes) - Pair on a Rails feature, watching how they navigate the codebase, write ActiveRecord queries, run tests, and debug
  

Non-negotiable rules for any test format: Always provide a starter app. Always test ActiveRecord beyond basic CRUD. Always use realistic data volumes - N+1 queries don't surface on 5 records. Allow candidates to use documentation, run tests, and search online. Real work is not memorization.

For senior roles, include at least one question about scaling or upgrading. A senior Rails developer should be able to talk about read replicas, database indexing strategy, or how they'd approach a major version upgrade.

Ruby on Rails Developer Skills Checklist

Here's the complete list of skills to evaluate when you hire Ruby on Rails developers, organized by priority.

Must-have skills (Rails Developer):

• Ruby 3.2+ language proficiency
  
• Rails 7.1+ framework expertise
  
• ActiveRecord mastery (associations, scopes, eager loading, transactions, callbacks)
  
• N+1 query prevention - the Rails developer's daily skill
  
• MVC pattern and Rails conventions
  
• REST API design OR Hotwire/Turbo (specify which for your role)
  
• Background jobs (Sidekiq, Solid Queue, or ActiveJob)
  
• Testing (RSpec or Minitest, including system tests)
  
• PostgreSQL or MySQL
  
• Bundler and gem ecosystem navigation
  
• Git
  
• Docker basics
  

Nice-to-have skills:

• Hotwire (Turbo Frames, Turbo Streams, Stimulus)
  
• ViewComponent or Phlex
  
• Kamal for deployment
  
• Sidekiq Pro features (batches, unique jobs)
  
• Cloud platforms (AWS, GCP, Heroku, Fly.io, Render)
  
• Rails upgrade experience (crossing major versions)
  
• Performance profiling (rack-mini-profiler, Scout, Skylight)
  
• GraphQL with Rails
  
• ActionCable for real-time features
  

Soft skills critical for remote Rails work:

• Clear async communication - Especially in pull request descriptions that explain the why, not just the what
  
• Strong opinions on Rails conventions, weakly held - They should have a take on service objects vs concerns, but update it when they see evidence
  
• Self-direction in debugging - Can diagnose slow queries and production issues without someone assigning the investigation
  
• Documentation habits - Writes comments and README sections for non-obvious business logic, not just for obvious code
  
• Pragmatism over perfectionism - Rails rewards shipping. The developer who refactors forever instead of deploying is a bad fit for most Rails teams.
  

Common Ruby on Rails Hiring Mistakes and How to Avoid Them

Every mistake below costs time and money. We've seen each one multiple times across 150+ hires.

• Posting "Rails developer" without specifying Full-Stack vs API-only - You attract both types, plus everyone in between, and waste two weeks of screening on candidates who can't do the actual job.
  
• Not testing ActiveRecord depth beyond basic CRUD - The candidate writes clean Ruby but ships N+1 queries on their first feature. Your app slows down, and you blame Rails instead of your hiring process.
  
• Treating Rails like any other web framework - Rails conventions matter more than in Express or Django. A developer who fights conventions will write code that's harder for the next developer to maintain.
  
• Not specifying Rails version - A Rails 5 developer doesn't know Hotwire, doesn't know Turbo, and has never seen Solid Queue. That's not a small gap.
  
• Testing generic algorithms instead of Rails-specific patterns - Knowing how to reverse a linked list tells you nothing about whether someone can design an ActiveRecord association or prevent an N+1.
  
• Hiring a Ruby generalist when you need Rails depth - Ruby and Rails overlap but they're not the same skill set. ActiveRecord, conventions, and the view layer are framework-specific knowledge.
  
• Expecting an API-only developer to ship full-stack Hotwire features - These are different specializations. You wouldn't hire a backend Python developer and expect them to build React components.
  
• Skipping technical tests for senior candidates - Years of experience does not equal Rails depth. Some "senior" developers have spent five years on one app without ever optimizing a query.
  
• Using 5-record seed data in tests - N+1 queries only surface at realistic data volumes. Give candidates 10,000 records and watch what happens.
  
• Waiting for inbound applications instead of sourcing actively - The best Rails developers are employed and not browsing job boards. You need to go find them.
  

One more for 2026 specifically: candidates comfortable only with Rails 5 or 6 infrastructure patterns - Redis-only background jobs, no awareness of the Solid Stack, no Kamal familiarity - are already behind the current standard. New Rails apps now default to Solid Queue for background jobs, Solid Cache for caching, Solid Cable for web sockets, Propshaft for the asset pipeline, and Kamal 2 for deployments. Your candidates should at least know what these are.

On-Site vs Remote: Where to Hire Rails Developers

Here's the comparison that matters when deciding how to hire Ruby on Rails developers for your team:

Remote works exceptionally well for Rails. The community has been async-native and remote-first since before most frameworks adopted it. Rails itself was built by a distributed team, and the conventions-heavy nature of the framework makes remote collaboration easier - when everyone follows the Rails Way, there's less to argue about in code review.

The strongest hiring regions for remote Rails developers:

• Eastern Europe (Serbia, Poland, Ukraine, Romania) - Deep Rails communities, strong English skills, European time zone overlap
  
• Latin America (Brazil, Argentina, Mexico) - Growing Rails communities, US time zone overlap, strong cultural alignment
  
• Portugal - Excellent for Western European time zone needs, strong developer ecosystem, competitive rates
  

These regions offer senior Rails talent at 40-60% of US rates. Remote Crew's network spans these regions with pre-vetted Rails developers who've already been screened for the specialization and ActiveRecord depth that matters.

Ruby on Rails Developer Hiring Checklist

Print this. Use it for every Rails hire.

Before posting:

• Defined Full-Stack vs API specialization
  
• Specified Rails 7.1+ and Ruby 3.2+
  
• Listed must-haves and nice-to-haves separately
  
• Salary range agreed and ready to publish
  
• Written job description with Rails-specific impact (not generic)
  

During hiring:

• Sourcing actively on LinkedIn and GitHub (not waiting for inbound)
  
• Screening for ActiveRecord depth in first interview
  
• Technical test includes N+1 prevention with realistic data volumes
  
• Live coding or pairing session scheduled
  
• Reference check focused on Rails-specific work
  
• Senior candidates asked architectural and scaling questions
  

After offer:

• Onboarding plan covers first 30 days
  
• First-week task touches ActiveRecord and the actual codebase
  
• Pairing time scheduled with existing senior engineer
  
• Probation criteria defined and shared upfront
  

Let Remote Crew Find Your Next Best Ruby on Rails Developers

We specialize in Rails developers across both specializations, and our screening process is built specifically for the framework.

Rails-specific screening includes:

• Distinguishing full-stack Rails from API-only developers at the sourcing stage
  
• Testing ActiveRecord mastery as the baseline filter - not generic Ruby
  
• Verifying Rails 7+ and Hotwire experience for full-stack roles
  
• Assessing API design depth for backend roles
  
• Evaluating Rails convention knowledge and pragmatism
  

The numbers:

• 99% probation pass rate - Developers approved 99% of the time
  
• 90%+ first-screening pass - Candidates who reach your desk are already qualified
  
• 50%+ higher offer acceptance - Because we match expectations before the first call
  
• First candidates in 48 hours - Not weeks
  
• No payment until you hire - We start working without upfront fees
  

We have strong Rails talent networks in Eastern Europe and Latin America, where senior developers deliver at 40-60% of US rates.

Book a free consultation to discuss your specific Rails role - full-stack or API, Hotwire or SPA backend, scaling experience or greenfield - and get matched with vetted candidates in 48 hours.

The Bottom Line

Hiring Rails developers well comes down to three decisions you make before you ever talk to a candidate: specifying Full-Stack vs API-only, requiring ActiveRecord depth as a non-negotiable filter, and testing for Rails-specific patterns instead of generic coding skills.

The companies that get this right hire faster, onboard smoother, and keep developers longer. The ones that skip this process post "Rails developer," interview 20 people, hire someone who writes Ruby but fights the framework, and start over six months later.

Rails in 2026 is a mature, powerful framework with a clear modern stack. Your hiring process should match that maturity. Define the role precisely, test what matters, pay the market rate, source actively, and screen for the conventions and ActiveRecord depth that separate Rails developers from Ruby developers who happen to use Rails.

Get started with Remote Crew - your first qualified Rails candidates in 48 hours, no upfront cost.

FAQ

What is the difference between a full-stack Rails developer and a Rails API developer?

Full-stack Rails developers build monoliths where Rails owns the UI through Hotwire, Turbo Frames and Streams, ERB views, and Stimulus controllers. Rails API developers run Rails in API mode and ship JSON endpoints consumed by React, Vue, or mobile apps - no views, no Hotwire, no frontend. These are different day-to-day jobs with different skill sets. Hiring a full-stack developer when you need API-only wastes money on unused skills, and hiring API-only when you need Hotwire means your developer can't ship the frontend features your product requires.

Why does ActiveRecord mastery matter so much when hiring Rails developers?

Every production feature in a Rails app touches ActiveRecord. It handles associations, query building, validations, scopes, transactions, and callbacks. N+1 queries are the single most common Rails performance failure, and they come directly from developers who don't understand eager loading with includes, preload, and eager_load. This skill is what separates a real Rails developer from a Ruby developer who happens to use Rails - and it's the reason we test it as a non-negotiable filter on every hire.

What Rails version should I require when hiring in 2026?

Rails 7.1+ is the current floor for job postings. Rails 7.0 (released 2021) introduced Hotwire as the default frontend approach. Rails 8 (November 2024) brought Solid Cable, Solid Cache, Solid Queue, and Solid Cable as database-backed adapters, along with Kamal 2 for deployment. Pre-Rails 7 experience means the candidate missed the Hotwire-first era entirely. Always specify "Rails 7.1+" or "Rails 8" in your job posting so candidates who stopped learning at Rails 5 self-select out.

How much does it cost to hire a senior Ruby on Rails developer in 2026?

The average senior Ruby on Rails developer in the US earns $157,724 per year, with the 75th percentile clearing $175,500 and top earners reaching $192,000. Western Europe pays €90K-€130K for senior roles. Eastern Europe and Latin America offer the same quality at €60K-€90K or $70K-$110K - that's 40-60% of US rates. Senior full-stack developers with Hotwire and scaling experience command an additional 15-25% premium over these base ranges.

What should a Rails developer technical test include?

Keep it under two hours. Provide a starter Rails 7.1 app with a domain model of at least three associated tables and realistic seed data (10,000+ records, not 5). The test must include ActiveRecord query optimization where N+1s are visible, a background job using Sidekiq or ActiveJob, and either a Hotwire interaction (Turbo Frame or Stream) for full-stack roles or a versioned JSON endpoint for API roles. Evaluate on ActiveRecord usage, Rails convention adherence, testing quality, and code organization. Always let candidates use documentation and run tests - you're testing Rails skill, not memorization.