How to Hire a Developer When You're Not Technical

The moment you realise you're out of your depth

You post the job, the CVs come in, and every single one lists frameworks you've never heard of. Someone claims five years of "full-stack development with scalable microservices architecture" and you have no idea if that's impressive or something they read off a tutorial site an hour before the interview. You nod along in the call. You have no way to push back.

This is normal. Most people running a 10–200 person company are not developers, and most of them still need to hire one. The good news: you don't need to learn to code to hire well. You need to stop trying to judge the code and start judging the evidence around it.

Don't fake technical fluency — it backfires

Candidates can tell when you're bluffing. Asking "so tell me about your experience with Kubernetes" and then just saying "great, great" no matter what they answer teaches a sharp candidate that this interview has no real bar. The ones who can talk fluently but can't deliver will sail through. The quiet, competent ones who assume you're actually checking will undersell themselves.

Be honest about it instead. "I'm not technical, so I'm going to ask you to explain things in plain language and I'm going to lean on someone who is technical for part of this process." This isn't weakness — it's the same thing a competent hiring manager does when hiring in any field they don't personally practice.

Borrow someone else's technical eyes — for one hour, not the whole process

You don't need a full-time technical co-founder to hire well. You need one hour of a developer's time, twice: once to help you write the job description and screening questions, and once to sit in on a final-round conversation or review a work sample.

Who this can be:

• A freelance developer you pay for two hours of consulting
• A friend or advisor who's built software before
• A contractor you already use for something else

What you ask them to do is narrow: "Look at this candidate's answer to this specific question and tell me if it holds up." Not "vet this person for me" — that's too vague and too much to ask of a favour.

Ask candidates to explain their own work, not hypotheticals

A developer who genuinely built something can explain it in plain English, at whatever level of detail you push for. Someone padding their CV usually can't go past the surface.

Good questions, in order of how much they reveal:

1. "Walk me through something you built that you're proud of. What did it do, and what was your part in it?"
2. "What was the hardest technical problem in that project, and how did you figure it out?"
3. "If I asked the other engineers on that team what it was like working with you, what would they say — and why?"
4. "Tell me about a time your code broke something in production. What happened and what did you do?"

The fourth question does the most work. Nearly every real developer has broken something. Someone who says "that's never happened to me" after a few years of claimed experience is either lying or has never shipped anything that mattered.

Use a small, real work sample

You don't need a candidate to build a whole feature for free. A short, scoped task — something that takes them 60–90 minutes, closely resembling actual work they'd do in the role — tells you more than an hour of conversation.

Keep it fair:

• Pay for it, or make it genuinely small enough that unpaid is reasonable (most candidates will tell you which is which)
• Give the same task to everyone at that stage
• Ask them to talk you through their own solution afterwards — this is where you catch someone who had help they didn't mention

If you don't have the technical judgement to review the output yourself, this is exactly the moment to spend your one hour of borrowed technical time.

If you'd rather not build a task from scratch, a calibrated technical screening test can do a first pass before you get to this stage — AssessFit runs adaptive tests across a range of technical skills so you're not sending every applicant straight to your one technical reviewer.

Check what they shipped, not what they claim to know

A CV full of technology names tells you what someone has touched, not what they're good at. Ask for evidence instead:

• A GitHub profile, portfolio, or link to something live they built
• The name of the company and product, so you can look at it yourself
• What percentage of a project was actually theirs versus a team's

Don't be impressed by a long list of tools. Be interested in one or two things they can go deep on. Depth is the signal; breadth of buzzwords is often the opposite of it.

Reference checks: ask about delivery, not skill

You can't ask a reference "was their code good?" and expect a useful answer unless the reference is also technical — and even then, it's a soft, generous question people rarely push back on.

Ask instead:

• "Did they finish what they said they'd finish, on the timeline they estimated?"
• "When something went wrong, did they tell you early or did you find out later?"
• "Would you hand them something ambiguous and trust them to figure it out, or does everything need to be spelled out?"

These questions don't require the reference to know code either. They require the reference to have worked alongside this person, which is a much lower bar to get honest answers on.

The honest limit here

None of this replaces having a technical person you trust, eventually. If this hire is your first engineer and there's genuinely nobody in your network who can sanity-check them, that's worth naming as a risk out loud — to yourself, and possibly to an early investor or advisor who might know someone. A 90-day probation period with clear, non-technical delivery milestones (did the thing ship, did it work, did users complain) is your backstop if the hire turns out weaker than the interview suggested.

You're not trying to become a developer. You're trying to build a process that catches the difference between someone who's built things and someone who's memorised the words for it.