Interviewing a developer when you are not technical

You do not need to read code to hire a good developer. You need to see how they think, how they communicate, and whether they finish what they start. Those things show up in conversation, in past work and in a small real task. Here is how to test for them without pretending to be technical.

Walk through work they have actually shipped

Ask the developer to show you two or three things they built that are live now. Not a portfolio slide. A working site or app you can open while you talk.

Then ask them to walk you through one of them:

• What was the problem the client was trying to solve?
• Which parts did you build yourself, and which did others build?
• What went wrong during the project, and what did you do about it?
• What would you change if you built it again?

Listen for specifics. A developer who built something can tell you why a decision was made, what broke and how it was fixed. Vague answers about 'the team' or 'the process' usually mean they were on the edge of the work.

Ask questions that show how they think

You are not testing syntax. You are testing judgement and communication. Good questions for a non-technical interviewer:

• Explain how you would build this, as if I were a customer. Can they make it clear without jargon?
• What would you need from me to get started? Good developers ask for access, examples and decisions early.
• What could make this take longer than planned? Honest answers name real risks: unclear requirements, third-party integrations, content arriving late.
• How will I know what you did this week? You want a concrete answer, such as a written update or a short demo.
• What would you leave out, or build later? A developer who pushes back on scope is protecting your budget.

If you have a brief, share it before the call. Their questions about it tell you as much as their answers. Our guide on how to write a developer brief helps if you do not have one yet.

Run a small paid trial task

A conversation shows how someone talks. A trial shows how they work. Pick a small, real piece of your project that takes a few hours to a couple of days, and pay for it. Paying keeps it fair and gets you their real effort.

Good trial tasks are self-contained and easy to check: a single page built from a design, a contact form that sends to your email, a small fix on your existing site. Write down what done looks like before they start.

Then judge the whole experience, not only the result:

• Did they ask sensible questions before starting?
• Did they tell you about problems early, or only at the end?
• Did they deliver when they said they would?
• Can you understand their handover note?

An hourly engagement suits a trial well. With us, a developer starts from $10/hr and a senior developer from $25/hr, so a short trial is a small cost next to a wrong long-term hire.

Red flags to watch for

• They cannot show live work, or cannot explain their part in it
• They agree to everything and ask no questions about your brief
• They give a firm price for a vague scope
• They want to keep the code, hosting or domain in their own accounts
• They go quiet for days during the trial, then deliver everything at once
• They blame every past problem on clients or teammates

One flag is worth a question. Two or three together are a reason to keep looking.

Check references properly

Ask for one or two past clients you can speak to directly. A short call beats a written testimonial. Ask them:

• Did the project finish on the timeline and budget you agreed?
• How did they handle changes and problems?
• Would you hire them again for your next project?

The last question matters most. Hesitation is an answer too.

Decide on evidence, not confidence

Put the three sources side by side: the walkthrough, the trial and the references. A developer who is clear in conversation, steady in the trial and recommended by past clients is a safer hire than one who simply interviews well. If you would rather have help with the vetting, see how it works or read what to check before hiring a developer.