How to Interview a Developer When You're Not Technical

How to Interview a Developer When You're Not Technical

You do not need to know how to code to interview a developer well. The skills that separate good developers from poor ones are mostly visible to anyone who knows what to look for.

Technical interviews conducted by non-technical founders often focus on the wrong things: trying to ask technical questions they do not fully understand, or deferring entirely to a technical test that scores code but misses the qualities that determine whether someone will work well in your organisation.

This guide focuses on what you can actually evaluate, how to evaluate it, and which signals are most predictive of success.

What You Are Actually Trying to Assess

The qualities that determine whether a developer will produce good outcomes for your business:

Communication. Can they explain what they built to someone who does not write code? Remote work is primarily written and async. A developer who communicates well in writing, produces clear documentation, and articulates blockers specifically is more valuable than one who codes brilliantly but communicates ambiguously.

Track record. Do they have a portfolio of shipped, working software? Not code samples, not GitHub projects with 10 commits, but finished things that real people have used. Shipping requires a different set of skills from writing code, and many developers who write good code struggle to bring software to a production state with real users.

Scope discipline. How do they handle unclear requirements? Do they ask clarifying questions before starting, or do they fill in the gaps with their own assumptions and build the wrong thing efficiently?

Honesty under pressure. What do they say when a project went wrong? Can they discuss failure clearly and what they learned from it? Developers who cannot discuss failure either have not had any (unlikely) or cannot be honest about it (more likely and worse).

Estimation accuracy. When you describe a feature, do they give you a specific estimate or a vague range that hedges against accountability? Experienced developers ask clarifying questions before estimating and provide ranges with named assumptions.

None of these require you to read code to evaluate.

Portfolio Evaluation Without Technical Knowledge

Before the interview, ask for two or three examples of shipped work. Links to live products, not GitHub repositories.

Try to use the software. Ask yourself:

Does it load reasonably quickly? (Performance is partially a developer responsibility)

Does it handle errors gracefully? Try clicking things you are not supposed to, leaving required fields empty, using it on your phone. Does it break, or does it handle edge cases reasonably?

Is the interface coherent? Not beautiful, necessarily, but does it behave consistently? Are similar actions handled similarly throughout?

Can you accomplish the core task it is designed for? Actually use it. Register, log in, do the main thing. Does it work?

Working software that you can actually use tells you more than any code review.

The Five Questions That Matter

"Show me something you built end-to-end and walk me through it."

This surfaces: can they talk about their own work clearly? Can they explain technical decisions to a non-technical person? Is the project real and complete? Listen for specificity. Vague descriptions suggest the project is less finished than presented.

"Tell me about a project that did not go as planned. What happened and what did you do?"

Every developer has a project that went wrong. The question is what they did about it and whether they can discuss it honestly. Listen for: they acknowledge their own role in the failure, they describe specific steps they took, they identify what they would do differently. Red flags: defensiveness, blaming external factors entirely, no acknowledgement of their own contribution.

"If I described a feature to you in a few sentences right now, what would you do before you started coding?"

The correct answer involves asking clarifying questions: Who uses this feature? What happens when X edge case occurs? What does success look like? What is already in place that this connects to? A developer who would start coding immediately without clarifying the requirements will build the wrong thing with enthusiasm.

"How do you estimate how long a feature takes?"

Experienced developers ask clarifying questions before estimating. They give ranges with named assumptions: "If the API integration is straightforward and the design is already done, two to three days. If the API is poorly documented or we need to build the data model from scratch, five to eight days." Vague non-answers ("hard to say without knowing more") without attempts to clarify is a weak answer. Confident specific estimates without any questions is overconfidence.

"What does your typical code review process look like?"

This reveals process discipline. Developers who have submitted their work for code review before understand why it matters. Look for: they describe what they check before submitting a PR, they describe how they respond to review feedback, they have opinions about what good review looks like. Developers who have never worked in a code review culture are higher risk for solo-style work habits.

The Written Communication Test

After the interview, send a follow-up question by email or Slack. Something that requires a meaningful response.

"Following up from our conversation: how would you approach the database schema for the project we discussed? What would be your main concerns?"

Observe: Does the response address the question specifically? Is it clear and well-structured? Does it come back in a reasonable timeframe? Are there any red flags in the writing (confusing phrasing, evasive answers)?

Written communication quality is the most predictive signal for remote work success that most interviews do not test. This test is simple and reveals a lot.

The Trial Project

No interview process predicts performance as reliably as a paid trial project. A one to two week paid engagement on a representative piece of real work tells you:

• How they handle a written brief
• How they ask questions when blocked
• The quality and clarity of their code (which you can have a technical advisor review)
• Whether they communicate proactively or go quiet when struggling
• Whether the work is delivered at the quality and timeline they estimated

Make the trial project representative of real work. Not a toy problem, not a generic coding challenge. A small but real task from your actual backlog, with a written brief and defined acceptance criteria.

Pay for the trial. Unpaid work tests create poor candidates. Paid trials attract serious developers and give you the legal right to the output.

Red Flags to Watch For

• Cannot explain their past work in plain language to a non-technical person
• Portfolio of started but never-shipped projects
• Defensive responses to questions about failure
• Unwillingness to ask clarifying questions before starting
• Vague estimates that avoid commitment without asking questions
• Written communication that is confusing or evasive
• Strong opinions on technology without evidence of shipped work using it

The single most consistent red flag is confident, detailed technical discussion without any evidence of a shipped product that uses the technologies described.

For help finding and vetting developers that pass these criteria, our staffing service conducts structured technical and communication assessments before presenting any candidate. Contact us to discuss your hiring needs.