Ruby on Rails developer interview questions you need to know

Ask a Ruby on Rails developer three kinds of question: what they know about Rails conventions, what they have actually shipped and maintained, and how they behave when something breaks in production. The strongest signal is a short work sample plus a structured interview where every candidate answers the same questions in the same order. Resume review and an unstructured chat predict very little.

That is the whole method. The rest of this page is the question bank, what a good answer sounds like, and where each question belongs in the process. Before the first call, get the Ruby on Rails developer job description settled so candidates and interviewers are measuring the same role.

TL;DR

• Structured interviews are the single best-validated selection method at .42, ahead of job knowledge tests at .40, work samples at .33 and cognitive ability at .31. Ask every candidate the same questions and score them the same way.
• Test Rails as it is now, not as it was in 2019. Rails 8 moved job queues, caching and WebSockets into the database with Solid Queue, Solid Cache and Solid Cable, and shipped an authentication generator. A candidate who only knows the Redis-and-Sidekiq era is not disqualified, but the gap is worth probing.
• Split the bank into general Rails knowledge, code-based work samples, and seniority questions about scale and incidents. Each group answers a different question about the candidate.
• Ask how the candidate uses AI tools. Pretending they do not is the fastest way to hire someone who cannot explain their own code.
• Run the work sample before the interview, not after. It is cheaper, it is fairer, and it gives the interviewer something concrete to dig into.

How should Rails developer interviews be run?

Run them in a fixed order: a short screen, then a scored work sample, then a structured interview built from the same question list for every candidate. Score each answer against a rubric written before anyone applied. This order is deliberate. It puts the cheapest, most predictive evidence first and saves interviewer hours for the candidates who have already shown they can write Rails.

The order matters more than most teams think. Analysis of decades of selection research by Sackett and colleagues, summarised by the Society for Industrial and Organizational Psychology, puts structured interviews at .42, job knowledge tests at .40, work sample tests at .33 and cognitive ability tests at .31. Every one of those beats a resume skim. The catch is the word structured: the .42 belongs to a process where the questions are fixed and scored, not to a friendly conversation that happens to be about Rails.

A workable four-stage process for a Rails hire:

1. Screen (15 minutes). Confirm the basics: Rails versions worked with, size of the codebases, whether they owned deploys. Two or three questions, same for everyone.
2. Work sample (60 to 90 minutes, async). A small Rails task with hidden test cases, or a code review of a deliberately flawed controller. Score it before anyone sees the candidate's name.
3. Technical interview (60 minutes). Walk through their work sample, then the general and seniority questions below. Two interviewers, one rubric.
4. Team and context interview (45 minutes). How they work with product, how they handle disagreement, what they do when an estimate slips.

Pro tip: write the scoring rubric before you write the questions. If you cannot describe what a 3-out-of-5 answer contains, the question is too vague to score and it will quietly become a vibe check.

What does a Ruby on Rails developer actually do?

A Rails developer builds and maintains server-rendered and API-backed web applications in Ruby, using the Rails framework's conventions for routing, data access, background work and testing. In a team under 200 people they are usually doing full-stack work: the database migration, the controller, the view or the JSON serializer, the background job, and often the deploy.

Two facts set the market context. Rails is a specialist skill, not a common one: in the 2025 Stack Overflow Developer Survey, 6.9% of professional developers reported using Ruby and 6.2% reported using Ruby on Rails. And the wider market they sit in is expensive: U.S. Bureau of Labor Statistics data puts the 2025 median wage for software developers, QA analysts and testers at $134,040 a year across 1,905,400 jobs, with employment projected to grow 10% between 2025 and 2035, per the BLS occupational outlook for software developers. A smaller candidate pool at a six-figure median is exactly the situation where a bad hire hurts and where guessing is the expensive option.

What changed in Rails 8

Rails 8.0 landed in November 2024 and reset several defaults that older interview banks still test. The Rails 8.0 release notes describe Solid Queue replacing "the need for Redis, also a separate job-running framework", Solid Cache replacing Redis or Memcached for fragment caching, and Solid Cable replacing Redis as the WebSocket pubsub server. The same release added an authentication system generator that produces a session-based, password-resettable starting point, made Propshaft the default asset pipeline, and preconfigured Kamal 2 for deployment. Rails 8.1.3 is the current stable release as of March 2026.

None of this means a candidate who reaches for Sidekiq is behind. Plenty of production apps still run it, and for good reason at high job volumes. But asking "how would you add background jobs to a fresh Rails app" and hearing no awareness that the framework now ships an answer tells you how recently they have started something new.

Which Rails skills should you test for in 2026?

Test the skills the role actually uses, and get evidence for each one rather than a claim. This is what the Testlify Competency-to-Evidence Matrix does: start from the role, map it to the competencies that matter, then connect each competency to a measurable source of evidence through assessments, work samples, interviews and structured reviewer feedback. The point is that no competency is allowed to rest on a candidate's own description of it.

Notice what is not on the list: years of experience, framework trivia a search would answer in four seconds, and whether they have used your exact gem stack. Those filter out good candidates without telling you anything about the work.

24 general Ruby on Rails interview questions

Group these by topic and ask the same set to every candidate for a given role. The "look for" line is the rubric. If a candidate misses it, that is a score, not a conversation to rescue.

Architecture and conventions

1. What is the difference between render and redirect_to? Look for: render returns a view in the same request, redirect_to sends a new HTTP request. A strong answer mentions that instance variables survive the first and not the second.
2. Walk through what happens between a request hitting the router and a response leaving the controller. Look for: routes, middleware stack, controller action, filters, view rendering. Vagueness here usually means they have never debugged a routing problem.
3. When would you put logic in a model, a controller, a service object or a concern? Look for: a real rule they apply, not a recitation. The best answers admit that service objects can become a dumping ground.
4. What do Action View helpers do, and when do you write your own? Look for: reuse across templates, keeping view logic out of controllers, awareness that a helper full of business logic is a smell.
5. How do strong parameters work and what do they protect against? Look for: mass assignment. A candidate who cannot name the vulnerability has only copied the pattern.
6. Explain Rails autoloading and a time it surprised you. Look for: Zeitwerk, naming conventions, the class-reloading behaviour in development.

Active Record and data

1. What is an N+1 query and how do you find one? Look for: includes and preload, plus a tool they actually use to detect it. The tool answer separates people who have fixed one from people who have read about one.
2. Difference between includes, preload, eager_load and joins? Look for: separate queries versus a single LEFT OUTER JOIN, and that joins alone does not load the association.
3. How do you write a migration that will not lock a large table? Look for: adding indexes concurrently, backfilling in batches, splitting schema and data changes. Senior answers mention deploying the code and the migration in separate steps.
4. When would you add a database constraint as well as a model validation? Look for: understanding that validations do not protect against race conditions or direct SQL.
5. What are scopes, and when do they get out of hand? Look for: chainability, and the trap of scopes that quietly return different types.
6. How do you handle a schema change that half the app depends on? Look for: expand and contract, feature flags, keeping both shapes readable during the transition.

Testing and code quality

1. What do you test, and what do you deliberately not test? Look for: a stated position. Testing everything and testing nothing are both answers that need defending.
2. Difference between a unit test, an integration test and a system test in Rails? Look for: correct scope for each, and where they put the bulk of their tests.
3. How do you keep a slow test suite usable? Look for: parallelisation, fixtures versus factories, cutting browser tests that duplicate cheaper checks.
4. How do you test a background job? Look for: testing the job class directly, plus asserting it was enqueued rather than running the whole queue.
5. What does a good pull request look like on your team? Look for: size, description, tests, and whether they think review is for catching bugs or sharing context.
6. Tell me about a time code review changed your mind. Look for: a specific technical example. This question is a personality test wearing a technical costume, and it is worth the slot.

Performance, security and delivery

1. A page that used to load in 200ms now takes 4 seconds. What do you do first? Look for: measure before guessing. Named tooling, then the usual suspects in order.
2. What belongs in a background job rather than the request cycle? Look for: email, third-party API calls, report generation, anything with a slow or unreliable dependency.
3. Which Rails security protections do you get by default, and which do you have to remember? Look for: CSRF tokens and escaped output by default; SQL injection through raw string interpolation and mass assignment as the ones you have to think about. Rails documents both categories in its security guide, and a strong candidate can name which protections are automatic.
4. How do you handle secrets and credentials in a Rails app? Look for: encrypted credentials or environment variables, and never in the repository.
5. Describe your deploy process on your last project. Look for: whether they owned it. Ownership of deploys is one of the clearest seniority signals in a small team.
6. What would you upgrade first in a Rails app running a three-year-old version? Look for: Ruby version first, test coverage before anything, incremental version steps rather than a leap.

5 code-based Rails questions with model answers

These work best as a scored work sample rather than a live whiteboard. Give a real repository, hidden test cases and a time limit. What you learn from reading the diff is worth more than watching someone sweat.

1. Fix the N+1 in this controller

Give them an index action rendering a list of posts with author names and comment counts, no eager loading, and a seeded database of a few thousand rows. A good submission adds includes for the association, uses a counter cache or a grouped count for the comment totals, and adds a test that would fail if the N+1 came back. A weak submission adds includes everywhere including associations the view never touches.

