How to Hire a Software Developer
For the founder who cannot read code and is about to hire the person who will build the thing the business runs on. How to judge the thinking when you cannot judge the work.
By Umair Ali · ·
This is how to hire a software developer when you cannot read the code yourself. If you can read code, you already know how to judge a developer, and most of this will be obvious. This is for the other person: the one making the most consequential technical hire of the company's life without the ability to inspect the work itself, for whom every candidate sounds confident and uses words you half-recognise, with no way to tell the strong one from the one who is merely good at interviews.
That is the real problem with a first developer hire. It is not finding people. It is that you are being asked to judge work in a language you do not speak.
This guide is about hiring a developer onto your team or as a long-term build partner. It is not about renting a freelancer for a one-off job through a marketplace, which is a different decision with different rules. If that is what you need, a vetted marketplace will serve you better than anything here.
First, decide what you are actually hiring
Before the job description, settle one question: employee, long-term contractor, or agency. These solve different problems, and the wrong pick is expensive in a way that is hard to reverse.
An agency suits a defined project with a clear end. They are fast and self-managing, and the wrong choice for a product you intend to keep building, because the people who understand your code leave when the contract does and you own none of that knowledge.
An employee or long-term contractor suits ongoing work where the code is the business. You are buying someone who accumulates understanding of your product and stays, rather than a deliverable handed over at the end. For a first developer on something you plan to grow, this is almost always the better call, even though it is slower and more commitment up front. The exception: if you cannot yet describe the work clearly, a short contract to prove the work is real, before converting it to a permanent role, is safer.
Write the role around an outcome, not a stack
The most common mistake in a developer job post is a list of fifteen technologies. It feels rigorous. It is mostly noise.
A wishlist of tools scares off strong generalists who could learn your stack in a fortnight but do not tick every box today, and it attracts people who pattern-match keywords onto their CV, the exact behaviour you are trying to screen out later.
Write the outcome instead: what must exist, or work, or be fixed, in the first few months. "We have a working payment system our customers can trust" tells a good developer what the job is and lets them tell you how they would build it. The specific tools matter far less than you have been led to believe, because the underlying skill is the judgment about how and when to use a tool, and that judgment outlasts any single language or framework. Name the two or three must-haves that are genuinely non-negotiable, mark the rest as nice to have, and be honest about which is which. Most of your list is a preference wearing the costume of a requirement.
The myth to drop: you cannot judge the code, but you can judge the thinking
Here is where the non-technical founder goes wrong, and the advice online makes it worse. The standard guidance says look at their GitHub, give them a coding test, check their portfolio. For your situation, most of that is weaker than it sounds.
Public code is a poor signal for many good developers. Their best work belongs to past employers and is private, so their profile is empty or a few half-finished side projects that say nothing about how they work under real conditions. An empty GitHub usually just means the person has been busy being employed, their strongest work locked inside jobs they cannot show you.
Take-home tests have their own problem. They mostly measure who has a free weekend, not who is good, and strong candidates with other offers often decline them. Even when someone completes one, you cannot read the result, so you are back where you started, having spent someone's Saturday for nothing. If the role is genuinely hands-on and you have someone technical who can review the output, a small, paid, time-boxed task can still be worth it, kept under a couple of hours and paid for, because asking for free labour filters for the desperate, not the skilled. This is the one part of developer hiring where I do not think there is a single right answer, and anyone who says there obviously is has not hired across enough situations.
So drop the idea that judging a developer requires evaluating code. It requires evaluating reasoning, which you can assess in plain English without knowing a single programming language. A genuinely good developer can explain a hard technical decision to you, a non-expert, in a way you understand. One who is repeating what they have absorbed cannot, because the jargon is load-bearing, holding up an understanding that is not there.
What to actually ask
Build the interview around explanation and decisions, not trivia. You are testing whether the thinking is real, and you can hear that even when you cannot read the code.
- Explain something you built recently as if I do not work in tech. What did it do, and why did it need building?
- Walk me through a technical decision where you had two reasonable options. Why did you pick the one you picked?
- What is something you chose not to build, or deliberately kept simple, and why?
- Tell me about a bug or a failure that was your fault. What was it, and what did you change afterwards?
- If I hired a weak developer for this role, what would I fail to notice for six months?
That last question is the most useful one you can ask. It makes the candidate describe the exact thing you cannot see yourself, which only real depth can answer, and hands you a checklist for judging everyone else.
Listen for two things. First, whether the explanation gets clearer as they go or vaguer. Real understanding simplifies under questioning; bluffing gets more complicated, because the person is adding words to cover a gap. Second, whether they can talk about trade-offs and failures. A developer who presents every past decision as obviously correct is either inexperienced or not being straight, because real engineering is a chain of imperfect choices, and good ones know it.
We nearly made this mistake ourselves. A candidate came to us with an empty profile and a thin CV, the kind you skim straight past, and we had half-decided to pass before we even spoke to him. In the interview he turned out to be one of the sharpest problem-solvers in the batch. A strong CV is not a strong candidate, and a thin one often just means someone put their effort into the work rather than the paperwork. We only caught it because we were looking at his actual interview answers next to the CV, not the CV alone, which is exactly what BestHire now puts in front of us.
The part you cannot do alone
Everything above works for one candidate in a room. The trouble starts earlier, at the pile.
You post the role and a hundred people apply, more if the market is soft. Every CV is a set of claims, and the only honest way to know which are real is the thing this guide describes: get the person to explain their work, then follow up until you can tell whether the understanding is there. Across a hundred applicants, in a field you cannot read, that is not something one founder can do. So most fall back on the two signals they can see, the CV's writing quality and the company names on it, both close to useless for predicting whether someone can build.
This is the gap BestHire is built for, and developer hiring is where it matters most, because it is where your judgment is thinnest. You post the role and get one link that collects every applicant. It sorts them on what they actually did rather than on keyword matches, so a strong developer who used different words is not thrown out for it. Then it does the part you cannot: it interviews every applicant who fits, not a shortlist you guessed at first, each interview built from that person's own CV and pressing on the specific claims they made. It is built to probe depth in a field you do not know yourself, which is the whole reason it helps here. It reads only what the person says, never their face, voice, or accent. Then it ranks them by whose claims held up and hands you a short list with the evidence attached: the CV line, and the answer that backed it or broke it. It rejects nobody; you make every call. It does the reading and the pressing, in a language you do not speak, so the five you sit down with are the five worth your time.
The interview, once you have the five
By now the technical question is mostly answered, so the conversation is short and does a different job: what a transcript cannot tell you. How they handle disagreement. Whether they can say plainly what they do not know, one of the strongest and rarest signals in a developer. Whether you can imagine explaining a problem to this person at nine at night when something is broken. No evidence trail decides that for you. That part is yours.
The short version
- If you cannot read code, stop trying to judge code. Judge the thinking, which you can hear in plain English.
- Decide first whether you want an employee, a contractor, or an agency. They solve different problems.
- Write the role around an outcome, not a list of fifteen technologies.
- The hard part is the pile, not the interview. Get the pile down to five real people first.
This is the developer-specific chapter of a bigger process. The full sequence, from posting the role to making the offer, is in How to Hire Your First Employee.