Engineering • Leadership

How to Run Technical Interviews When You Are Not Technical

You do not need to write code to hire good engineers. You need to know what to look for, what to listen for, and how to structure a process that actually works.

Mike Tempest • 9 min read • 28 March 2026

The Two Mistakes Non-Technical Founders Make

I see this pattern constantly. A non-technical founder needs to hire their first engineer (or their first few engineers) and they fall into one of two traps.

Trap one: outsource the whole thing. They hand the interview process entirely to a recruiter, a technical friend, or an agency. The candidate gets hired based on someone else's judgement, and the founder has no real sense of who they have brought into the business. Six months later, the engineer is technically competent but a terrible cultural fit, or they are building the wrong thing because nobody assessed whether they actually understood the product.

Trap two: bluff it. The founder tries to run the technical interview themselves, asking questions they found on Google, nodding along to answers they do not understand. Good candidates see through this immediately. Bad candidates exploit it. Either way, the founder ends up making decisions based on confidence and charisma rather than competence.

There is a better way. You do not need to code to run an effective interview process. But you do need to understand what you are actually evaluating, structure the process properly, and know which parts you should own and which parts you should delegate.

What You Are Actually Evaluating

Forget leetcode puzzles and whiteboard algorithms. For an early-stage startup, here is what actually matters.

Problem-Solving Approach

How do they break down a vague problem? Do they ask clarifying questions or charge ahead with assumptions? Do they think about edge cases and trade-offs, or jump to the first solution that comes to mind? You can assess all of this without understanding the technical details.

Communication Clarity

Can they explain technical concepts to someone who is not technical? This is not a nice-to-have at an early-stage startup. It is essential. If your first engineer cannot communicate with you, with customers, and with future hires, you have a problem. The best engineers I have worked with can explain complex systems in plain language without being condescending.

Pragmatism vs Perfectionism

Startups need engineers who ship. That does not mean sloppy work. It means understanding that a working feature in users' hands this week is worth more than a perfectly architected feature next month. Listen for how they talk about trade-offs, deadlines, and "good enough". If every answer involves building the perfect system from scratch, they are not a startup engineer.

Business Context Awareness

Do they ask about the product? The users? The business model? Engineers who only care about the technology and not the problem it solves will build impressive systems that nobody needs. Your first engineering hire needs to care about why, not just how.

Cultural Fit and Startup Tolerance

Working at a startup is fundamentally different from working at a large company. Requirements change weekly. There is no dedicated QA team. You might be deploying code on a Friday afternoon because a customer needs it. Some excellent engineers are terrible in this environment, and that is fine. But you need to know before you hire them.

An Interview Structure That Actually Works

Three stages, roughly two hours total. Fast enough to not lose good candidates, thorough enough to avoid expensive mistakes.

Stage 1

30 Minutes With You: Values, Vision, and Context

This is your interview to lead. You are not assessing technical skills here. You are doing three things: selling the opportunity, explaining what you actually need, and getting a sense of who this person is.

Talk about the product vision. Explain where the company is and where it is going. Be honest about the stage you are at and the challenges ahead. Good candidates appreciate honesty. Bad ones want to hear that everything is perfect.

Pay attention to the questions they ask. Are they curious about the product and the users? Or are they only asking about the tech stack, remote work policy, and equity? Neither set of questions is wrong, but it tells you what they care about.

Stage 2

45 Minutes Technical: Run by an Expert, Observed by You

This is where you bring in a fractional CTO, a technical advisor, or a senior engineer from your network. They lead the technical assessment. But here is the critical part: you sit in.

You will not understand everything that is discussed. That is fine. You are listening for something different. Can the candidate explain their reasoning? Do they acknowledge trade-offs? Do they ask good questions about constraints? Do they get defensive when challenged, or do they engage thoughtfully?

After the session, debrief with your technical assessor. Ask them to explain not just whether the candidate is technically strong, but how they approached problems, what their weaknesses are, and whether they would be effective in a startup environment.

Stage 3

30 Minutes With You Again: Culture, Questions, and Compensation

The final conversation is yours again. This is where you discuss working style, expectations, compensation, and give the candidate space to ask their remaining questions. It is also your chance to address anything that came up during the technical session.

This is where you assess startup tolerance. Ask about their experience with ambiguity, changing priorities, and wearing multiple hats. Ask what their ideal working environment looks like and be honest about how yours compares. If you are building your first engineering team, you need someone who thrives with autonomy, not someone who needs a product manager, a designer, and a sprint planning ceremony to function.

Questions Non-Technical Founders Can Ask Effectively

