CTO Interview Questions From Someone Who's Hired for Six Startups

The best CTO interview questions do not test knowledge. Any competent candidate knows the vocabulary. They test judgment under a constraint you specify, because that is the actual job: making a call with incomplete information, a deadline, and real consequences if it is wrong. Below is the set I actually use, organised by what each one is really checking for, plus the answers that should worry you.

I have hired or evaluated technical leadership for six startups I co-founded across three continents, and I have been the candidate in more CTO and technical co-founder conversations than I can count. Most public interview question lists read like they were written by someone who has done neither. This one is not a list to read off a page; it is a set of tools, use the ones that fit your stage.

Questions that test architectural judgment, not architectural knowledge

"Walk me through a system you built where the requirements changed significantly after launch. What did you do?"

What you are checking: whether they design for change or design for the spec in front of them. A strong answer names a specific decision that made the change cheap (an interface boundary, a data model choice) rather than "we just refactored it." A weak answer blames the changing requirements instead of describing what they'd do differently.

"Tell me about a technical decision you made that you would make differently today."

What you are checking: whether they can be honest about being wrong, and whether they have actually updated their thinking since. Watch for candidates who cannot name a real mistake, or who name a trivial one to seem humble while protecting the decisions that actually mattered. The best answers include what the mistake cost and how they caught it.

"If you had to cut our current roadmap by 60% and keep the company alive, what goes and what stays?"

What you are checking: whether they can make a real prioritisation call live, under a constraint, instead of retreating to "it depends" forever. This is the single most useful question I ask, because subtraction is most of what a good technical leader actually does at the early stage, and it is the skill interview prep does not cover.

Questions that test how they think about risk

"Describe the worst production incident you have owned. What happened, and what changed afterward?"

What you are checking: ownership language versus blame language, and whether "what changed afterward" is a real process improvement or a platitude. I want to hear "I" own the decision that caused it, not "the team" or "the previous engineer." If someone has never owned a real incident, ask why: sometimes it means they have not been senior long enough, sometimes it means they have been shielded from consequences their entire career.

"What is the single point of failure in the last system you were responsible for, and did you fix it?"

What you are checking: self-awareness about risk they are currently carrying, not risk they fixed years ago. A candidate who says "none" either has not thought about it or is not being honest with you. Every real system has one.

"How do you decide when a security or compliance gap is urgent versus something to sequence for later?"

What you are checking: whether they have an actual framework, or whether everything is either an emergency or ignored. In regulated or enterprise-facing work, this is where I have seen the most expensive mistakes: PHI or card data sitting somewhere it should not because nobody made an explicit call about urgency, they just didn't get to it.

Questions that test how they work with people, not just code

"Tell me about the last time you disagreed with a founder or another executive on a technical call. What happened?"

What you are checking: whether they can hold a position under pressure from someone senior to them, and whether they know when to concede versus when to push. A candidate who says "I always defer to the founder" is telling you they will not stop you from making an expensive mistake. A candidate with no example has probably not been in the room enough.

"How do you evaluate whether an engineer on your team is actually good, versus just experienced?"

What you are checking: whether they have a real framework for assessing people, since this is most of the job once a team exists. Vague answers ("good communication, works well with others") suggest they have not actually had to make a hard call about someone's performance. Specific answers name what they look at: the quality of the questions someone asks before building, how they handle being wrong, whether their code needs to be rewritten six months later.

"Describe a time you had to deliver bad technical news to investors or the board. How did you frame it?"

What you are checking: whether they can be the person in the room who says the hard thing plainly, which is a large part of what you are paying a CTO for in high-stakes conversations. Watch for candidates who cannot recall ever having to do this; it usually means they have not been in the room, or they have avoided the moment when it mattered.

Questions specific to fractional and part-time engagements

If you are evaluating a fractional CTO rather than a full-time hire, add these:

"What does a normal week actually look like across your current clients?"

What you are checking: whether the hours claimed are real, and whether the candidate is spread so thin that your company gets leftover attention. Ask for specifics: which days, which parts of the week are yours.

"What have you told a client not to build?"

What you are checking: whether they will tell you no. The value of a fractional CTO with pattern recognition across companies is largely the things they talk you out of, not the things they help you build. If they cannot name an example, they may be optimising for keeping the retainer rather than for your outcome.

"How do you handle it when a week needs more hours than the retainer covers?"

What you are checking: whether the retainer is structured as a floor or a ceiling. The honest answer should be some version of "it gets the hours," not "we'd discuss an additional invoice." I wrote the full reasoning behind this in designing a fractional CTO retainer that delivers results, and it is worth reading before you sign anything, from me or anyone else.

Questions I would ask myself, and my honest answers

Founders sometimes ask if they can just use this list on me. Please do. A few, answered straight:

A system you built where requirements changed significantly after launch? The anonymised edtech venture. We built our own Linux OS from zero because nothing off the shelf handled the requirement, then had to port it to mobile Linux mid-build when the requirement shifted again. The decision that made that survivable was keeping the core assessment engine decoupled from the OS layer from day one, before we knew we would need to.

The worst production incident you have owned? One wrong line in an AWS load balancer configuration, caught in the last moment before our first full run of 500,000 assessments in an hour. It did not go wrong, but it was one line away from going very wrong, and the process change afterward was a mandatory second reviewer on any infrastructure change touching that path, no exceptions for how confident either of us felt.

A mistake you would make differently today? I have made the same category of mistake across more than one of six startups: underestimating how long a stack choice would cost me in hiring, not in building. I cover this directly in six startups, three continents: what actually killed them.

How to use this list without turning the interview into an interrogation

Pick three or four questions, not all of them. Ask for a specific example every time; "how would you handle X" gets you a rehearsed answer, "tell me about a time you actually did X" gets you the truth. And listen for what they say about their own past mistakes more than what they say about their strengths: anyone can describe their strengths convincingly, and it tells you almost nothing about how they behave under pressure.

Frequently asked questions

Should I ask a fractional CTO candidate to do a paid trial before signing a full retainer? Yes, and I would recommend it over four rounds of interviews. Two weeks of a paid architecture review tells you more than any interview, because you get to see the actual judgment applied to your actual codebase. I structure my own engagements to start this way rather than a long contract signed on the strength of a conversation.

How many of these questions should a strong candidate be able to answer well? Most of them, with real specifics, not polish. A candidate who is smooth on every question but light on detail is worth a second, harder round. A candidate who is honest about a real mistake and specific about what changed is usually the stronger hire, even if the delivery is rougher.

What is the single biggest red flag in a CTO interview? An inability to name a real mistake, or a real thing they told a previous team not to build. Both suggest either limited seniority or a pattern of protecting their own record over the company's outcome, and both are expensive traits in someone you are about to trust with irreversible decisions.

Do these questions work for evaluating a technical co-founder, not just a hire? Mostly yes, with more weight on the disagreement and risk-ownership questions, since a co-founder relationship runs for years under far more pressure than an interview loop simulates. I go deeper on that specific evaluation in how to find a technical co-founder.

If you are running a search right now and want a second opinion on a specific candidate or a specific answer they gave, book a call. If you are the one being asked these questions and want to know what the honest answers actually sound like, the rest of the site is the long-form version.