Free Ruby developer interview questions for employers: six sets on Ruby, Rails, debugging, testing, and working style, plus a level calibration scorecard.
Six question sets for the owner or lead running the interview: Ruby fundamentals, Rails and ActiveRecord, debugging, testing, working style, and a level calibration scorecard. Every question comes with why it is worth asking and what a strong answer sounds like. Download as DOCX.
The first time I sat across from a Ruby developer I was about to hire, I understood roughly a third of what he told me, and I could not tell which third was true. That is the ordinary situation for a small business owner making this hire. You wrote the job description yourself, you are the only interviewer, and the person best qualified to check the answers is the person you are trying to evaluate.
You can check far more than you think. Almost every question worth asking a Ruby developer has a memorized answer and a reasoning answer, and the gap between the two is visible without knowing the language. At FirstHR we build for owners who make this hire alone, so every question below arrives with why it is worth asking and what a strong answer actually sounds like.
These six sets cover Ruby fundamentals, Rails and ActiveRecord, debugging, testing and code quality, working style, and a weighted scorecard with a junior to senior calibration guide. Take the sets that fit your situation and skip the rest.
TL;DR
Interview a Ruby developer on five things: language fundamentals judged by reasoning rather than recall, Rails and ActiveRecord judgment, debugging method, testing and code quality, and working style. Decide the level first, ask every candidate the same questions, and score each area from 1 to 5 with written evidence. Six sets download as DOCX.
What a Ruby Developer Does at a Small Business
At a small business, a Ruby developer usually maintains and extends an application that already carries the revenue, rather than building a new one. That single fact should shape the whole interview, because the candidate who performs best on language internals is not always the one who can walk into an unfamiliar codebase, resist rewriting it, and ship something useful in week one.
The scope is also wider than the same title carries at a large company. On a team of two or three, the developer often owns the deploy, the database, the error alerts, and the conversation with you about what to build next. Language skill is necessary and nowhere near sufficient.
In commercial hiring, Ruby work is Rails work most of the time, so treat the two titles as close cousins rather than separate roles. Our Rails developer job description covers the posting side of the same hire, and our guide to finding developers for a startup covers sourcing. This page covers the hour you spend in the room.
Decide the Level Before You Write the Questions
Decide whether you are hiring a junior, a mid-level developer, or someone who will own the application, and do it before you write a single question. The level determines which sets carry weight, what a good answer looks like, and what you have to provide in return, and deciding it after you have met a candidate you liked is how small teams end up with the wrong hire at the right price.
Junior
What they own
Ships small, scoped changes with review
What you must provide
Someone senior available to review and unblock them, either on staff or on retainer
How to weight the interview
Weight collaboration and debugging method highest. Language depth will come.
Mid-level
What they own
Owns features end to end with light direction
What you must provide
A codebase in reasonable shape and clear priorities
How to weight the interview
Weight Rails judgment and testing highest. This is the best value hire for most small teams.
Senior or sole developer
What they own
Owns the application, the deploy, and the phone call at night
What you must provide
Trust, and a decision process for what gets built
How to weight the interview
Weight ownership, production judgment, and communication highest.
A Junior Hire Needs a Reviewer
The most expensive version of this hire is a junior developer with nobody to review their work. It looks like a saving and it is not, because unreviewed early-career code becomes the maintenance burden you pay for over the next three years. If you have no senior developer on staff, either hire mid-level or budget for a few hours a week of an experienced contractor to review pull requests. If you are hiring at the top of the ladder instead, our senior Ruby developer interview questions go deeper on production ownership and inherited code, and the senior Ruby developer job description covers the posting side of that hire.
Which Question Set to Use
Use two or three sets, not all six. Pick them from your situation rather than from the list: a sole-developer role makes testing and debugging the highest-signal hour you will spend, while a hire joining an existing team can be weighted toward Rails judgment and collaboration. Each set is sized to fit inside a normal interview slot.
Ruby Language Fundamentals
Reasoning, not recall
Symbols and strings, blocks, nil handling, Enumerable, modules, and a feature they now avoid. Every question is graded on the reason attached to the definition.
Rails and ActiveRecord
The framework as a system
Request to response, where business logic belongs, N plus one queries, migrations on a large table, background jobs, and upgrade judgment.
Debugging and Problem Solving
The best hour you will spend
An unreproducible bug, the last real bug they fixed, a page that got slow, untested code, and a mistake they caused. Works even if you do not write Ruby.
Testing and Code Quality
Weight this if they are alone
What to test first, when mocking hides a problem, a forty-minute suite, flaky tests, reviewable pull requests, and good code in an app they did not write.
Collaboration and Working Style
Costlier than skill gaps
Explaining a tradeoff without jargon, what they do when stuck, disagreeing and committing, how they learn, and how they want feedback.
Level Calibration Scorecard
Score, do not guess
A weighted six-area rubric with suggested weights per hiring situation, a junior to senior calibration guide, and a red-flag checklist.
Write the Weights Down First
Decide which areas matter most while you are still thinking about the job rather than about a person. Once you have met a candidate you liked, it becomes very easy to quietly re-weight the scorecard toward the things they happened to be good at, and the re-weighting never feels like bias while it is happening. Put the weights in the scorecard file, then start interviewing. If the hire is broader than Ruby, our general technical interview questions cover the same ground without the framework specifics.
6 Question Sets to Download
Download all six as a single Word document, or copy individual sets. Each question lists why it is worth asking, what a strong answer sounds like, and what a weak one sounds like, with space for notes. More question sets by role sit in the hiring templates library.
Download All Six Question Sets and the Scorecard
Five question sets plus a weighted scoring rubric, a junior to senior calibration guide, and a red-flag checklist. All in one DOCX.
Set 1: Ruby Language Fundamentals Questions
Symbols and strings, blocks, nil handling, Enumerable, modules, and a feature they used once and now avoid. Each question is graded on the reason, not the definition.
Ruby Language Fundamentals Questions
RUBY DEVELOPER INTERVIEW: LANGUAGE FUNDAMENTALS
Candidate: __
Interviewer: __
Date: __
Suggested length: 20 to 25 minutes
QUESTIONS TO ASK
1. What is the difference between a symbol and a string, and when does the
difference actually matter in real code?
Why ask it: it is the most common warm-up question in Ruby hiring, so almost
every candidate has an answer ready. The value is in the second half, which
almost nobody rehearses.
Strong answer: gives the definition quickly, then names a real situation
(hash keys, comparisons in a hot loop, data arriving from outside the app)
and explains why it mattered there.
Weak answer: a textbook definition with nothing behind it, or an insistence
that the choice never matters.
2. Walk me through what a block is, and when you would use one instead of a
plain method.
Why ask it: blocks are the feature that most separates people who write Ruby
from people who write another language in Ruby syntax.
Strong answer: describes passing behavior into a method, gives an example
they wrote themselves, and can say what a block costs in readability when it
grows past a few lines.
Weak answer: recites the difference between a proc and a lambda without ever
describing a use.
3. How do you handle nil in a codebase where a lot of methods can return it?
Why ask it: nil handling is where most production Ruby errors actually come
from, so this predicts real defect rates better than syntax questions.
Strong answer: talks about deciding at the boundary, keeping nil from
spreading, and having a house style rather than scattering checks
everywhere.
Weak answer: names one operator and stops.
4. Which Enumerable methods do you reach for most, and when does map become the
wrong choice?
Why ask it: it separates fluency from familiarity, and the second half tests
whether they think about what the code does to memory and readability.
Strong answer: names several methods with the situations that call for each,
and can describe a case where a plain loop or a lazy approach was clearer or
cheaper.
Weak answer: lists method names as vocabulary with no situations attached.
5. When would you use a module instead of a superclass?
Why ask it: it is a design question wearing a syntax costume, and the answer
reveals how they structure code they expect other people to read.
Strong answer: shared behavior across unrelated classes versus a real is-a
relationship, plus an honest note that modules get overused as a place to
hide code that has no better home.
Weak answer: describes the mechanics of inclusion without any judgment about
when to use it.
6. Tell me about a Ruby feature you used once and now avoid.
Why ask it: it is the single best question in this set, because it requires
having owned code long enough to watch a clever decision turn expensive.
Strong answer: a specific feature, the specific problem it caused later, and
a changed rule of thumb. Metaprogramming and monkey patching are common and
good answers.
Weak answer: cannot think of one, or names something they read a warning
about but never used.
7. What happens when two gems define the same method on the same class?
Why ask it: it tests whether they have debugged a real dependency conflict
or only read about one.
Strong answer: describes load order winning, why the resulting bug is hard
to find, and how they would confirm which definition is active.
Weak answer: a confident theoretical answer with no method for checking.
WHAT A STRONG SET OF ANSWERS SOUNDS LIKE
Score reasoning, not recall. Every question above has a memorized answer and a
reasoning answer, and only the second one predicts anything about the job. The
reliable follow-up is five words long: where did that bite you? Candidates
prepare definitions; they rarely prepare consequences.
NOTES
[Write the answer down in the candidate’s own words before scoring it.]
Set 2: Rails and ActiveRecord Questions
Request to response, where business logic belongs, N plus one queries, a migration against a large table, background jobs, and what they check before a framework upgrade.
Rails and ActiveRecord Questions
RUBY DEVELOPER INTERVIEW: RAILS AND ACTIVERECORD
Candidate: __
Interviewer: __
Date: __
Suggested length: 25 to 30 minutes
QUESTIONS TO ASK
1. Explain what happens between a browser request and the rendered page in a
Rails application.
Why ask it: it is the cheapest test of whether the candidate understands the
framework as a system or only as a set of files they edit.
Strong answer: routing, controller, model and database, view, response, with
the places they have actually had to debug called out.
Weak answer: names the three letters of the pattern and stops.
2. Where do you put business logic that does not belong in the controller or
the model?
Why ask it: this is the question your codebase will live with for years, and
there is no single right answer, which is exactly why it is useful.
Strong answer: has a position and defends it with the tradeoff, and admits
what their approach costs when the application grows.
Weak answer: repeats a slogan about fat models or skinny controllers with no
reasoning attached.
3. How do you spot and fix an N plus one query?
Why ask it: it is the most common performance problem in Rails applications
and the most common one small teams ship without noticing.
Strong answer: describes noticing it in logs or an instrumentation tool
first, then the fix, and mentions confirming the query count dropped
afterward.
Weak answer: names the fix without ever describing how they would find the
problem.
4. Walk me through writing a migration against a table with several million
rows.
Why ask it: it separates people who have changed a schema in production from
people who have only done it on a laptop.
Strong answer: worries about locks and downtime, splits the change into
steps, backfills separately from the schema change, and has a plan for
reversing it.
Weak answer: describes the migration file and nothing about what it does to
a live application.
5. When is adding a database index the wrong fix?
Why ask it: it tests whether they treat a familiar remedy as a reflex or as
a decision with a cost.
Strong answer: names write cost, storage, and cases where the query itself
or the data model is the real problem.
Weak answer: treats indexes as free.
6. How do you decide whether work belongs in a background job or in the
request?
Why ask it: getting this wrong is the most common cause of slow pages and
duplicate emails at small companies.
Strong answer: talks about what the user needs to see immediately, what
happens if the job runs twice, and how failures get retried and observed.
Weak answer: moves everything to a queue with no discussion of failure.
7. What do you check before upgrading the framework version on an application
that is already carrying the business?
Why ask it: most small-company Ruby work is maintenance, so upgrade judgment
is closer to the real job than greenfield design is.
Strong answer: test coverage first, then dependencies, then a sequence of
small releases rather than one large one, with a way to roll back.
Weak answer: proposes an upgrade sprint with no mention of tests or
rollback.
WHAT A STRONG SET OF ANSWERS SOUNDS LIKE
The pattern to listen for is measure, then change. A strong candidate
establishes how they would know what is wrong before proposing what to do
about it, and they can name the cost of their own recommendation. If you hear a
confident fix arrive before any diagnosis, ask how would you know that was the
cause, and score the second answer rather than the first.
NOTES
[Write the answer down in the candidate’s own words before scoring it.]
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
The closest thing to a job simulation you can run in an hour, and the set that works best if you do not write Ruby: an unreproducible bug, a page that got slow, and untested code.
Debugging and Problem-Solving Questions
RUBY DEVELOPER INTERVIEW: DEBUGGING AND PROBLEM SOLVING
Candidate: __
Interviewer: __
Date: __
Suggested length: 20 to 25 minutes
QUESTIONS TO ASK
1. A customer says the checkout page is broken, but you cannot reproduce it.
What do you do first?
Why ask it: it is the closest thing to a job simulation you can run without
a laptop, and it works even if you do not write Ruby yourself.
Strong answer: gathers specifics before touching code (who, when, what
browser, what account, what error tracking shows), and narrows deliberately
rather than guessing.
Weak answer: starts changing code, or asks the customer to try again.
2. Walk me through the last real bug you fixed, start to finish.
Why ask it: an invented answer falls apart under two follow-ups, and a real
one shows you their actual method rather than their described one.
Strong answer: a specific symptom, how they narrowed it, what the cause
turned out to be, and what they did so it could not happen again.
Weak answer: a generic description with no detail that could only come from
having been there.
3. A page that used to be fast now takes six seconds. Where do you look?
Why ask it: it tests ordering. There are many possible causes, and the
answer reveals whether they work from evidence or from habit.
Strong answer: asks what changed and when, looks at instrumentation before
guessing, separates database time from application time, and names the
first measurement they would take.
Weak answer: jumps straight to caching or to adding servers.
4. You have to change a method nobody understands and it has no tests. How do
you do it safely?
Why ask it: at a small company this is a weekly event, and the answer
predicts how much damage the hire will do in month one.
Strong answer: pins the current behavior with tests first, changes in small
reversible steps, and resists rewriting until the behavior is understood.
Weak answer: proposes a rewrite before reading anything.
5. How do you decide when to stop investigating and ship a workaround?
Why ask it: small companies need judgment about when good enough is
correct, not just technical purity.
Strong answer: ties the decision to customer impact and to the cost of the
outage, and describes writing the real problem down so it is not lost.
Weak answer: either never ships a workaround or never goes back.
6. Tell me about a bug you caused. How did you find out, and what changed
afterward?
Why ask it: the willingness to answer at all is signal, and the change they
made afterward is the part that transfers to your team.
Strong answer: names a specific mistake without excessive hedging, and
describes a concrete habit or guardrail that came out of it.
Weak answer: cannot think of one, or every problem was caused by someone
else.
WHAT A STRONG SET OF ANSWERS SOUNDS LIKE
Debugging answers are where a candidate’s method is most visible and least
rehearsed. Strong candidates narrow: they describe cutting the space of
possible causes in half rather than listing everything that could be wrong.
Weak candidates enumerate. Push with what would you check next, twice in a row,
and the difference becomes obvious to a non-technical interviewer.
NOTES
[Write the answer down in the candidate’s own words before scoring it.]
Set 4: Testing and Code Quality Questions
Weight this heavily if the hire will be your only developer: what to test first, when mocking hides a problem, a slow suite, flaky tests, and reviewable pull requests.
Testing and Code Quality Questions
RUBY DEVELOPER INTERVIEW: TESTING AND CODE QUALITY
Candidate: __
Interviewer: __
Date: __
Suggested length: 15 to 20 minutes
QUESTIONS TO ASK
1. You have limited time. What do you test first?
Why ask it: nobody at a small company has full coverage, so the useful
question is how they choose.
Strong answer: prioritizes by what breaks the business (money, data loss,
access) and by what has broken before, rather than chasing a coverage
number.
Weak answer: recites a coverage target, or says everything should be tested.
2. When do you mock, and when is mocking hiding a real problem?
Why ask it: over-mocked suites pass while the application is broken, which
is the worst possible outcome for a team with no QA function.
Strong answer: mocks at real boundaries such as third-party services, and
notices that heavy mocking of their own code usually means the design is
tangled.
Weak answer: mocks everything for speed with no discussion of what the test
still proves.
3. Your test suite takes forty minutes. What do you do?
Why ask it: a slow suite is the most common reason small teams quietly stop
running tests at all.
Strong answer: measures which tests are slow before changing anything, then
talks about splitting, parallelizing, or moving a few tests down a level.
Weak answer: proposes deleting tests, or proposes buying hardware without
measuring.
4. How do you handle a flaky test?
Why ask it: how someone treats an unreliable test tells you how they treat
unreliable evidence in general.
Strong answer: treats flakiness as a real defect to diagnose, quarantines
with a deadline rather than deleting, and names common causes such as time,
ordering, or shared state.
Weak answer: retries until green, or deletes it.
5. What makes a pull request easy to review?
Why ask it: at a small company, review capacity is the scarcest resource
you have, and it predicts how much of your week the hire will consume.
Strong answer: small scope, a description that explains why rather than
what, and separating refactoring from behavior change.
Weak answer: has no view, or describes review as a formality.
6. What does good code mean in an application you did not write?
Why ask it: it distinguishes a personal aesthetic from a working standard,
and small-company Ruby work is mostly other people’s code.
Strong answer: consistency with what is already there, readability for the
next person, and changing style only when there is a reason beyond taste.
Weak answer: describes a preferred style and treats deviation as
incompetence.
WHAT A STRONG SET OF ANSWERS SOUNDS LIKE
Weight this set heavily when the hire will be your only developer, because
nobody else is going to catch anything. The answers you want are proportional:
a candidate who tests everything and a candidate who tests nothing are both
telling you they have not had to make the tradeoff with a real deadline.
NOTES
[Write the answer down in the candidate’s own words before scoring it.]
Set 5: Collaboration, Learning, and Working Style Questions
Explaining a tradeoff without jargon, what they do when stuck, disagreeing and committing, how they learn a new part of the stack, and how they want feedback on their code.
Collaboration, Learning, and Working Style Questions
RUBY DEVELOPER INTERVIEW: COLLABORATION AND WORKING STYLE
Candidate: __
Interviewer: __
Date: __
Suggested length: 15 to 20 minutes
QUESTIONS TO ASK
1. Explain a technical tradeoff you made to someone who does not write code.
Pick any one, and explain it to me now.
Why ask it: at a small company the developer talks to the owner constantly,
so this is a daily job requirement rather than a soft skill.
Strong answer: plain language, an honest cost on both sides, and a
recommendation. Watch for jargon used as a shield.
Weak answer: cannot leave the vocabulary behind, or oversimplifies into a
sales pitch.
2. What do you do when you have been stuck for more than an hour?
Why ask it: it is the single most useful question for a junior or mid-level
hire, because the failure mode is silence rather than incompetence.
Strong answer: a specific personal rule about when to ask, and what they
bring with them when they do (what they tried, what they expected, what
happened).
Weak answer: never asks for help, or asks immediately without trying.
3. Tell me about a time you disagreed with a technical decision and lost.
Why ask it: it shows whether they can commit to a direction they argued
against, which matters far more on a team of three than on a team of thirty.
Strong answer: a real disagreement, the argument they made, and evidence
they then supported the decision properly.
Weak answer: has never disagreed, or is still relitigating it.
4. How do you learn a part of the stack you have not used before?
Why ask it: the tools will change, so the learning method is the durable
part of the hire.
Strong answer: a concrete method with a recent example, usually building
something small and reading the source when documentation runs out.
Weak answer: says they pick things up quickly and offers nothing else.
5. How do you want feedback on your code?
Why ask it: it prevents a specific and common early failure, where the owner
avoids giving feedback because the first attempt went badly.
Strong answer: has a preference and can say why, and separates feedback on
code from feedback on the person.
Weak answer: no preference, or defensiveness surfacing in how they answer
the question itself.
6. What did your last team do well, and what would you change?
Why ask it: the shape of the criticism tells you what they will bring to
your team, and how they talk about a previous employer is a useful preview.
Strong answer: specific on both halves, with the criticism aimed at process
rather than at named people.
Weak answer: everything was terrible, or everything was perfect.
7. What questions do you have about how we work?
Why ask it: what a candidate asks is often better evidence than what they
answer.
Strong answer: asks about ownership, on-call, review, and what the first
ninety days look like.
Weak answer: no questions, or only compensation questions in a first
conversation.
WHAT A STRONG SET OF ANSWERS SOUNDS LIKE
This set carries the most weight for a first developer hire and the least for a
short-term contractor. On a team of two or three, communication failures cost
more than skill gaps, because a skill gap is visible and a communication gap
takes three months to surface.
NOTES
[Write the answer down in the candidate’s own words before scoring it.]
Set 6: Level Calibration Scorecard and Red Flags
A weighted six-area rubric with suggested weights for three hiring situations, a junior to senior calibration guide, and a red-flag checklist, so the decision rests on written evidence.
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Key strengths: __
Key concerns: __
Interviewer signature: __
Every interviewer scores alone before anyone speaks. Technical debates anchor
hard, and the person with the strongest vocabulary usually wins the room
regardless of the evidence.
How to Judge Answers If You Do Not Write Ruby
Grade the shape of the answer rather than the syntax. A strong answer attaches a specific reason to every definition, names what the choice cost as well as what it gained, and describes measuring something before changing it. That pattern is recognizable whether or not you know what a block is.
The most useful follow-up on this page is four words long: how would you know? Ask it after any diagnosis and after any recommendation. Rehearsed candidates have prepared the answer, not the reasoning behind it, and the difference surfaces within one exchange.
A definition arrives with a reason attached
Sounds like this
Symbols are reused, so they matter as hash keys and in loops that run constantly. It bit us in a report that built a hash per row.
Not this
Symbols are immutable and strings are mutable.
Measurement comes before the fix
Sounds like this
I would check what changed and when, then look at where the time is actually going before touching anything.
Not this
I would add caching.
The cost of their own choice is named
Sounds like this
Extracting that into a service object made it testable, but it added a layer people have to find. That is the trade.
Not this
Service objects are the correct pattern.
Ownership of a specific mistake
Sounds like this
I shipped a migration that locked a table for eleven minutes on a Friday. Now I split backfills out of the schema change.
Not this
I have not really had a production issue.
One habit worth borrowing from structured interviewing: write the candidate's answer down in their own words before you score it. Scoring from memory an hour later quietly turns into scoring how the conversation felt, which is exactly the thing a technical interview is worst at measuring.
Junior, Mid-Level, or Senior: Reading the Answers
Level is scope and judgment, not years in the language, and the same question separates the levels cleanly if you listen for the right thing. Titles inflate on resumes, so treat the level a candidate claims as something to test rather than something to accept.
Question
Junior answer
Mid-level answer
Senior answer
Symbols versus strings
Correct definition
Definition plus where it mattered
Definition, where it mattered, and when it does not
Handed unfamiliar code
Asks what it is supposed to do
Reads the tests and the callers
Pins behavior with tests, changes in small steps
A page suddenly got slow
Lists possible causes
Names the first measurement to take
Asks what changed and when, then measures
Business logic placement
Puts it in the model
Has a position and a reason
Has a position and names its cost
Asked about a failure
Has not had one yet
Owns a mistake and what changed
Owns a decision, not just a mistake
Explaining a tradeoff
Reaches for vocabulary
Plain language, one side of the cost
Plain language, honest cost on both sides
The most informative single question in the whole set is the one about a Ruby feature they used once and now avoid. It cannot be answered from study, because it requires having owned code long enough to watch a clever decision turn expensive, which is the difference between the levels in one sentence.
The Practical Exercise, and What to Skip
Run one short, realistic, paid exercise, and skip both the multi-day take-home project and the algorithm puzzle. Long unpaid assignments are declined most often by candidates with the strongest options, so they filter for availability rather than skill, and puzzles measure interview practice.
Format
What it actually measures
Use it?
Read a file from your codebase out loud
Judgment, reading order, what they notice first
Yes, the highest signal per minute
Small time-capped task, paid, criteria stated
Working code, structure, and how they scope
Yes, for a second data point
Pair on a real bug for one hour, paid
Collaboration and debugging together
Yes, if you have someone to pair with
Multi-day unpaid take-home project
Availability and tolerance for unpaid work
No
Whiteboard algorithm puzzle
Recent interview practice
No
Trivia quiz on language syntax
Memory, not judgment
No
Whichever you choose, tell the candidate in advance how it will be judged, and give the same exercise to every finalist so the comparison means something. Our guide to skills assessment covers designing a fair exercise in more detail.
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
The prepared questions open the door and the follow-ups are where the evidence is. Push for the specific number, the actual outcome, and the decision the candidate personally made, and read the signals below as patterns across the whole hour rather than as verdicts on a single answer.
Follow-ups worth memorizing
How would you know that was the cause?
What would you check next?
Where did that bite you?
What did that decision cost you later?
Signals of a strong hire
Narrows instead of listing possibilities
Names the cost of their own recommendation
Reads before rewriting
Asks about ownership and the first ninety days
Signals worth probing harder
Correct definitions with nothing underneath
A fix proposed before any diagnosis
Jargon when you ask for plain language
No question they want to ask you
Patterns, not single answers
Every past team and codebase was terrible
Cannot name a mistake of their own
A rollback described but clearly never performed
Confidence that rises as specifics fall
No single red flag is disqualifying. The one worth probing hardest is a rewrite proposed before the candidate has read anything, because at a small company the job is mostly the opposite of that. Ask what they would need to read first, and listen to whether the answer changes.
Scoring the Interview
Score each of the six areas from 1 to 5 with one line of written evidence, immediately after the interview while the answers are still fresh. A score with nothing written beside it is a gut feeling wearing a number, and it will not survive a disagreement two days later.
If more than one person interviews, everyone scores alone before anyone speaks. This matters more in technical hiring than anywhere else, because the strongest vocabulary in the room usually wins the debate whatever the evidence says. Our interview evaluation form is a general-purpose version of the same discipline, and the phone screen guide covers the round before this one.
Ruby Developer Pay
There is no federal wage series for Ruby developers, because occupations are classified by role rather than by programming language. The nearest classification is software developers, SOC 15-1252, and the honest way to use it is the percentile ladder as a leveling map rather than the headline median as a quote.
Software Developers, National Wages
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers (SOC 15-1252) had a national median annual wage of $135,980, with the 10th percentile at $82,460, the 25th percentile at $105,210, the 75th percentile at $171,980, and the 90th percentile at $214,670 (U.S. Bureau of Labor Statistics, OEWS national estimates).
Percentile
Annual wage (BLS OEWS, May 2025)
Roughly which level
10th
$82,460
Junior, first commercial role
25th
$105,210
Junior to lower mid-level
50th (median)
$135,980
Solid mid-level developer
75th
$171,980
Senior individual contributor
90th
$214,670
Staff and principal scope
Anchor to the level you decided on earlier, then adjust for your market, your industry, and whether the role carries production ownership. Read our guide to salary benchmarking before you set a band, and publish a good-faith range wherever pay transparency laws apply.
Two practical notes. The federal occupation profile for software developers covers a far wider population than Ruby specialists, so treat the ladder as a map rather than a market rate. And most software roles at this level are exempt from overtime under the Department of Labor computer employee exemption, which carries its own salary and duties conditions. This is general information, not legal advice.
Fair, Legal, and Structured Interviewing
A fair interview and an accurate one are the same interview. Asking every candidate the same job-related questions produces comparable evidence, reduces bias, and keeps you away from the questions that create legal risk, which are collected in our guide to illegal interview questions.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and questions that probe them create risk even when they arrive as friendly small talk. Avoid age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. In a developer interview the traps are specific and easy to walk into: asking how long someone has been programming as a proxy for age, asking where they are originally from after hearing an accent, or raising family plans while explaining on-call rotation. Every question in the sets on this page is tied to the work. This is general information, not legal advice.
Ask every candidate the same core questions
A structured interview, where every candidate faces the same questions scored against the same rubric, predicts on-the-job performance far better than a free-flowing conversation, and it reduces the chance that the decision rests on rapport. Technical interviews drift more than most, because a candidate who shares your background produces a more comfortable hour regardless of their skill. Pick your sets, fix the order, and ask them the same way every time. If a candidate takes you somewhere interesting, follow it, then come back to the list rather than abandoning it.
Score independently, then discuss
When more than one person interviews, each scores the rubric alone before the group talks. This matters more in technical hiring than anywhere else, because the most confident vocabulary in the room tends to win the debate whatever the written evidence says. Compare the scores first, then talk about the gaps. Write one line of evidence next to every number: a score with nothing beside it is a gut feeling wearing a number, and it will not survive a disagreement two days later.
Interview for your codebase, not a generic one
A Ruby developer joining a six-year-old application that already carries the business is a different hire from one joining a project three months old, so weight the sets accordingly. An older application makes debugging judgment and upgrade sequencing the highest-signal questions you can ask. A newer one shifts weight toward design decisions and testing habits that will still be there in three years. Decide which situation you are in before you write the weights down, and interview for the job you actually have rather than for a generic engineering role.
Structure Beats Conversation
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation, and asking the same job-related questions of everyone also keeps you within the EEOC rules against basing decisions on protected characteristics. Technical interviews drift more than most, so structure matters here more, not less.
Keep the small talk on the job as well. In a developer interview the traps arrive as friendly curiosity: how long someone has been programming used as a proxy for age, where they are originally from, or family plans raised while you explain the on-call rotation. This is general information, not legal advice.
Interviewing Without an HR Department
At a large company a developer candidate runs a coordinated loop with several engineers and a recruiter collecting scorecards. At a small business the owner usually runs the interview alone, between everything else, and then hands the application to whoever they choose. Here is how to make that one hour hold up.
The person best placed to judge the answers is the person you are hiring
At a large company a developer candidate runs a coordinated loop with several engineers and a recruiter collecting scorecards. At a small business the owner usually runs the whole interview alone, and often cannot verify a technical claim directly. The workaround is cheaper than it sounds: grade the shape of the answer rather than the syntax, and pay a developer you trust for two hours in the final round if you want a second technical opinion. Two hours of an experienced contractor is a rounding error against the cost of a wrong hire.
A long take-home exercise quietly filters out the candidates you want
Multi-day unpaid projects are declined most often by the candidates with the strongest options, so a long take-home does not filter for skill, it filters for availability. Two formats work better at a small company. Ask the candidate to read a short file from your own codebase out loud and say what they notice first, which grades exactly the judgment you are hiring for and needs no grading rubric from you. Or give a small, time-capped task with the evaluation criteria stated up front, and pay for the time. Give the same exercise to every finalist so the comparison means something.
The interview is one hour; the first month decides whether it worked
Once you choose someone, the job shifts from evaluating to hiring well: a written offer that arrives quickly, the new hire paperwork, and access ready before the first morning. FirstHR fits this people side for a small business: send the offer for e-signature, run the new hire paperwork and the onboarding checklist, and keep the signed documents and the hiring record on the employee profile. To be clear on scope, FirstHR is an onboarding and HR platform, not a payroll provider and not an engineering tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
Two cheap additions raise the accuracy of the whole process. Pay a developer you trust for two hours in the final round if you want a second technical opinion, and check references specifically on ownership and follow-through rather than on general impressions. Applicant tracking is coming soon to FirstHR.
From Interview to Onboarding
Once you choose someone, speed is most of the game. A good developer is usually in another process, so a written offer letter that arrives the same day beats a better package that arrives next week. After that, the job is making the first week feel organized rather than improvised.
Send the offer the same day
Confirm title, level, pay, remote expectations, and start date in writing with e-signature. A developer with options is usually in another process, so a slow week costs you the hire.
Have access ready on day one
Repository, staging, error tracking, database, and the deployment path, provisioned with least privilege before the first morning rather than requested during it.
Ship something small in week one
A local environment running and one real change in production during the first week is the clearest signal that the onboarding was designed rather than improvised.
Keep the hiring record together
Store the scorecards, the signed offer, the confidentiality agreement, and the standard new hire forms in one place so the employee file is complete.
Access is the part small companies get wrong most often. Nothing signals a serious employer faster than a developer who can run the application locally and ship a small change in week one, and our guide to developer onboarding covers that sequence in detail.
FirstHR connects the offer, e-signature, new hire paperwork, policy acknowledgments, and the onboarding checklist in one place, and keeps the signed documents and the hiring record on the employee profile. FirstHR is an onboarding and HR platform, not a payroll provider and not an engineering tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Decide the level before you write the questions, because it changes which sets matter and what a good answer sounds like.
Score reasoning, not recall: every question here has a memorized answer and a reasoning answer, and only the second predicts anything.
Weight debugging and testing highest when the hire will be your only developer, because nobody else will catch anything.
Ask how would you know that was the cause after every diagnosis; it is the follow-up rehearsed candidates have not prepared for.
Run one short paid exercise and skip the multi-day take-home, which filters for availability rather than for skill.
Anchor pay to the level you chose: $105,210 at the 25th percentile to $171,980 at the 75th for software developers (BLS OEWS, May 2025).
Frequently Asked Questions
What questions should I ask a Ruby developer in an interview?
Ask across five areas: Ruby language fundamentals, Rails and ActiveRecord judgment, debugging method, testing and code quality, and working style. Strong openers include when the difference between a symbol and a string actually matters, where business logic belongs if it is not in the controller or the model, how they would start on a bug they cannot reproduce, what they test first when time is short, and what they do after being stuck for an hour. Every one of those has a memorized answer and a reasoning answer, and only the second one predicts anything about the job. The most useful follow-up is five words long: where did that bite you? Candidates prepare definitions and rarely prepare consequences, so the second half of the answer is where the evidence is.
How do I interview a Ruby developer if I do not write code?
Grade the shape of the answer rather than the syntax. A strong answer attaches a specific reason to every definition, names what the choice cost as well as what it gained, and describes measuring something before changing it. A weak answer is a correct definition with nothing underneath, or a confident fix proposed before anyone has established a cause. That pattern is recognizable without knowing what a block is. Lean on the debugging set, which reads as plain problem solving, and ask the candidate to explain one tradeoff as though you do not write code, because a developer at a small company has to do that with you regularly. If you want more confidence, pay a developer you trust for two hours in the final round.
What is the difference between a Ruby developer and a Rails developer?
In practice, almost none in commercial hiring. Ruby is the language and Rails is the dominant web framework written in it, so the overwhelming majority of paid Ruby work at small companies is Rails work. A candidate who says they are a Ruby developer rather than a Rails developer is usually signaling either broader experience outside web applications or a preference for the language itself. It is worth one clarifying question rather than a filter: ask what proportion of their last two roles was Rails, and what they built when it was not. Interview the same way regardless, but weight the framework set higher when the hire will spend every day inside a Rails application, which is the usual case.
How do I tell a junior Ruby developer from a mid-level one?
Look at whether reasons arrive attached to answers, and at how they debug. A junior candidate gives correct answers about the language that stay thin on consequences, and debugs by listing everything that could be wrong. A mid-level candidate attaches a reason to each definition, names at least one real cost, and narrows during debugging rather than enumerating. The second reliable marker is production experience: a mid-level developer has usually caused a real problem and can describe the habit that came out of it, while a junior has not yet had the chance. Neither is better in the abstract. A junior hire is a fine decision when you have someone to review their work, and a poor one when they will be your only developer.
Should I give a Ruby developer a coding test?
Give a short, realistic, paid exercise rather than a long unpaid project or a whiteboard puzzle. Multi-day take-home assignments are declined most often by the candidates with the strongest options, so they filter for availability rather than for skill, and algorithm puzzles measure interview practice more than the job. Two formats work well at a small company. Ask the candidate to read a short file from your own codebase out loud and say what they notice first, which grades judgment directly and works even if you cannot evaluate Ruby yourself. Or give a small, time-capped task with the evaluation criteria stated in advance, and pay for the time. Give the same exercise to every finalist so the comparison is meaningful.
How much does a Ruby developer cost?
There is no federal wage series for Ruby specifically, because occupations are classified by role rather than by programming language. The nearest classification is software developers, SOC 15-1252. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers had a national median annual wage of $135,980, with the 25th percentile at $105,210, the 10th percentile at $82,460, and the 75th percentile at $171,980. Read the ladder as a leveling map rather than a single number: a junior hire typically sits near the 10th to 25th percentile, a solid mid-level developer near the median, and a senior individual contributor near the 75th. Adjust for your market, your industry, and whether the role carries production ownership. Most software roles at this level are exempt from overtime under the federal computer employee exemption.
How many interview rounds should a Ruby developer hire have?
Two or three rounds is right for a small business, and more than that starts costing you candidates. A practical structure is a 30-minute screening call covering scope, compensation range, and logistics, then a 60 to 90 minute technical conversation using two or three of the question sets on this page, then a short final round with the owner covering ownership expectations and the first ninety days. Decide within two business days of the final conversation. Compressing rounds is not the same as compressing rigor: the same questions, asked of every candidate and scored on the same rubric, produce better evidence in two hours than five unstructured conversations produce in three weeks.
Are these Ruby developer interview questions legal to ask?
Yes. Questions about technical experience, how a candidate approaches specific problems, decisions they have made, and how they work with a team are job-related and permitted. The legal caution is general to all interviewing: avoid anything that probes characteristics protected under federal law, which the EEOC enforces, including age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. In developer interviews these usually arrive as small talk, such as how long someone has been programming used as an age proxy, where they are originally from, or family questions raised while discussing on-call rotation. Asking the same job-related questions of every candidate and scoring them on the same rubric is the simplest way to stay both fair and consistent. This is general information, not legal advice.
