How to assess · For hiring teams
How to Assess Ruby on Rails Skills When Hiring
The test formats that actually work for Ruby on Rails, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.
The short answer
Assess Ruby on Rails with a task, not a conversation: diagnose a slow, tangled feature, build a feature with tests, ai-scored assessment (e.g. cohesyve) or refactoring conversation. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.
- Reads the SQL ActiveRecord generates and eliminates N+1s with `includes`, `preload` or a query object
- Keeps callbacks minimal and side-effect-free, moving workflow into service objects or jobs
- Structures models by responsibility, extracting concerns and objects before a model becomes a god
- Writes tests that are fast and meaningful, and knows what belongs in a model spec versus a request spec
Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.
Rails makes it easy to build something that works and easy to build something that will not survive growth. The framework's conventions hide a lot, and the developers who understand what is hidden — how ActiveRecord queries the database, what a callback chain does to a save, where a fat model becomes a liability — are the ones who keep a Rails codebase fast and changeable. This page covers how to assess Rails for backend and full-stack roles: ActiveRecord and query performance, application structure, testing, background jobs and the judgement to use conventions without being trapped by them.
Why Ruby on Rails is worth testing
Rails codebases degrade in predictable ways: N+1 queries, callbacks that trigger other callbacks, models with two thousand lines, and tests that take forty minutes. Each is a habit a strong developer avoids and a weak one accumulates. Testing surfaces the difference early, and it matters more in Rails than in most frameworks because the conventions make bad habits look normal until the app is slow.
What strong Ruby on Rails looks like
- Reads the SQL ActiveRecord generates and eliminates N+1s with `includes`, `preload` or a query object
- Keeps callbacks minimal and side-effect-free, moving workflow into service objects or jobs
- Structures models by responsibility, extracting concerns and objects before a model becomes a god
- Writes tests that are fast and meaningful, and knows what belongs in a model spec versus a request spec
- Uses background jobs for anything slow or unreliable, with idempotency and retries considered
- Understands the request lifecycle well enough to debug middleware, sessions and caching
- Knows when a Rails convention should be broken and can justify it
Ways to assess Ruby on Rails
Diagnose a slow, tangled feature
Provide a small Rails app with an N+1 in a view, a callback chain that sends email on every save, and a controller doing work that belongs in a job. Ask the candidate to fix and explain.
Pros
Cons
Best for Mid and senior Rails developers.
Build a feature with tests
Ask for a small feature — an invitation flow, an export — with request specs and a background job, in a capped take-home.
Pros
Cons
Best for Full-stack and product engineers.
AI-scored assessment (e.g. Cohesyve)
Generate a Rails task from the job description — a query review, a refactor plan, a job design — with a rubric. Each candidate receives a different variant; reasoning is scored with the code.
Pros
Cons
Best for Screening before pairing sessions.
Refactoring conversation
Show a 600-line model and ask how they would break it up, in what order, and what would go wrong along the way.
Pros
Cons
Best for Senior developers inheriting legacy apps.
Cohesyve
Run a Ruby on Rails assessment on your next opening
Cohesyve generates a unique Ruby on Rails task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.
What to test
ActiveRecord and performance
Whether they know what the database is being asked.
Application structure
Whether the code has a shape beyond MVC.
Testing
Whether tests are fast and worth running.
Jobs and reliability
Whether slow and unreliable work is handled safely.
Sample Ruby on Rails questions
What is an N+1 query and how do you find one in a Rails app?
EntryLook for A query per row; find with logs or a gem like Bullet; fix with `includes`.
When should logic live in a model callback, and when should it not?
EntryLook for Data integrity close to the model; anything with side effects, external calls or workflow belongs elsewhere.
A controller action takes four seconds because it generates a PDF. What do you change?
MidLook for Background job, a status for the user, idempotency, and where the file is stored.
How would you split a model that has grown to a thousand lines?
MidLook for Identify responsibilities, extract objects incrementally, keep tests green, avoid concerns as a dumping ground.
Your test suite takes thirty minutes. Where do you start?
SeniorLook for Profile, find slow specs, reduce database setup, move to fakes for external services, parallelise; keep the meaningful ones.
Red flags
- Has never looked at the SQL a page generates
- Puts external API calls in callbacks
- Cannot explain why a test suite is slow
- Treats "the Rails way" as an answer to every design question
- Has not designed a background job for failure
Scoring rubric
| Criterion | Weight | What strong looks like |
|---|---|---|
| Query awareness | 30% | Knows what the database sees and keeps it efficient. |
| Structure | 25% | Responsibilities are separated; callbacks are minimal. |
| Testing | 20% | Fast, meaningful, at the right layer. |
| Jobs and reliability | 15% | Slow work is asynchronous, idempotent and retried. |
| Judgement | 10% | Uses conventions deliberately and can explain departures. |
Mistakes hiring teams make
- Testing Ruby syntax rather than Rails judgement
- Not including a query-performance task — the most common real problem
- Accepting a feature with no tests because it works in the browser
- Ignoring background jobs entirely
- Hiring on years of Rails without checking for the habits that degrade apps
Roles that need Ruby on Rails
Common questions
Should I test Ruby separately from Rails?
Lightly. Ruby fluency shows in any Rails task. The failure modes that matter — queries, structure, jobs — are Rails-specific, so spend the time there.
What is the quickest Rails screening question?
Show a view with an N+1 and ask what the database does. It takes five minutes and separates people who understand ActiveRecord from people who use it.
How do I assess a senior Rails developer?
Give them a legacy problem — a god model, a slow suite — and ask for a plan. Seniors think incrementally and can say what would break along the way.
Does Rails experience transfer from other frameworks?
The web fundamentals do. ActiveRecord habits and Rails conventions do not, and they are where new Rails developers create the most trouble. Test them specifically.
Cohesyve · Skill assessments for hiring
Test Ruby on Rails before the first interview
Generate a role-specific Ruby on Rails assessment from your job description and see who can do the work before you spend interview time on them.
1,500+
assessments completed
50%
faster time-to-hire
90%
completion rate
5 min
from JD to assessment
No credit card · 10 free candidates · Plans sized to your hiring volume
From the blog