2. Refactor a fat controller

Hand over a 90-line create action doing validation, payment, email and logging. Look for the extraction they choose and the reasoning in the pull request description. There is no single right answer here, which is the point: the rubric scores whether the boundaries they drew are defensible and whether behaviour is preserved by tests.

3. Add the missing tests

Take a small, untested model with two edge cases and one genuine bug. Strong candidates find the bug by writing the test, then fix it. Weaker ones write tests that assert the current broken behaviour, which tells you they are testing what the code does rather than what it should do.

4. Design the background job

A written question rather than code: a nightly export that has started timing out. Look for batching, idempotency, what happens on a partial failure, and whether they think about the second run at all. Idempotency is the word to listen for.

5. The vibe-coding task

Give a small feature and let them direct an AI tool to build it instead of writing the syntax by hand. Then ask them to explain a specific decision in the generated code and change one requirement live. This is the question most Rails interview banks are missing, and it now separates candidates more sharply than any syntax question. A developer who can steer the tool, review its output critically and modify it under questioning is doing the job as it is done in 2026. One who cannot explain the code they submitted has told you something important.

How do you assess senior Rails experience?

Seniority shows up in scale, in tradeoffs, and in what someone chose not to build. Ask about a system they owned rather than a technology they used. These five questions do most of the work.

• What is the largest Rails codebase you have worked in, and what made it hard? Listen for specifics: model count, test suite runtime, deploy frequency. "It was big" is not an answer.
• Tell me about a production incident you were on point for. Look for the timeline, what they checked first, what the actual cause turned out to be, and what changed afterwards. Blame-free specificity is the marker.
• What technical decision on a past project would you make differently now? Look for a real reversal with reasoning. Candidates who cannot name one are either very junior or not reflective.
• Describe a time you argued against building something. Look for scope negotiation with product. At a company under 200 people this skill is worth more than another framework.
• How do you bring a junior developer up to speed on a Rails codebase? Look for pairing, documentation, and picking starter work deliberately. This predicts whether the hire multiplies or just adds.

What are the red flags in a Rails interview?

Most red flags are patterns rather than single wrong answers. Score the answer, then look for these across the whole conversation.

• Cannot explain their own submitted code. The single strongest signal, and more common since AI assistants became standard. It is not about whether they used the tool, it is about whether they understood the result.
• No testing opinion at all. Not "I test everything" or "tests slow us down", but a genuine blank. It usually means they have never maintained anything long enough to feel the cost.
• Blames the previous team for everything. Every developer inherits bad code. The tell is whether they can describe what they did about it.
• Only framework-level knowledge, no SQL. Rails hides the database until it cannot. A candidate who has never read a query plan will not diagnose the slow page.
• Rails knowledge frozen at a specific version. Not knowing Rails 8 defaults is fine. Not having looked at anything new in four years is a learning-rate signal.
• Vague on ownership. Persistent use of "we" with no answer to "what did you personally build" is worth one direct follow-up. Ask it once, plainly.

How do skills assessments fit the process?

Testlify runs coding questions in an embedded VS Code editor in the browser, with single-file or multi-file project submissions, up to 20 test cases per question that can be visible or hidden, per-test-case scoring, and SQLite database test cases for the data questions above. Vibe coding is a supported question type, which is what makes question 5 in the work-sample section practical to run at scale rather than only in a live session.

Three things matter beyond the coding surface. The AI checker classifies an answer as human, AI generated or mixed, which turns "did they use AI" from a guess into a data point you can ask about. Item-level analytics report a difficulty index and a discrimination index per question, so a question that everyone passes or that fails to separate candidates can be found and replaced rather than left in place for a year. And coding assessments feed multi-reviewer scoring, so two interviewers score independently before comparing notes.

The product is explicit that AI scores and insights are for guidance only and that human judgment makes the final call. That is the right default. A score narrows the field; a person decides. Testlify also integrates with 100+ ATS platforms, so results land in the system your team already uses rather than in a second place to check. For the full sequence from job posting to offer, the screening guide for Rails hires covers the stages either side of the interview, and the Ruby on Rails test is the ready-made starting point if you would rather not author questions from scratch. Teams hiring across the backend generally can start from the broader backend developer question set instead.

Key takeaways

A strong Rails hiring process tests demonstrated ability before investing senior engineering time in interviews. Use a structured rubric, realistic work samples, current Rails practices, AI-aware evaluation, and deeper SQL testing to distinguish candidates who can build from those who only know how to talk about Rails.

Frequently asked questions (FAQs)