Questions to Ask a CTO in an Interview
Questions to ask a CTO in an interview when you are the candidate, most often an engineer whose loop includes the head of technology. They are grouped by subject: the role and what it is meant to fix, the stack and the codebase, how work ships and what on-call costs, how decisions get made, the team and your growth in it, and the CTO in person, ending with two for closing the conversation. Each has a note on what a full or a thin answer tells you. Product managers, designers and analysts with a CTO round can use the role, decisions and team groups as they are. If you are on the other side of the table and hiring a CTO, the vault keeps a separate set of questions for a CTO candidate.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The role
What are the biggest technical challenges the engineering team is facing right now?
Why ask it
It is the standard opener for a reason: the CTO picks what to name, and the pick is their real priority list. Scaling trouble, a stalled migration and a hiring gap describe three different years ahead. Ask which of them would land on your desk.
What is your technical vision for the next two to three years, and how far along is it?
Why ask it
Any CTO can describe a destination. Asking how far along it is separates a plan with people and budget behind it from a slide, and tells you whether you would be building the new thing or keeping the old one alive while others do.
What problem is this role meant to solve?
Why ask it
The useful answers name something that hurts today: a service with no owner, a roadmap item nobody is free to build, a team with no senior person on it. That thing is your first year. When the reply is only that the company is growing, ask what the team could do with one more person that it cannot do now.
What does the first ninety days look like for someone in this role?
Why ask it
A considered answer describes a first change shipped, the systems to learn and the people to meet, roughly in that order. If all you hear is 'ramping up', ask what the last person hired was doing by the end of their first month. No answer to that either, and you would be defining the job yourself.
What makes an engineer successful on your team, beyond writing good code?
Why ask it
Whatever comes out first is what gets rewarded: shipping fast, careful design, speaking up, staying out of the way. Hold it against how you like to work. A description of someone who needs no guidance and works every hour is also an answer, and you should believe it.
Is this a new role or a backfill, and if it is a backfill, what happened?
Why ask it
New headcount means someone argued for the budget, so ask what was promised in return. A backfill means half-finished work to inherit, and it is fair to ask whether the last person moved up, moved teams or left the company. If they left, notice how they are spoken of.
Who would I work with day to day, and who decides what I work on?
Why ask it
The answer separates places where a tech lead sets the work from places where a product manager assigns tickets or where nobody does. If the CTO has to think hard about who your manager would be, the team structure is probably in flux.
What do you expect will be hardest about this job in the first six months?
Why ask it
Asked about difficulty, a CTO has to step out of the pitch for a moment. A named system, stakeholder or migration is a warning you can prepare for, and worth a follow-up on who else is working on it. If nothing comes to mind, ask what the last person to join the team found hardest.
What will you personally be judged on this year, and where does this role fit into that?
Why ask it
A CTO under pressure to cut the cloud bill, pass an audit or ship one large customer's feature will back the work that serves that goal first. If your role sits inside it, expect attention and deadlines. If it sits outside, ask who would defend your project when priorities are set.
How much would this role work with you directly once the interviews are over?
Why ask it
In a company of twenty the CTO may be your manager. In one of two thousand, this conversation may be the last you have with them for a year. Neither is bad, but it tells you whose judgment will shape your work, and that is the person to save your sharpest questions for.
Stack and code
What does the tech stack look like, and which part would you choose differently today?
Why ask it
The list of languages and services is usually in the job ad, so what you are after is the regret. A CTO who names one, and what it costs the team each month, is being straight with you. Then ask whether replacing it is on the plan or only on the wish list.
Which part of the codebase does everyone avoid, and why?
Why ask it
Most teams have one: the billing code, the oldest service, a module whose author left. Hearing it named, along with what is planned for it, tells you the debt is at least on a list. If you are told there is no such place, the codebase may be very young or the CTO may be too far from it to know, and an engineer on your loop can tell you which.
How do you balance paying down technical debt against building new features?
Why ask it
Asked in general, this nearly always gets 'we try to balance it'. So follow with last quarter: roughly what share of engineering time went to maintenance and bug work? A standing allocation, or a named piece of cleanup that shipped, means it really happens. If the split leans heavily toward keeping things running, that is the job on offer, whatever the description says.
How much of the codebase can a new engineer safely change in their first month?
Why ask it
This gets at test coverage, deploy safety and how much tribal knowledge is required, all at once. Answers about being careful around certain services are honest and useful; answers claiming anyone can change anything are usually optimistic.
What did you last decide to buy instead of build, and what tipped it?
Why ask it
A real purchase shows engineering taste and budget together. Listen for a rule about what counts as core and gets built in-house. If nothing has been bought in years, ask who looks after the home-made deploy tooling, queues and dashboards, since that upkeep may be part of the job.
How is security handled day to day: who can reach production data, and who reviews that?
Why ask it
A concrete answer covers who holds production access, how it is granted and when the list was last pruned. If the reply is only the name of a certification, ask what it changed about the way engineers work. Companies handling health or payment data work under rules that depend on the country and the industry, so ask which ones apply here.
Which part of the system is closest to its limit at today's load?
Why ask it
Growth plans fail at one specific place, and you want to know whether it is in the area you would own. If it is, ask whether the fix is designed, funded or still only a worry. Should the CTO not know, save the question for whoever runs infrastructure.
Which AI tools do engineers here write code with, and what is off limits?
Why ask it
Some teams hand every engineer an assistant, others forbid sending any source code to an outside service, and plenty have never written a rule down. Ask who answers for generated code once it is merged, and whether customer data may ever go near these tools. If you lean on an assistant, or distrust one, this answer changes your working day.
How much of the testing is automated, and what still gets checked by hand?
Why ask it
The manual part is the useful half. A release checklist someone clicks through, or a QA team that only sees work at the end, sets how fast anything can ship and who gets blamed for a bug. Ask whether engineers write the tests for their own changes.
If I had to understand a service nobody has touched in a year, where would I start?
Why ask it
This is the documentation question in a form that cannot be answered with 'we have a wiki'. Design notes, a runbook and a readable commit history are all good places to start. Being told to ask one particular person means the knowledge lives in people, and your first months depend on their patience and on their staying.
How does a new language, framework or tool get adopted here?
Why ask it
Some teams require a written proposal and a trial with an end date. In others, whoever starts using a thing first has chosen it for everyone. The first way is slower and leaves fewer orphans, and the number of languages in production is a fair record of which one has been in force.
Shipping
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.
How does code review work here, and how long does a pull request usually wait?
Why ask it
The wait is a number, so a vague reply means nobody tracks it. Hours suggests review is treated as part of the job; several days suggests reviewers are overloaded or nobody is sure who owns the code. Ask whether one or two named people must approve everything, because their calendar then sets the pace for the whole team.
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 watches the alert load, while 'it is pretty quiet' with no figure may mean nobody has measured it. Whether on-call is paid or earns time off differs by employer and by country, so ask how it works here before you assume.
When something breaks in production, who usually notices first: monitoring, an engineer or a customer?
Why ask it
'A customer' is an honest and common answer in a young system, and it tells you monitoring is work waiting to be done. If alerts catch most things, ask how many of them turn out to be false, because noisy alerting is what makes a rotation miserable.
What happened during the last serious outage, and what changed afterwards?
Why ask it
Listen to how the story is told: whether a person or a process takes the blame, and whether the follow-up work was finished. If you hear that some of the fixes are still sitting on a list, that is at least an honest picture of how much room this kind of work gets.
What happened the last time a project ran late?
Why ask it
This is where you learn whether deadlines are negotiated or enforced, and whether anyone was blamed. Listen for whether scope was cut, dates moved, or engineers worked weekends, because that pattern will repeat while you are there.
Does the team work in sprints, and what happens when something urgent lands in the middle of one?
Why ask it
Whether it is called Scrum, Kanban or nothing at all, the test of a process is the interruption. Ask how often the plan made on Monday is still the plan on Friday. A CTO who cannot say how teams plan is usually leaving it to them, which is fine, though it makes the engineers on your loop the ones to ask.
What does an ordinary week look like for an engineer here, and how much of it is meetings?
Why ask it
A rough count of the standing meetings is something a CTO should be able to produce. Protected mornings or a meeting-free day show that somebody has defended engineers' time on purpose. Put the same question to an engineer later; where the two answers differ, the engineer's week is the one you would have.
Decisions
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
Some teams are brought a customer problem and asked how to solve it. Others receive finished tickets with a date attached. Ask for the last time an engineer changed the scope of something and what came of it. If you want a say in what gets built, the second kind of team will wear on you.
How do you handle disagreement with the rest of the leadership team about timelines?
Why ask it
You want an example: a date the CTO pushed back on, and what was offered in exchange, such as less scope, more people or a later launch. When every deadline is passed down untouched, the negotiating is left to the teams, and engineers make up the difference in their evenings.
Tell me about the last time an engineer changed your mind.
Why ask it
You are asking whether disagreement travels upward here. A recent, specific story, including what the engineer showed them, means it does. A long silence, or an example from years back, suggests decisions flow in one direction.
How often do engineers here talk to customers or watch them use the product?
Why ask it
Engineers who see the product in use argue about scope from evidence, and are harder to hand a finished specification. If the answer is never, ask how a bug report or a feature request reaches the team, and how much gets lost on the way.
How would sales and support describe working with engineering?
Why ask it
The honest reply includes the standing complaints: estimates that slip, bugs that wait, features promised to a customer before anyone asked the team. From it you learn whether engineering is treated here as a partner or as a queue. Ask how a request from sales reaches an engineer, and who is allowed to say no to it.
If you were given five more engineers tomorrow, where would you put them?
Why ask it
The answer shows where the CTO thinks engineering is thinnest, which no org chart will. If the area you are joining comes first, expect a full plate and plenty of attention. If it goes unmentioned, expect less of both.
Where does AI fit into the product plans, and who is working on it?
Why ask it
Answers range from a staffed team with something shipped, to a line in the sales deck, to a deliberate decision to wait. Ask what customers are using today. If that work would pull you in, or you would rather it did not, find out how people are chosen for it.
What has the team tried that did not work?
Why ask it
An abandoned migration or a tool nobody took up is ordinary, and a CTO who can name one without flinching is easier to work for. Notice whether the failed effort was closed and written up, or is still running half maintained. The second kind tends to land on whoever joins next.
How is the company funded right now, and how does that shape what engineering does next?
Why ask it
At a startup this is the runway question, and a candidate is entitled to ask it, though how much detail you get depends on the company and its stage. At a profitable or public company, ask whether the engineering budget is growing, flat or being cut. In both cases you are listening for a CTO who can tie the money to the plan: what gets hired for, and what waits.
Team and growth
How big is the engineering team today, and how is it organized?
Why ask it
The split between product teams, platform and infrastructure shows what kind of work exists and where yours would sit. Size also tells you what the title means. The CTO of fifteen engineers is often still reviewing code, and the CTO of five hundred is running managers of managers.
How would you describe the engineering culture, and what would the engineers add that you left out?
Why ask it
The first half gets the adjectives: collaborative, pragmatic, fast. The second asks the CTO to look at the place from below, and often produces the first unpolished remark of the interview, about pace or process or how blunt the reviews are. Compare it with what the engineers on your loop say unprompted.
How do you handle a strong engineer who is difficult to work with?
Why ask it
What gets tolerated when someone's output is high says a good deal about daily life on the team. A story about coaching, a changed role or someone being let go is a real answer. If it has never come up, ask what would happen if you raised a problem about a senior colleague.
Who has left the team in the last year, and why did they go?
Why ask it
People leave every team, so the number alone says little. What counts is whether the CTO knows the reasons, such as pay, a manager or a stalled project, and whether anything changed afterwards. Several departures from one team are worth a polite follow-up.
How does someone get promoted here, and who was promoted most recently?
Why ask it
A named person, what they did and roughly when shows the ladder is in use. A framework described with no recent example may exist only on paper, so ask how long the last promotion took from first conversation to new title. Review cycles and pay bands differ by employer, so ask how they work here.
How far can an engineer go here without becoming a manager?
Why ask it
Titles such as staff and principal engineer are easy to add to a ladder. What counts is how many people hold them here, and whether those people still build things. If everyone above senior is a manager, within a few years you will be choosing between the work you like and a raise.
How do you measure whether the engineering team is doing well?
Why ask it
Dates hit, uptime, revenue from new features and how many people stayed are all defensible answers, and each one points the team at something different. Counting tickets or commits is a warning, since both are easy to inflate. Ask which of those numbers the chief executive sees, because that is the one the team will be steered by.
What do engineers here get for learning: time, a budget, conference trips?
Why ask it
A budget nobody spends is common, and it usually means the calendar never leaves room. So ask for the last course, conference or week of exploration somebody on the team took. Design reviews and a rotation onto another team are learning too, and they cost nothing.
Where does the team work from, and how do remote engineers find out what was decided?
Why ask it
The location policy is usually in the job ad. How a decision reaches the people who were not in the room is not, and choices made in a hallway and never written down leave anyone outside the office a step behind. If you would be remote, ask how many other engineers are, and whether any of them are senior.
Who would I learn the most from on this team?
Why ask it
A CTO who knows the team answers with a name and a reason. You find out whether anyone is ahead of you in the things you want to get better at, and it leads naturally into asking to meet that person before you decide.
The CTO
Do you still write code, and where does the rest of your week go?
Why ask it
Moving from code to hiring, budgets and board meetings is the normal path for a CTO, not a failing. What you need from the answer is who makes the technical calls day to day now, and whether you have met that person in your interviews. If the CTO does still commit code, ask who reviews it.
Why did you take the CTO job here, and has it turned out to be the job you expected?
Why ask it
Nearly everyone enjoys the first half, which makes it a good one to start with when your turn comes. The surprise is the informative part: the state of the code, the board, how much of the week goes to hiring. With a founding CTO, ask instead how the job has changed since the first hire.
How would you describe your leadership style, and when has it not worked?
Why ask it
Hands-off, direct and collaborative are labels every leader claims. The time it failed is the part with information in it: a team that needed more direction than they gave, feedback that landed too hard. A CTO who cannot think of one has probably not been told, and that tells you something as well.
What do you still do yourself that a CTO probably should not?
Why ask it
Approving every pull request, holding the only production credentials, interviewing every candidate: each is a queue you would wait in. Ask it lightly, then ask what would have to be true for them to hand the thing over, because now and then the answer is this very hire.
From what you have heard today, where would you expect me to struggle in this role?
Why ask it
The CTO's doubt often decides the hire, and it is seldom said aloud unless invited. Ask only if you can hear the answer calmly, then reply with one example and stop. If they say nowhere, do not go looking for a weakness to volunteer.
What happens after this conversation, and is the final decision yours?
Why ask it
A CTO round is often the last one, and sometimes the CTO holds a veto and not the vote. Knowing which helps you read the silence afterwards. Ask for a date you can expect to hear by, and who will be the one to get in touch.
Using these questions in a CTO interview
Practical guidance for the conversation itself
How to ask them
Take five or six, one from each group you care about
A CTO slot is often half an hour with ten minutes left for you, so this list is for choosing from, not for reading out. Put the question whose answer could change your decision first. The fine detail of deploys, reviews and on-call can also go to the engineers and the hiring manager on your loop, who live closer to it.
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 before you decide
How often the team deploys, and how many times the last on-call rotation was paged overnight. Between them they describe the working week better than a long talk about culture, and both are easy to answer and hard to dress up. A CTO who is too far from the work to know them will usually say so, and an engineer on your loop can fill them in.
Match the questions to the CTO's actual distance from the code
At a small company the CTO can often answer anything about the codebase. At a larger one they will know direction, funding and headcount but not the state of one service. Ask a CTO of the second kind about organization and priorities, and the engineers on your loop about the code.
If you are not an engineer
Product managers, designers and analysts get a CTO round too. The role, decisions and team groups work as they stand. From the technical groups, keep the ones about how work reaches production and who notices when it breaks, since those shape your launches as much as anyone's.
What to watch for in the answers
A codebase described as clean
Nearly every system of any age has a region people avoid. At a small company, a CTO who cannot name it is either away from the work or managing your impression. At a large one they may simply be too many levels up, so take the question to an engineer before you accept.
Maintenance handled by intention alone
If reducing technical debt has no share of the schedule, no owner and no recent example, it is a stated value and not yet a practice. The backlog you inherit is then more likely to grow than shrink, so ask what it would take to get one cleanup onto the plan.
Roadmaps that arrive fully specified
Ask who proposed the last three things engineering built. If the answer is always product or the chief executive, engineering here carries out plans and does not shape them. Some people are content with that; it is better learned in the interview than in month three.
A vision with no first step
A picture of the technology three years out costs nothing to draw. If the CTO cannot say what was done toward it last quarter, and by whom, treat it as a hope and weigh the job on what the team is doing now.
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 would still ask if the CTO slot were cut to ten minutes. Senior people's interviews do get squeezed.
- If the CTO is your final round, hold back one closing question: whether they have a doubt about you that you could answer, or who makes the decision and when.