How to hire your first developer when you can't read code

Hiring your first developer is hard for a simple reason: you're judging skills you can't evaluate directly. Confident candidates can sound great and deliver little. Quiet, excellent ones can undersell themselves.

You can't become an engineer before you hire one. You can, however, run a process that relies on evidence instead of gut feel.

Decide what kind of developer you need

"A developer" is too vague. Before writing a job post, answer a few questions in plain language:

• What will they build first? A web app, a mobile app, an internal tool, or improvements to an existing prototype.
• Is there existing code? Someone joining an AI-generated codebase needs different strengths than someone starting fresh.
• How much will they decide alone? Your first developer often chooses the stack, the hosting and the structure.
• Full-time, part-time, or project-based? Each fits a different stage and budget.

Your first hire should usually be a generalist who can work across the frontend, backend and database, and who is comfortable making decisions without a senior engineer above them.

Look for evidence, not claims

Resumes and interviews are easy to polish. Ask for things that are harder to fake:

1. Live products they built or significantly contributed to. Use them. Ask what they'd do differently now.
2. Code samples or public repositories, which a technical friend or advisor can skim for you.
3. References from past clients or employers, especially non-technical ones who can speak to communication and reliability.
4. Their explanation of a past technical decision. Good developers can explain trade-offs in plain language.

Interview questions that work without technical knowledge

You don't need to quiz anyone on algorithms. These questions reveal judgment, honesty and communication, which matter most in a first hire:

• "Walk me through a project that went wrong. What happened and what did you do?"
• "How would you approach building our first version? What would you leave out?"
• "How do you make sure what you build is secure?"
• "How should progress be reported each week?"
• "What would you need from me to do your best work?"

Listen for specifics. Strong candidates ask questions back, push back on scope and admit what they don't know. Be cautious of anyone who promises everything quickly and never mentions a risk.

Run a short paid trial

The best predictor of how someone will work is watching them work. Before any long commitment, give your top one or two candidates a small, paid, real task with a clear deadline.

• Pick something useful and contained, like one feature, a bug fix or a small internal tool.
• Pay fairly for their time. Unpaid tests put off the people you most want.
• Judge communication as much as output: did they ask good questions, flag problems early and deliver what they said?
• Have someone technical review the result if you can.

A trial that goes badly is cheap. A full-time hire that goes badly costs months.

Red flags to take seriously

• They want the code in their own accounts, or resist giving you admin access.
• They can't or won't explain decisions in plain language.
• Estimates are vague, or always "almost done."
• They dismiss security, testing or backups as unnecessary for now.
• They push you to rebuild something that works, without a clear reason.
• They go quiet for days without updates.

Protect yourself from day one

Whatever happens with the hire, set things up so the company never depends on one person's goodwill.

1. Create the code repository, hosting, database and domain accounts under the company, then invite the developer.
2. Sign a contract that assigns all IP to the company and covers confidentiality.
3. Agree on a simple weekly rhythm: what was done, what's next, what's blocked.
4. Ask for a short README and setup notes as part of the work, not as an afterthought.
5. Keep a shared password manager so nothing lives only in their head.

Get a second set of eyes

The hardest part is knowing whether the work is good after they start. A trusted technical advisor who can review the code occasionally, sit in on the final interview and sanity-check big decisions removes most of the guesswork.

This doesn't need to be a full-time role. A few hours at the right moments, during hiring and in the first months, protects the most important early investment you'll make.

Deeraf's On Call service is built for this: help defining the role, a technical voice in interviews and trials, and ongoing code review once your developer starts.