Questions to Ask a CTO in an Interview
Questions for an engineering candidate whose interview loop includes the CTO, covering how technical decisions get made, what the codebase and on-call load are really like, how the team is organized, and what this role is expected to fix.
The questions
Open any question for the note
What is the engineering team's shape today: how many people, and split how?
Why ask it
Headcount and the split between platform, product and infrastructure tell you what kind of work exists. It also exposes whether a CTO of a fifteen-person team is really a hands-on lead, which changes what the job is.
What problem is this role meant to solve?
Why ask it
Backfilling someone who left, absorbing overflow work, and starting something new are three very different jobs with the same title. If the answer is only that they are growing, the scope has not been thought through yet.
Walk me through how a change gets from a laptop to production.
Why ask it
You learn the real state of testing, review and deploy tooling from the concrete path. Long manual steps or a release window on Thursdays tells you more about daily life than any statement about engineering culture.
How often do you deploy, and how long does a rollback take?
Why ask it
These two numbers together describe the team's confidence in its own system. Frequent deploys with slow rollbacks means outages last a long time, which is where your evenings will go.
What is on-call like, and how many pages did the last rotation get overnight?
Why ask it
Ask for the count, not the policy. A specific number means someone is looking at alert load. A vague reassurance that it is quiet usually means nobody has measured it and the person on call is absorbing it silently.
Which part of the codebase does everyone avoid, and why?
Why ask it
Every team has one. Naming it openly means the debt is acknowledged and probably scheduled. A claim that no such area exists means either the codebase is very young or the CTO is not close to it.
How do you decide between fixing what exists and building something new?
Why ask it
Look for a mechanism, such as a standing share of each cycle for maintenance. Answers that rely on judgment case by case usually mean maintenance loses to whatever the roadmap wants that month.
Who decides technical direction, and how did the last significant decision get made?
Why ask it
The example matters more than the process. It shows whether decisions come from the CTO, from a group of senior engineers, or from whoever argued longest, and whether they get written down.
How do engineering and product decide what gets built?
Why ask it
Reveals whether engineers see problems or receive specifications. A team handed finished tickets tends to have limited say in scope, which is where most engineering frustration actually comes from.
What happened during the last serious outage, and what changed afterwards?
Why ask it
The story tells you how blame is handled and whether follow-up work gets funded. Action items that were written and never done is a common and revealing answer if the CTO is honest about it.
How much of the platform is yours to change, and how much depends on vendors?
Why ask it
Heavy vendor dependence limits what engineers can fix and shifts the work toward integration. Worth knowing before you accept a role expecting to build systems from the ground up.
What does the first ninety days look like for someone in this role?
Why ask it
A CTO who has thought about it will describe a first change shipped, systems to learn, and people to meet. An answer that is only about ramping up suggests you will be defining the job yourself.
How do you handle disagreement with the rest of the leadership team about timelines?
Why ask it
Tests whether the CTO negotiates scope or passes deadlines through untouched. The second pattern is what turns into permanent crunch two levels below them.
Where do you spend your own time now, and where did you spend it two years ago?
Why ask it
A CTO drifting from code to hiring and board work is a normal path, but it tells you who actually makes technical calls day to day, and whether that person is in your interview loop.
How does someone get promoted here, and who was promoted most recently?
Why ask it
A named example with a timeframe means the ladder functions. A description of the framework with no recent example usually means promotions happen when someone threatens to leave.
What are you doing about security and access, in practice rather than on paper?
Why ask it
Concrete answers mention who can reach production data and how that is reviewed. If the answer is a compliance certification, security is being handled as an audit exercise rather than an engineering one.
Which of your current engineering commitments do you think will not survive the year?
Why ask it
An unusual question that most CTOs will answer candidly. What they name, a rewrite, a framework migration, a service nobody owns, is where the next disruption will come from.
What has the team tried that did not work?
Why ask it
Abandoned migrations and tooling nobody adopted are normal. What you learn is whether failed efforts get named and closed, or quietly left running and half maintained.
How long is the runway, and how does that shape what engineering does next?
Why ask it
Fair to ask directly at a private company. The answer sets the horizon on every technical bet, and a CTO who cannot connect funding to engineering plans is unlikely to be in those conversations.
Who has left the team in the last year, and do you know why?
Why ask it
Turnover is not damning on its own, but the specificity of the answer is telling. Naming reasons and what was done in response is a stronger signal than a low number stated without detail.
Using these questions in a CTO interview
Practical guidance for the conversation itself
How to ask them
Ask for the last time, not the general case
How do you handle outages produces a policy. What happened during the last serious outage produces a story with names, timings and follow-up work you can evaluate. Anchor every question to a real event where you can.
Get two numbers if you get nothing else
Deploy frequency and overnight page count in the last rotation will tell you more about the working week than an hour of discussion about culture. Both are easy to answer and hard to dress up.
Match the questions to the CTO's actual distance from the code
At a small company the CTO can answer anything about the codebase. At a larger one they will know direction, funding and headcount but not the state of a service. Ask the second group about organization and the engineers on your loop about the code.
What to watch for in the answers
A codebase described as clean
Every system of any age has a region people avoid. A CTO who will not name it is either detached from the work or managing your impression, and both are worth knowing before you accept.
Maintenance handled by intention alone
If reducing technical debt has no allocated capacity, no owner and no example of recent work, it is a stated value rather than a practice. Expect the backlog you inherit to keep growing.
Roadmaps that arrive fully specified
Ask who wrote the last three things engineering built. If the answer is always product or the CEO, engineering here executes rather than decides, which is fine to accept but not to discover later.
Before the interview
- Look at the company's public repositories, engineering blog and conference talks so you can ask about something specific they have built.
- Check their status page history if they publish one: it gives you the outage question with a real incident attached.
- Read the job description for what it omits, then ask about the missing part directly.
- Pick the three questions you will ask if the CTO slot gets cut to ten minutes, which happens often.