These questions do not require technical knowledge to ask or evaluate. The quality of the answer tells you everything you need to know.

"Walk me through how you would build [a feature from your product]"

You are not evaluating whether their technical approach is correct. You are evaluating whether they ask clarifying questions, think about the user, consider trade-offs, and communicate their thinking clearly. A strong candidate will ask who the users are, what the constraints are, and what "done" looks like before they start talking about implementation.

"Tell me about a time you shipped something you were not proud of"

Every experienced engineer has done this. The good ones can articulate why they made the trade-off, what the consequences were, and what they learned. If someone claims they have never shipped anything they were not proud of, they are either lying or they have never worked under real constraints.

"How do you decide when something is good enough?"

This is a pragmatism test. You want to hear about balancing quality with speed, about understanding what the user actually needs versus what would be technically elegant, about knowing when to cut scope. If the answer is "I never compromise on quality", this person will struggle at a startup.

"What would you do in your first two weeks here?"

Strong candidates talk about understanding the codebase, talking to users or stakeholders, identifying quick wins, and building relationships with the team. Weak candidates talk about rewriting the architecture or introducing new frameworks. If their first instinct is to change everything, they are not listening to the problem. See also: red flags when hiring your first engineer.

"What questions do you have about our product and our users?"

This is not really a question. It is a test. Engineers who care about the business will have genuine, thoughtful questions about what you are building and why. Engineers who only care about the technology will ask about the tech stack, deployment pipeline, and whether they can use their favourite framework. Both tell you something important.

Red Flags You Can Spot Without Writing Code

You do not need to understand algorithms to spot these warning signs. They are all about behaviour, communication, and attitude.

Cannot Explain Things Simply

If a candidate cannot explain their previous work, their technical decisions, or their approach to a problem without heavy jargon, that is a problem. Either they do not truly understand what they are talking about, or they cannot communicate with non-technical colleagues. At an early-stage startup, both are disqualifying.

Dismisses Business Context

"I just want to write code" sounds admirable, but at a startup it is a liability. Your first engineers need to understand why they are building what they are building. If a candidate shows no interest in the product, the market, or the users, they will build technically elegant solutions to the wrong problems.

Only Wants Greenfield Work

Building new things from scratch is fun. Maintaining, improving, and fixing existing systems is where most of the actual work happens. If a candidate only gets excited about building new features and visibly deflates when you mention legacy code, bug fixes, or maintaining existing systems, they will not last.

No Questions About the Product or Users

An engineer who does not ask about what you are building, who you are building it for, and why, is telling you exactly where their priorities are. At a large company with a dedicated product team, this might be fine. At a startup where the engineer is half the product team, it is not.

Over-Indexes on Tools and Frameworks

Beware the candidate whose entire identity is wrapped up in a specific technology. "I am a React developer" or "I only work with Kubernetes" are warning signs. Good engineers use the right tool for the job and can adapt. Your startup's needs will change, and you need people who can change with them. This matters especially when you are deciding on your technical leadership structure.

The Technical Assessment: Get Help, but Get It Right

You need someone technical to assess coding ability. There is no way around this. But you have options that do not require a full-time CTO on staff.

A fractional CTO can run the technical portion of your interview process. A trusted technical advisor or mentor can do a one-off assessment. A senior engineer from your network might help as a favour. The point is: get someone competent to assess the technical skills, but make sure they understand what your startup actually needs.

For the assessment itself, skip the abstract algorithm puzzles. Use a take-home project based on a real problem from your product. It does not need to be your actual codebase, but it should reflect the kind of work the candidate will actually do. Keep it to 2 to 4 hours maximum. Anything longer and you will lose good candidates who have other options and do not want to spend a weekend on a free trial.

When you review the take-home with your technical assessor, ask them to evaluate not just whether the code works, but how the candidate made decisions. Did they over-engineer it? Did they cut corners in dangerous places? Did they write code that someone else could understand and maintain? These qualities matter more than raw technical brilliance in a startup context.

Reference Checks: Actually Do Them

I am consistently surprised by how many founders skip reference checks. They will spend weeks on the interview process and then not bother to call the two people who can actually tell them what working with this person is like on a Tuesday afternoon when things are going wrong.

When you do call references, do not just ask about output. Ask about collaboration. How did this person handle disagreements? Did they communicate well with non-technical stakeholders? How did they respond to changing requirements or tight deadlines? Did they mentor junior team members or hoard knowledge?

The answers to these questions are worth more than any interview performance. People can practise for interviews. They cannot fake six months of working relationships.

And if a candidate cannot provide references, that is a red flag worth taking seriously.

Common Mistakes That Cost Founders Months

Hiring the Most Impressive CV Instead of the Best Fit

A candidate from Google or Meta sounds impressive. But someone who has spent ten years in a large company with dedicated infrastructure teams, product managers, designers, and QA engineers may struggle enormously in a startup where they need to do all of those things themselves. Experience at scale is different from experience at speed. For early-stage hires, startup experience often matters more than brand-name employers.

Not Checking for Startup Tolerance

Some people thrive in ambiguity. Others need structure to function. Neither is wrong, but your startup almost certainly cannot provide the structure that a large company can. Ask directly about their experience with unclear requirements, shifting priorities, and working without a safety net. If they have never done it, you are paying to find out whether they can.

Letting Candidates Interview You

This is subtle but common. A confident, articulate candidate can flip the dynamic so that you feel like you are the one being assessed. You end up selling the opportunity rather than evaluating the person. This happens more often with non-technical founders because the knowledge asymmetry makes you feel like the candidate has the power. They do not. You are the one writing the cheque. Stay in control of the process.

Moving Too Slowly

Good engineers have options. If your interview process takes three weeks and four rounds, you will lose candidates to companies that move faster. The three-stage process described above can be completed in a week. If you have found someone good, make a decision and make an offer. Deliberating for another two weeks while you "see who else applies" is how you lose your best candidate.

The Bottom Line

Running technical interviews as a non-technical founder is not about pretending to be technical. It is about knowing which parts of the assessment you are uniquely qualified to lead and which parts you need help with.

You are the best person to assess values alignment, communication skills, product curiosity, and cultural fit. You need help assessing coding ability and technical decision-making. Structure your process accordingly, and you will make better hiring decisions than most technical founders who focus entirely on algorithms and ignore everything else.

The cost of a bad first engineering hire is enormous. Not just the salary, but the 3 to 6 months of lost momentum, the code that needs to be rewritten, and the damage to team morale if you have to let someone go. Getting the interview process right is one of the highest-leverage things you can do as a founder.

You do not need to code. You need to be structured, honest, and willing to get help where you need it. That is not a weakness. That is good leadership.

If you need help structuring your interview process or assessing technical candidates, a fractional CPTO can run the technical assessment and help you build your first engineering team the right way. For more on hiring, see the related articles below.

EngineeringLeadership

Need help hiring your first engineer?

Get an experienced Fractional CPTO to run technical assessments, structure your interview process, and help you make the right hire. No guesswork, no bluffing.

Book a Free Day Get in Touch

Frequently Asked Questions

Can a non-technical founder really run a technical interview?

Yes. You are not assessing whether someone can write a sorting algorithm. You are assessing whether they can communicate clearly, solve problems pragmatically, understand your business context, and work well with your team. These are things any founder can evaluate. Pair with a fractional CTO or senior technical advisor for the coding assessment, but you should lead the culture and values portions yourself.

How do I avoid getting bluffed by a technically impressive candidate?

Ask them to explain things in plain language. If they cannot explain what they built, why they built it that way, and what the trade-offs were without resorting to jargon, that is a red flag. Also ask about failures and compromises. Strong engineers talk openly about mistakes and trade-offs. Weak ones only talk about successes.

Should I use a take-home test or a live coding interview?

For early-stage startups, a take-home test based on a real problem from your product is far more useful than live coding. It shows how candidates think, write code, and make decisions when they are not under artificial pressure. Keep it to 2 to 4 hours maximum and pay for their time if you can. Live coding tests mostly measure performance anxiety, not engineering ability.

How many interviews should the process have?

Three stages is the sweet spot for early-stage startups. A 30-minute call with you covering values and product vision. A 45-minute technical session run by a senior technical person whilst you sit in. Then a final 30-minute conversation covering culture, questions, and compensation. Any more than this and you will lose good candidates to faster-moving companies.

What if I cannot afford a fractional CTO to help with interviews?

You have options. Ask a technical advisor or mentor to sit in on the technical portion. Use your network to find a senior engineer who will do a one-off assessment as a favour. Some fractional CTOs offer interview-only engagements for a single day rate. The cost of one bad engineering hire far exceeds the cost of getting help with the interview process.

Mike Tempest

Fractional CPTO

Mike has hired and built engineering teams across multiple startups, from first engineer to 20-person departments. As CTO at Risika and Head of Engineering at RefME, he ran hundreds of technical interviews and helped non-technical co-founders develop hiring processes that work. He now provides fractional CPTO services to UK startups, including interview process design and technical candidate assessment.

Learn more about Mike