Questions to Ask a CTO
Questions for founders, chief executives and board members assessing a CTO candidate, covering what they have actually built, how they make technical calls under pressure, how they run and grow a team, and where their experience stops.
The questions
Open any question for the note
Tell me about the largest system you have been responsible for. What was its scale?
Why ask it
Get concrete figures: users, requests, data volume, team size. Candidates often describe well-known products without saying which part was theirs, and the difference between owning a service and working near one is the whole assessment.
How large was the team you ran, and how was it organized?
Why ask it
Running eight engineers directly and running sixty through managers are different jobs. A candidate who has only done the first can learn the second, but not while also being your first technical hire on a deadline.
What did you build yourself in the last year?
Why ask it
At an early-stage company you need to know whether they still write code, review it, or neither. Any of those can be right for the role, but a mismatch here is the most common reason a CTO hire fails in the first six months.
Describe a technical decision you made that turned out to be wrong.
Why ask it
Strong candidates name the decision, the cost, and the signal they missed. Weak answers stay at the level of a technology that did not work out, without any account of their own reasoning at the time.
How would you spend your first ninety days here?
Why ask it
Look for whether they plan to learn the system and the people before reorganizing either. A candidate who arrives with a rewrite already in mind has not yet asked why the current code looks the way it does.
Our current architecture works like this. What worries you about it?
Why ask it
Describe your real system and let them react. This is the only question in the set that tests judgment live, and it shows whether they can find risk in unfamiliar territory without dismissing what exists.
How do you decide what not to build?
Why ask it
A CTO's leverage is mostly in refusals. Look for the criteria they apply and an example of something they killed. Candidates who only talk about delivery tend to accept every request and then miss dates.
How do you handle it when engineering says six weeks and the business needs three?
Why ask it
The useful answers are about reducing scope, shipping something narrower, or being explicit about what is being traded. An answer that amounts to finding a way is how teams end up in permanent overtime.
How do you know whether the team is productive?
Why ask it
Watch for whether they reach for individual output measures, which damage teams, or for delivery and reliability signals. Also worth noting if they say they judge it by talking to people, which is honest but hard to scale.
Who have you hired that you were most wrong about, and how long did it take you to act?
Why ask it
Everyone has hired badly. The question is the delay between recognizing it and doing something, because a CTO slow to act here will let a weak senior hire shape your codebase for a year.
How do you recruit engineers when the company is not well known?
Why ask it
Relevant for any pre-brand company. Candidates from large firms often have no experience selling a role, and this becomes obvious three months in when the hiring plan has produced nothing.
What have you done about security in a company at our stage?
Why ask it
You are testing proportion. The right answer at twenty people is access control, secrets handling and backups that have been tested, not a security program copied from an enterprise.
How do you explain a technical trade-off to a board that has no engineers on it?
Why ask it
Ask them to do it with a real example. A candidate who cannot make the cost of technical debt legible to non-engineers will lose every budget argument they enter, however sound their reasoning.
What does your engineering budget usually go to, and what did you cut last time money got tight?
Why ask it
Reveals whether they track spend at all. Cloud cost, tooling and contractors are the usual lines, and what they chose to protect shows their priorities more clearly than any strategy answer.
How do you work with a founder who has strong technical opinions?
Why ask it
Ask this if that describes you. The honest answers acknowledge friction and describe how they set boundaries. A candidate who says it has never been a problem may simply defer, which leaves you still making the calls.
What would make you leave a role like this within two years?
Why ask it
Answers usually name a real dealbreaker: no authority over hiring, a product direction they cannot support, or a founder who overrides them. Better to hear it now than to discover it as a resignation.
Which technologies do you not want to work with, and why?
Why ask it
Preferences are fine, but the reasoning matters. Dislikes rooted in a bad experience at one company can quietly narrow your options, especially if your existing stack is on the list.
How do you handle an engineer who is talented and difficult?
Why ask it
This decides the culture more than any statement about values. Look for whether they have actually done it, what it cost the team while they waited, and whether the person changed or left.
What part of the CTO job do you find least enjoyable?
Why ask it
Most name hiring, performance conversations, or executive meetings. Whatever they name will be underserved, so the question is whether that is a part of the role you need done well.
What questions do you have about the business rather than the technology?
Why ask it
A CTO who asks about customers, pricing and runway is thinking about where engineering effort should go. One who only asks about the stack will optimize the system rather than the company.
Assessing a CTO candidate
Practical guidance for the conversation itself
How to run the conversation
Bring your real architecture to the room
Describe the system you actually have, including the parts you are embarrassed by, and ask what worries them. Hypothetical design questions test recall. Reacting to your mess tests judgment, and it also shows you how they treat other people's work.
Separate scale claims from ownership claims
Ask which specific component they owned, who else was accountable, and what they would have done differently. Impressive company names on a resume often cover a narrow slice of the system.
Interview for the company you are, not the one you plan to be
A CTO who has only run large organizations may not want to write code, and one who has only been hands-on may not be able to hire ten people this year. Decide which stage you are hiring for before the loop starts.
Common mistakes in hiring a CTO
Assessing only the technical half
Most CTO failures are about hiring, prioritization and communicating with the rest of the leadership team, not about architecture. Give those areas as much of the interview as the technical discussion gets.
Being impressed by a rewrite plan
A candidate who proposes replacing your system before understanding why it was built that way is showing you their reflex, not their analysis. Ask what evidence would change their mind.
Skipping references from people who reported to them
Peers and managers describe output. The engineers who worked for them describe what it was like, whether promotions happened, and how difficult conversations went. That is the information you are missing.
Practical notes
- Write down what the first year must produce before you interview anyone, then score candidates against that rather than against each other.
- Have a senior engineer you trust in at least one session: the technical depth question is hard to judge alone.
- Ask the same three core questions of every candidate so the answers are comparable.
- Agree in advance who holds authority over hiring, architecture and vendor choices, and say so in the conversation.