How to Interview a CTO
Or: Can you code and communicate?
This is the third post in the How to CEO series—a collection of tactical, no-nonsense guides for running a high-growth company. If you’re just joining us, start with the series welcome post for the full roadmap, or check out How to Interview a Product Leader, and How to Write a Job Description for a Senior Exec, the first posts in the series.
The best CTOs aren’t just brilliant engineers. They’re force multipliers who can lead, communicate, and ship. You feel calmer when they’re in the room.
I remember the first time I interviewed a CTO. I brought in one of the partners from our lead investor—someone with a strong technical background—to help. At one point, he turned to the candidate and asked: “Imagine you’re standing on Earth. Spaceships to Mars leave every hour. Each trip takes X hours, and they return after a fixed turnaround. How many ships will you pass on your trip to Mars?”
It was one of those analytical brain-twisters meant to test how someone thinks. I gave it about ten seconds of thought before realizing: I WANT to solve it, but I’m not the best person to solve it. My job isn’t to solve that problem. My job is to hire someone who can. That was a real unlock for me. I didn’t need to pretend to be technical. I needed to be clear about what the company needed and find someone who could deliver it.
Most first-time CEOs don’t know how to interview a CTO. I didn’t either. I’ve now hired multiple technology leaders, some who helped us build real momentum, and one who lasted 30 days. This post is a distillation of what I’ve learned the hard way about evaluating technical partners.
If you’re a non-technical founder, it can feel intimidating. You’re supposed to know what great technical leadership looks like, but you can’t read their code or architect a system. So what do you do? Too often, CEOs just cede the whole conversation. They assume the CTO knows best and focus the interview on culture fit or vision alignment. That’s a mistake.
You’re hiring someone who will shape the future of your product, your company, and your team. You can’t afford to just hope you got it right. You have to ask better questions.
Here are mine. And before we get into the interview questions, here’s what else I’ve learned to look for:
First, I want to know if they can actually code—and if they still will. Are they jumping into problems on a Sunday at 3am when the system is down? Or do they need someone else to handle that? I’m not asking them to pull all-nighters every week, but I need to know they can go from strategy to keyboard when it counts.
Second, the tech itself matters—a lot. The best tech often wins. And when it comes time to raise money, sell, or even just explain your business to a strategic partner, the first thing they’ll ask is: is the tech real? Is it differentiated? Is it defensible? You can’t fake this. So I want a CTO who’s proud of what we’re building and holds the quality bar high.
And finally, I want to know what they’re curious about. What’s the last thing they built, even for fun? What’s the last thing they learned? You can’t teach curiosity, and I want someone who brings it with them.
1. Can they ship?
I once hired a CTO who couldn’t get us from zero to 0.1. We spent weeks debating platforms and tooling choices instead of putting product in front of users. That person was gone in 30 days. I learned that early-stage CTOs can’t just be smart—they have to be scrappy and pragmatic. Hands on. Committed to velocity over elegance.
So I ask:
“Tell me about a time you had a hard deadline for a product launch. What trade-offs did you make to hit it? What did you cut, what did you keep, and how did you make those calls?”
Then I listen for ownership, urgency, and realism.
2. Do they have range?
Early on, you probably don’t have a full EPD org. You might not even have a PM. I need to know my CTO can go end-to-end—front end, back end, infrastructure, cloud, and mobile. They don’t need to be an expert in all of it, but they have to know enough to build and enough to decide what not to build.
So I ask:
“When you’re building a new product—say in [insert your space]—how do you choose your stack? Walk me through your process: front end, back end, infra, mobile. What trade-offs do you consider, and how do your past experiences shape those decisions?”
And: "How do you think about balancing short-term speed with long-term scale? When have you had to make architecture decisions that supported a fast MVP now but wouldn't block future growth later?"
3. Do they understand the customer and the business?
I’m not looking for someone who just wants to write code. I’m looking for someone who wants to solve real problems. That means caring about customers, understanding competitors, and being able to work through ambiguity.
Some engineers want a finished spec. Others want to help shape the roadmap. Run from the ones who just want to be a cog — give me a spec and we’ll deliver types. You’ll be frustrted that they dont care about the business. They need to understand the customer, the market, and what the company is trying to achieve. I’m not looking for someone who just executes. I’m looking for someone who solves problems that matter.
So I ask:
“How do you get to know the customer and market when you join a new company? Do you prefer a clear spec, or do you want to help define the problem? How do you connect your team to the business goals?”
4. Can they recruit and retain talent?
The best CTOs are magnets for talent. They’ve worked with great people before, and they can bring them with them. I want to know who they’d call and if those people would actually pick up the phone.
So I ask:
“Who are the 3 to 5 people you’d try to bring with you if you took this job? Have you worked with them before—and would they join you?”
I also want to know how they build teams:
“What’s your approach to recruiting, especially when you can’t pay top of market? How do you sell the opportunity?”
5. Can they communicate?
Your CTO needs to talk to product, marketing, sales, and the board. They need to communicate trade-offs clearly, reset expectations when needed, and help the company make decisions.
So I ask:
“How do you keep non-technical stakeholders in the loop without slowing your team down?”
And:
“Tell me about a strong partnership you’ve had with a sales or marketing leader. What made it work—or not work?”
6. Who are they, really?
Every interview ends the same way. I ask the same four questions, no matter the role:
What’s your long-term career ambition?
What’s your superpower?
What’s something you’re not great at?
What would your last manager or CEO say about you in a formal review—especially constructive feedback?
You learn more in those answers than in any whiteboard exercise.
📝 Download the Interview Scorecard
Use the same structured CTO interview scorecard I do. It’s a tab in the same workbook as the Product Leader Scorecard from the previous post: https://mbj.im/interviewscorecards
CEO Move:
Don’t outsource this. Just because you’re not technical doesn’t mean you don’t get to have an opinion. Stay in the room. Ask good questions. Know what your company needs—right now—and find someone who can deliver it. You don’t need to be an engineer. You need to be a CEO.
When your tech is great, everything gets easier. Fundraising. Hiring. Selling. You can feel it. So can everyone else.
If this post helped you—or made you think of someone—please forward it to them. And let me know what resonated or missed. I read every reply.
#leadership #howtoceo #executivehiring #cto #RealTalk