# How to Interview a CTO Candidate When You Don't Understand the Code
A founder I work with was interviewing CTO candidates for her Series A-stage company. She had raised $3M, had 40,000 users, and needed someone to build and lead a 12-person engineering team. She asked me to help her run the interviews.
She had been focused on the technical questions - asking candidates about their favorite databases, their opinions on microservices, their experience with specific frameworks. The candidates gave confident answers she couldn't evaluate. She had no idea who was actually good.
I changed her interview process entirely. We stopped asking technical questions and started asking questions about decision-making, communication, and leadership. She made her hire six weeks later. Two years in, that CTO has built one of the most functional engineering teams I've seen at her stage.
Here's how to interview a CTO when you can't evaluate the code they've written.
What You're Actually Evaluating
The instinct to ask technical questions in a CTO interview comes from wanting to verify competence. But CTO competence at the level you need is not primarily technical. The three things that determine whether a CTO will succeed in a startup context are:
How they communicate technical complexity to non-technical people. As a non-technical founder, your CTO's ability to explain things to you is not a nice-to-have - it's how you'll run the company together.
How they make decisions under uncertainty with incomplete information. Startups never have enough information to make technically perfect decisions. A CTO who needs certainty before acting will slow you down. A CTO who makes reasonable bets, communicates the tradeoffs, and moves fast is what you need.
How they hire and develop engineers. Your CTO will make your engineering team. Their hiring judgment and management style will determine your culture, your retention, and your output for years.
None of these require you to understand code to evaluate.
The Communication Test
Start every CTO interview with this: "Explain our core technical architecture to me as if I have no technical background."
You can evaluate the answer even without technical knowledge. A good CTO will:
- Ask what you already know before explaining
- Use analogies to things you understand
- Start with the high-level picture before going into details
- Check whether you're following and adjust
- Be able to describe it in 5 minutes or less
A poor CTO will:
- Immediately dive into technical terminology
- Use jargon without defining it
- Get lost in the weeds and lose the narrative
- Give you a 20-minute monologue without checking comprehension
This test predicts how they'll communicate with you when things go wrong at 11pm on a Friday. The clarity of explanation under calm conditions is always better than under stress. If they can't explain clearly in an interview, they won't be able to explain clearly in a crisis.
Decision-Making Questions
Ask candidates to walk you through a significant technical decision they made that turned out to be wrong. Not a small bug - a real architectural or strategy decision that cost their team time or money.
What you're evaluating:
Ownership. Do they take responsibility or blame the team, the tools, the requirements, or the timeline? A CTO who makes decisions that don't work out is normal. A CTO who never owns those decisions is a problem.
Learning. Can they articulate specifically what they would do differently? Vague "I would communicate better" answers are a red flag. Specific "I would have done a technical spike before committing to the approach, because the uncertainty was too high" answers show genuine reflection.
Self-awareness. Do they recognize the decision as wrong, or do they rationalize it as right given the information they had? Both can be valid - but they should know the difference.
Follow up with: "Tell me about a time you overruled a technical recommendation from your team. What was the outcome?" This reveals whether they can make judgment calls against technical consensus - a key CTO skill - and whether they can do it in a way that doesn't destroy team trust.
Architecture Thinking Questions
You don't need to evaluate whether their architecture answers are technically optimal. You need to evaluate whether they think in the right dimensions.
"If we had to double our engineering team in six months, what would you do differently in how we build the product today?"
Good answers consider: documentation (more people need to be able to understand the system), modularity (a larger team needs clearer ownership boundaries), process (more people means more coordination overhead), and architecture choices that facilitate parallel work.
Bad answers are either "nothing, we're building it right" (overconfidence) or a technical wish-list without prioritization (doesn't understand the business constraints).
"If our biggest technical competitor announced they were cutting their prices by 50% tomorrow and you needed to ship three major features in two months to compete, how would you approach that?"
This question has no right answer. What you're evaluating is their prioritization instincts, their understanding of the cost of shortcuts, and their ability to work under business pressure without abandoning engineering fundamentals. A CTO who says "we'd cut all testing and ship fast" without any caveats is dangerous. A CTO who says "we can't compromise quality no matter what" without any flexibility is naive.
Team Building Questions
"Describe the best engineer you've ever hired. How did you find them, and how did you know they were right for the team?"
This reveals their talent instincts. Good CTOs can describe specific traits and skills, explain how they evaluated them, and tell you whether the hire worked out and why. Vague answers ("they were really talented") suggest they don't have sharp hiring judgment.
"Describe the last time you had to let someone go from your engineering team. How did you handle it?"
Firing someone is one of the hardest parts of building a team. You want to know whether they do it when necessary (CTOs who avoid it protect poor performers at the expense of the team) and whether they do it well (CTOs who do it badly create fear and resentment).
The Reference Check Is the Real Interview
References are where the interview actually happens for an executive hire. Call three to four former colleagues - ideally a mix of people who reported to them, peers, and people they reported to.
The question that surfaces everything: "Would you hire this person again to lead your engineering team? With full context of what I'm building and what I need?"
Follow-up: "What's the most important thing I'd want to know about working with them that wouldn't come up in an interview?"
These questions bypass the polished interview performance and get to what people actually experienced. The honest answers you get from good references will tell you more than six hours of structured interviews.
The CTO my client hired came with four references who all said independently: "He makes technical decisions fast, explains them clearly, and owns it when he's wrong." That's what she needed. She has never regretted the hire.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr