How to interview a developer when you're not technical

Short answer: to interview a developer when you're not technical, don't try to judge their answers on technical merit. Pick something they have actually built, ask them to explain it, and judge the quality of the explanation: specifics, trade-offs, honesty about mistakes. A person who built something can talk about it in detail. A person who didn't, or doesn't understand it, usually can't.

This works for tech recruiters without an engineering background and for founders hiring their first engineers. You do not need to know the programming language.

Why generic questions fail

Lists of "top 50 developer interview questions" fail non-technical interviewers for two reasons. You can't tell a correct answer from a confident wrong one. And candidates have read the same lists, so the answers are rehearsed.

Questions about the candidate's own work fix both. The candidate is the world's expert on it, so you only need to judge how they talk about it, which you can do. And rehearsed answers don't exist for a project nobody else wrote.

Before the interview: find something to ask about

Spend 10 minutes preparing. Ask the candidate for a project they are proud of, or look at their public work.

1. Open their GitHub profile and look at pinned repositories and recent merged pull requests. Our guide to evaluating a developer's GitHub profile shows what to look for.
2. Pick one or two pieces of work that look real: used by others, changed over time, or reviewed by someone else.
3. Write down three questions about those specific pieces.

DevEval does step 1 to 3 automatically: it only reads code the candidate wrote and suggests interview questions about it. You can do it by hand with the steps above. If the candidate has little public work, ask them to describe a project from a past job instead and use the same questions.

The interview structure (45 minutes)

Time	Part	Purpose
5 min	Role and context	Explain the job, the team, the product. Let them ask questions
15 min	Walk me through something you built	Understand depth and ownership
10 min	Problems and trade-offs	See how they think when things went wrong
10 min	Working with others	Collaboration, feedback, communication
5 min	Their questions	Good candidates ask good questions

Ten questions to ask

About something they built

1. "Pick a project you're proud of. What does it do, and who uses it?"
2. "What was your part, and what did others do?" (Separates ownership from team credit.)
3. "What was the hardest part? How did you decide how to solve it?"
4. "What would you do differently now?" (Strong developers answer instantly and specifically.)

About trade-offs and mistakes

5. "Tell me about a bug that got into production. How did you find it and what did you change afterwards?"
6. "Describe a time you chose a quick solution over a clean one. Why?"
7. "Tell me about a change in your own code that a reviewer pushed back on." (Needs a real code review story. See code review.)

About working with others

8. "How do you explain a technical problem to someone who isn't technical?" (You are that someone. Notice whether they succeed.)
9. "Describe a disagreement with a teammate about how to build something. How did it end?"
10. "What do you want to learn in your next job?"

How to judge answers without technical knowledge

You are listening for four things.

Specifics. Names, numbers, concrete events. "We had a slow page, I found the database was queried 200 times per load, and I changed it to one query" beats "I optimised performance".

Trade-offs. Strong developers say "we could do A or B; I chose A because..." Weak answers describe one path as obvious.

Honesty about limits. Phrases like "I didn't know, so I read the docs and asked Maria" are good signs. Someone who has never been wrong, or never needed help, is not a better developer. They are less honest.

Consistency. Ask a follow-up in different words ten minutes later. A real story survives it. A rehearsed one often changes.

Follow-up prompts that work every time

• "Can you give me an example?"
• "What happened next?"
• "What was the alternative, and why didn't you choose it?"
• "How did you know that worked?"
• "What would a teammate say about that decision?"

Each takes the candidate from a general claim to a specific memory. Memory is hard to fake.

Green flags and red flags

Green flags

• Explains a complex thing in plain language without being asked
• Credits teammates by name
• Describes mistakes without defensiveness
• Asks you about the product, users and team
• Can tell you what they would change in their own work

Red flags

• Cannot explain what their own listed project does
• Uses "we" for everything and cannot say what they personally did
• Answers every question the same way regardless of the example
• Blames others for every problem
• Gets irritated by follow-up questions

A red flag is a reason to ask one more question, not to reject. People get nervous. Give a candidate a chance to recover before you conclude anything.

Don't skip the technical check

Your interview is a first filter. For most roles, an engineer should still do a technical conversation before an offer. If you don't have one, borrow one for an hour: a contractor, an advisor, a friend in the industry. Give them the candidate's own work and your notes so they can go deep in 30 minutes. Compare the options in take-home vs live coding vs GitHub review.

Be fair to the candidate

• Tell them in advance how you will interview them and that you may look at their public code.
• Ask about the work they can share. Many developers have private work they can't show. A thin GitHub profile is not a weak candidate.
• Give the same structure to every candidate so comparison is fair.
• Treat any tool's output, including DevEval's, as one input. A person makes the decision.

Checklist

• Looked at 1 or 2 pieces of the candidate's real work
• Wrote 3 questions about them
• Told the candidate what to expect
• Asked "what was your part?"
• Asked about a mistake and what changed afterwards
• Asked at least three follow-ups
• Noted specifics, trade-offs, honesty and consistency
• Arranged a technical check with an engineer before any offer

Frequently asked questions

Can I really assess a developer without knowing code? You can assess how they explain, own and reflect on their work. You can't verify technical correctness. Pair your interview with an engineer's review before an offer.

What if the candidate has no GitHub? Ask about a past project and use the same questions. Ask for a sample they are allowed to share.

Should I use a coding test as well? It can be useful. See how to screen developers without a coding test for when to skip one.