How to Interview a Developer When You're Not Technical

The instinct of most non-technical founders is to either skip the interview entirely (defer to the CV and a portfolio) or to ask questions they found on a technical interview blog — neither of which reliably identifies whether a developer will work well in your specific context.

Technical interviews conducted by technical people test for technical knowledge. What a non-technical founder actually needs to know is almost entirely different: Can this person solve problems independently? Do they communicate clearly? Will they tell me when something is harder than expected, or will they go silent and miss the deadline?

You can assess all of this without knowing how to write code.

What you're actually evaluating

Before designing your interview, be clear about what matters. For most non-technical founders hiring their first or second remote developer, the four things that predict a good engagement are:

1. Communication clarity — can they explain technical decisions in plain English?
2. Problem-solving approach — do they ask clarifying questions or start building immediately?
3. Track record alignment — have they built things similar to what you need?
4. Red-flag absence — no vague answers, no reluctance to share code, no unrealistic promises

Technical skill matters, but it is secondary to these four — and you have other tools to assess it (see the section on portfolio review and technical screening below).

The structure of an effective interview

A good interview for a non-technical founder runs 45–60 minutes and follows this structure:

Opening (5 minutes): Let them lead. Ask them to walk you through what they have been working on recently. Listen for specificity. A developer who can say "I built a Stripe payment integration for a subscription product — it handled proration when customers upgraded mid-cycle" is demonstrating a very different communication ability from one who says "I worked on an e-commerce project."

Past project deep-dive (15 minutes): Choose one relevant project from their portfolio and ask them to walk you through it end-to-end. The questions to ask:

• What was the hardest technical problem you ran into? (Tests for honesty about difficulty)
• How did you approach it? (Tests for structured thinking)
• What would you do differently now? (Tests for self-awareness and growth)
• How did you communicate progress to the client? (Tests for communication habits)

Scenario questions (15 minutes): Present them with realistic scenarios from your actual project. These are not trick questions — they are tests of judgment and communication. Good scenarios to use:

• "You start a task and realise halfway through that it's more complex than the estimate — it will take three times as long. What do you do?"
• "The client asks for a feature that you think is a bad idea technically. How do you handle it?"
• "You find a bug in code you did not write. The client has not noticed it. What do you do?"

The answers you want are clear, communicative, and show that the developer treats the client as a partner rather than someone to manage.

Your project walkthrough (10 minutes): Explain what you are building. Ask them to reflect back what they understood. Ask what questions they have. The quality of their questions tells you a lot: does this person think about edge cases, security, scalability? Or do they just confirm deliverable dates?

Logistics and expectations (10 minutes): Timezone overlap, availability, how they prefer to receive feedback, what makes an engagement work well for them. A developer who has clear preferences is easier to work with than one who agrees to everything.

How to evaluate communication without technical knowledge

Communication quality is visible to anyone who pays attention. During the interview, note:

• Do they give direct answers to direct questions?
• When they do not know something, do they say so clearly?
• Do they use jargon without explanation, or adapt their language to you?
• Are their examples specific and concrete, or vague and general?

A developer who says "I built an API that does stuff" is communicating differently from one who says "I built a REST API that takes webhook events from Shopify and writes them to a PostgreSQL database — it handles duplicate events by checking order IDs." The second developer is telling you exactly what they did. The first is not.

This also extends to questions they ask you. A developer who asks "What's the budget?" before understanding the problem is signalling something different from one who asks "What happens if the payment fails — does the order cancel or stay pending?"

Technical screening without being technical

You do not need to conduct a technical interview yourself. There are three approaches that work:

Portfolio code review. Ask for a link to a public GitHub repository or sample project. Find a developer friend, a CTO-for-hire on Upwork, or a technical advisor who can spend 30 minutes looking at the code quality. What to ask them to assess: is the code organised, is it documented where necessary, are there tests, does it follow reasonable conventions for the language and framework?

Paid technical test. Give the developer a small, scoped task — build a simple feature, create a data model, write a function — and pay them for it (two to four hours of their time). Evaluate the output for functionality, code clarity, and how they communicated during the task. This is more revealing than any interview question.

Technical account manager. If you are engaging through a staffing company, the technical vetting should happen before you interview. A structured staffing company screens for skill before you ever see a CV. If you still want assurance, ask their technical account manager to review the candidate's code sample.

Red flags to watch for

A few things that should make you pause, regardless of CV quality:

• Overpromising on timelines. A developer who agrees immediately to your timeline without asking what the timeline covers is either not taking it seriously or not being honest.
• No questions about your business. A developer who never asks about what you do, who your users are, or what success looks like is treating this as a commodity task.
• Vague previous work. If they cannot describe a project they supposedly worked on in concrete detail, they likely did not do the work they claim.
• Reluctance to share code samples. Every developer doing serious work has something they can show. Reluctance without a clear reason (NDA, etc.) is unusual.
• References they cannot provide. Ask for one or two previous clients you can contact briefly. A developer with a good track record should have at least one satisfied client who will take a five-minute call.

The follow-up test question

Before ending the interview, ask one question and observe how they respond over the next 24 hours rather than in the room: "I'll send you a brief email tomorrow with a quick question about our project. No rush — whenever works." Then send a simple question about their experience with a technology you will use.

Their reply speed, the quality of their answer, and how they structure their response tells you more about their day-to-day communication than the interview itself.

The guide on managing remote developers covers what good working patterns look like once you have hired — worth reading before you make the hire so you are designing for the engagement, not discovering it.

Codalyst Tech's staffing model handles technical vetting before you interview — so by the time you talk to a candidate, the skill question is already answered and the interview is purely about fit.