Questions to Ask CTO in Interview
Questions for a founder, CEO, board member or hiring panel interviewing a CTO candidate. They cover the architecture the person actually owned, how they set delivery dates, how they hire and let people go, and what would make the job a bad fit for them.
The questions
Open any question for the note
How big was engineering when you joined your last company, and how big when you left?
Why ask it
Two numbers give you the scale and the direction of the job they really did, and they are easy to check in references. A candidate who grew a team from six to sixty solved different problems from one who took over a hundred people, and the second is often mistaken for the first.
Walk me through the architecture you were responsible for, and tell me what you would change if you started again.
Why ask it
The second half of the question is the one that matters, because everyone can describe a system and only people who lived with the consequences can criticise it precisely. A candidate with no regrets either did not stay long enough to see the bill or is not being candid.
How much do you still write code, and what was the last thing you shipped yourself?
Why ask it
There is no correct amount, but the answer must be consistent with the job you are hiring for. A candidate who codes daily may struggle at fifty engineers, and one who has not touched the stack in five years may not be able to judge whether your team's estimates are honest.
How do you decide what engineering works on when product and sales both want something urgently?
Why ask it
You are listening for a mechanism they own rather than an appeal to prioritisation as a shared value. Candidates who describe taking the decision to a forum with named participants have done this; candidates who say they align stakeholders usually mean whoever shouts loudest wins.
Tell me about a technology choice of yours that turned out badly.
Why ask it
Every experienced technical leader has one, usually a database, a framework or a rewrite. A specific answer that includes the cost of unwinding it is a strong signal; blaming the team that implemented it is the answer you should worry about most.
What was your last serious outage, and what changed afterwards?
Why ask it
The change is the signal, not the incident, and you want to hear something structural rather than a promise of more care. A candidate who mentions what the post-mortem found and who was in the room understands that reliability is an organisational property.
How do you arrive at delivery dates, and how do you communicate them to a board?
Why ask it
This is the skill most CTO hires are actually judged on and the one least tested in interviews. Look for someone who commits to ranges and narrows them as scope firms up, rather than someone who either refuses to give dates or agrees to whatever the board wants.
How would you assess this team in your first sixty days?
Why ask it
Good answers include reading the code and the incident history, one-to-ones with every engineer, and sitting in on existing rituals before changing them. Anyone who arrives with a reorganisation already planned is applying a template rather than diagnosing your company.
From what you know so far, what would you change here and what would you leave alone?
Why ask it
The second half separates the thoughtful candidates, because naming something worth preserving requires having actually paid attention during the process. Beware anyone who finds nothing worth keeping, and anyone who finds nothing worth changing.
How do you handle a senior engineer who quietly resists a direction you have set?
Why ask it
This happens to every technical leader and the answers vary enormously: some escalate, some persuade, some rewrite the plan. What you want to hear is that they went to the person directly and early, and that they can describe changing their own mind at least once.
How many engineers have you hired, and how many have you had to let go?
Why ask it
The second number is the one candidates avoid, and hearing it plainly tells you whether they will manage performance or leave it to you. Someone who has never let anyone go at a team of any size has usually postponed hard conversations rather than avoided the need for them.
How would you split an engineering budget between people, infrastructure and tooling?
Why ask it
This surfaces whether they think about cost at all, which many strong engineers do not. Concrete answers reference cloud spend as a share of revenue or per-engineer tooling cost, and a candidate who has renegotiated a vendor contract will usually say so here.
What is your view on contract, agency or offshore engineering?
Why ask it
There are defensible positions in every direction, so the useful part is whether they have run it and what it cost them in coordination. Absolute answers in either direction usually mean one bad experience being generalised.
How do you deal with security and compliance before a customer forces the issue?
Why ask it
Most companies only act when an enterprise deal demands it, so a candidate who describes doing anything earlier stands out. Watch whether they treat security as a certificate to obtain or as engineering practice, because the first buys you a document and the second buys you fewer incidents.
How do you decide whether to build something or buy it?
Why ask it
The answer tells you whether they can distinguish your actual differentiator from everything else. A default towards building often produces impressive internal platforms and slow product delivery, which is a trade you should make knowingly rather than by accident.
Tell me about a time you told a chief executive something they did not want to hear.
Why ask it
A CTO who cannot do this is expensive, because you will find out about problems only when they become public. Look for a specific occasion, what they said, and how the relationship survived it.
How do you keep visibility on delivery without becoming the bottleneck?
Why ask it
This is where you learn whether they lead through managers and metrics or through personally reviewing everything. Both fail at different scales, so check the answer against the size of team you are asking them to run.
What kind of chief executive do you work best with?
Why ask it
Candidates answer this honestly more often than you would expect, and the answer is a direct compatibility test with whoever they would report to. Someone who needs a lot of autonomy and a founder who reviews everything is a known failure pattern, and it is better to find it now.
Which part of the CTO job do you like least?
Why ask it
Hiring, budgeting, board reporting and performance management are the usual answers, and the honest ones are useful because you can staff around a known weakness. A claim to enjoy all of it equally is the least informative answer available.
What would make this job a bad fit for you?
Why ask it
Asked plainly at the end, this often produces the most valuable minute of the interview, because it names the conditions under which the hire fails: no budget authority, a fixed roadmap, or a founder who keeps making technical decisions. Cheerful deflection here means you learn it in month nine instead.
How to use these questions
Practical guidance for the conversation itself
Running a CTO interview
Put a technical assessor in the loop
If the hiring decision sits with non-technical founders or board members, bring in a trusted senior engineer or an outside CTO for one session. Their job is to check that the architecture stories hold up under questioning, which is the part a business interview cannot test.
Ask for a whiteboard, not a deck
Have the candidate draw the system they last owned and explain where it broke under load. Twenty minutes of this tells you more than any prepared presentation about strategy, and it is very hard to fake in front of someone who knows the domain.
Match the candidate to the stage, not the title
Finding a first repeatable engineering process, scaling from twenty to a hundred, and turning around a stalled organisation are three different jobs. Decide which one you are hiring for before the interviews, and ask which of the three they have actually done.
Reference the people, not just the results
Ask for references from an engineer who reported to them, a product counterpart, and someone they managed out. The last one is the hardest to get and the most informative when you do.
What to weigh in the answers
- Whether they separate their own decisions from the team's. Constant use of we with no specific personal calls usually means a smaller role than the title suggests.
- How precisely they describe failure. Vague regret is common; naming the cost in months and money is rare and worth a lot.
- Whether they ask you hard questions back. A serious CTO candidate will want to know about runway, board expectations and who really decides the roadmap.
- Their language about non-engineers. Dismissiveness towards sales or support predicts an engineering organisation that ignores the rest of the company.
- Consistency across sessions. Ask two interviewers to cover the same territory and compare the numbers you each got.
Common pitfalls
Hiring the biggest logo in the pile
Having run engineering at a large, well-known company often means having inherited working systems and deep support functions. Ask what existed before they arrived and what they personally built.
Leaving scope undefined
Data, security, IT and product engineering may or may not report to this person, and candidates assume different defaults. Write the boundaries down before the final round, and check that your existing leaders agree with them.
Skipping the money questions
Cloud spend, tooling cost and contractor budgets are a large part of the job. A candidate who has never held a budget is a real risk at any company past its earliest stage, and it is easy to miss if you only discuss architecture.
Confusing fluency with judgement
Strong candidates can talk convincingly about any current technology. Anchor the conversation in what they shipped, what it cost, and what broke, rather than in what they think about the industry.
Follow-ups worth keeping ready
- "What did that cost, in months or money?" Forces a qualitative answer into a checkable one.
- "Who on your team would tell that story differently?" Reveals whether they know how they are perceived.
- "What did you decide personally, and what did you delegate?" The cleanest way to size their real scope.
- "If we called your former product lead, what would they say was frustrating about working with you?" More useful than any question about weaknesses.