Hiring a developer when you’re not technical is one of the harder challenges for non-technical founders and business owners. You can’t evaluate the code. You don’t know if the answers you’re getting are good ones. You’re essentially trying to hire a surgeon without being able to check their medical records.
I’ve helped a few clients navigate this. Here’s what I’ve learned about how to hire a Rails developer when you don’t know Rails.
Get Clear on What You Need First
Before you start evaluating candidates, you need to understand what you’re actually hiring for. The most common mistake I see is businesses hiring a developer before they’ve defined the problem clearly enough to know what kind of developer they need.
A few questions to answer before you start:
Is this greenfield or maintenance? Building something new from scratch is very different from improving and extending something that exists. Some developers are great at one and struggle with the other.
How much complexity is involved? A simple marketing site is not the same as an order management system with third-party ERP integration. Be honest about what you’re building.
Do you need someone long-term or for a project? Permanent hire versus contractor versus project engagement changes who you’re looking for.
What’s your budget? Good Rails developers cost real money. Junior developers cost less and can be valuable, but they need mentorship. If you’re hiring a junior developer to build your production application without technical oversight, you’re setting up for problems.
Where to Find Rails Developers
Rails-specific communities. The Ruby on Rails subreddit, the Ruby community Slack, Ruby Central’s job board — these are where Rails developers actually hang out.
Toptal and Gun.io for vetted freelancers. They screen candidates, which helps when you can’t evaluate technical skills yourself. More expensive, but the quality floor is higher.
Referrals. If you know anyone in the tech world, ask who they’ve worked with and trusted. A genuine referral is worth ten cold applications.
Upwork — with caution. The quality range is enormous. You can find excellent developers on Upwork, but you can also find people who look good on paper and disappear after deposit. Do not hire someone on Upwork for a large project without a small paid test first.
Direct outreach. Find Rails developers with public GitHub profiles, look at their work, and reach out directly. This is time-consuming but filters for people who write real code.
Interview Questions That Work When You’re Not Technical
You can’t ask coding questions and evaluate the answers. But you can evaluate how someone thinks.
“Tell me about the last application you built in Rails. What was hard about it and how did you handle it?”
Good developers have clear answers. They can explain what they built in terms a non-developer can follow, identify what was genuinely challenging (not just “it was complex”), and describe their decision-making process. Watch for specificity — vague answers about “complex architecture” without details are a warning sign.
“Walk me through how you’d approach building [specific thing you need].”
You don’t need to evaluate the technical correctness — you need to see whether they ask clarifying questions, think about trade-offs, and have a coherent approach. Good developers don’t just immediately start describing implementation. They make sure they understand the problem first.
“What’s something you built that you’d do differently now?”
This question separates developers who think critically about their work from those who believe their code is always right. The answer doesn’t need to be in technical terms — the key is whether they can reflect honestly on their decisions.
“How do you handle it when you disagree with a client’s direction?”
You need someone who’ll push back when something doesn’t make sense, but who respects that you’re the decision-maker. The right answer involves expressing the concern clearly, explaining why, and then ultimately respecting the client’s choice.
The Paid Test Project
Before committing to a significant engagement, do a small paid test. Give the candidate a well-defined task — something real but small — and pay them their standard rate. Evaluate:
- Did they understand the requirements or did they ask good clarifying questions?
- Did they deliver what was asked or something adjacent to it?
- Is the code readable and structured reasonably?
- Did they communicate during the process or disappear and surface with a finished product?
- Did they finish within the estimate?
A paid test isn’t foolproof but it’s much better than interviews alone. Most good developers are comfortable with this arrangement.
Get a Technical Advisor
If you’re hiring for a significant role or project, invest in a couple hours with a technical advisor — someone who can review candidates’ code samples, sit in on technical interviews, and give you a second opinion on what you’re hearing.
This doesn’t need to be expensive. $500-$1,000 in consulting fees to validate your hiring decision on a role that will cost you $80,000-$150,000 annually is extremely good ROI.
The Green Flags
- They talk about the problem before the solution
- They’re honest about what they don’t know
- They have examples of production code they can share or discuss
- They ask about your business goals, not just the technical requirements
- They have opinions and can back them up with reasoning
- They’ve maintained systems, not just built them
The Red Flags
- They promise fast delivery on everything without scoping it
- They can’t explain technical decisions in plain English
- Their references are vague or unavailable
- They avoid talking about past failures or mistakes
- They quote significantly below market rates for senior-level work (this usually means you’re getting junior work at senior-looking rates)
Hiring is hard. If you want a direct conversation about whether I’m the right fit for what you’re building — or if you’d like a technical advisor perspective on a candidate you’re evaluating — reach out. I’m direct about what I can and can’t do, and I’ll tell you if what you need isn’t what I offer.