You run a business, you need software built or maintained, and you can't read code. Now you have to hire a developer and somehow judge work you can't evaluate. This is a real problem, and pretending otherwise is how non-technical owners end up paying for six months of "almost done." The good news: you can screen developers well without knowing how to program, because most of what predicts a good developer is visible to anyone who watches carefully.
Make them walk you through their work
Don't ask about skills. Ask about things they've shipped. Pick a project from their portfolio or resume and have them walk you through it like you're a customer:
- What does it do, and who uses it?
- What was the hardest part, and how did you get past it?
- What would you build differently now?
- What happened after launch? Bugs, changes, maintenance?
You're not judging the code. You're judging the explanation. A real developer describes their own work fluently, owns the messy parts, and lights up on the details. Someone claiming credit for work they didn't do stays vague, and the vagueness is obvious once you push past the first answer. Ask "why" twice in a row and see if the answers stay concrete.
Here's the test that matters most for you specifically: can they explain technical things in plain English? Ask them to explain something from their project, like what a database does or why the app needs a login system, as if you're exactly what you are, a non-technical owner. A developer who can't translate for you in an interview can't translate for you in month four when you need to decide whether a delay is legitimate. You'd be surprised how many strong coders fail this, and for a small business, that failure is disqualifying. You need a developer you can actually talk to.
Pay for a trial project
The single best screen available to a non-technical hirer is a small paid trial. Before committing to a hire or a big contract, pay for one or two weeks of real, bounded work: a small feature, a bug backlog, a report you actually need. Pay a fair rate. Free "test projects" insult good candidates and select for desperate ones.
A trial project tells you things no interview can:
- Do they ask clarifying questions before starting, or disappear and guess?
- Do they give you honest progress updates, including bad news?
- Does the delivered thing actually work when you use it?
- Was the estimate close to reality?
That last one deserves attention. You can't judge code quality, but you can absolutely judge whether someone said "two days" and took nine without warning you. Estimation honesty in a small project predicts estimation honesty in a big one.
Check references on shipped work
Reference checks for developers are only useful if you ask the right questions. Skip "were they good?" and ask about outcomes:
- Did the project ship, and does it still run today?
- Who maintains it now, and was the handoff sane?
- When something went wrong, how did they handle it?
- Would you pay them again, at the same rate?
"Does it still run" is underrated. Plenty of developers can produce a demo. Fewer can produce software that survives two years of real use without its author on retainer. If every past client says the project got rewritten after the developer left, that's your answer.
Red flags you can spot without reading code
- Can't explain simply. Jargon as a shield. If you leave every conversation more confused, that's a choice they're making, and it will cost you money.
- No questions asked. A developer who takes your vague description and says "no problem, I can build that" without asking who the users are, what happens in edge cases, or what matters most is going to build the wrong thing confidently.
- Everything is a rewrite. If their first take on your existing system is "this all needs to be thrown out" before they've spent real time in it, be careful. Sometimes rewrites are right. Usually that instinct means they can't or won't read other people's code.
- No live work to show. Portfolios full of screenshots but nothing you can actually click, no app store listing, no client site, no code repository. Shipped work leaves evidence.
- Estimates with no ranges and no assumptions. Confident single numbers for fuzzy work signal inexperience or sales tactics.
- They resent oversight. Weekly demos of working software are a normal ask. A developer who bristles at showing progress is a developer you'll hear from at the deadline, with bad news.
How to know you got it right
Within the first month or two, a good developer hire feels like this: you see working software regularly, not just status reports. You understand what they tell you. Bad news arrives early with options attached, not late with excuses. And things they finished stay finished. If instead the demos keep slipping, the explanations keep getting more technical, and "done" keeps needing one more week, act on it early. If you'd rather not run this gauntlet alone, this is exactly the kind of hire where having a technical person on your side of the table changes everything. We sit in on developer interviews for clients for that reason, and it usually takes one conversation to sort the builders from the talkers.
Stuck on this, or want it done for you? That's the job.
Email us →