Questions to Ask a CTO Candidate in an Interview
Questions to ask a CTO candidate in an interview, written for the hiring side of the table: a founder, chief executive, board member or panel choosing the person who will run technology. They are grouped into track record, strategy, delivery and risk, people, the business, and fit, and they open with what is worth establishing first: the size of team the candidate really led, the architecture they owned and a technology strategy they set. Each question has a note on what a strong or a thin answer tells you, and often what to ask next. The guide covers running the interview when nobody on the panel is technical, and how to share the groups out between interviewers. If you are the candidate and it is the CTO who is interviewing you, the vault keeps a separate set of questions to ask a CTO in an interview.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Track record
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.
Tell me about a technology strategy you set: which business goal was it for, and how did it turn out?
Why ask it
Nearly every CTO interview asks how technology lines up with the business, and asked in general it gets a general answer. Asking for one real plan gets you the goal it served, such as a new market, a cost target or a large customer's demands, and whether anyone outside engineering would recognise the story. If the plan was written and never revisited, ask what replaced it.
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.
Tell me about a technology choice of yours that turned out badly.
Why ask it
Anyone who has led for a few years has one, often a database, a framework or a rewrite. The strong version names what it cost to unwind and how long they defended it before admitting it. Blaming the team that built it is the reply to mark down.
Which achievement as a technical leader are you proudest of, and what was your own part in it?
Why ask it
What they pick shows what they think the job is: a system, a team they built, a rescue, a sale that closed because the product held up. Push on their own part until you can separate their decisions from their team's. A proud story with no other names in it is as much a warning as one with no 'I' in it.
What is the hardest project you have led, and what came closest to sinking it?
Why ask it
Hard projects fail for dull reasons: a dependency on another team, a key person leaving, a requirement that changed in month four. Whoever names the dull reason has run something difficult. Ask what they would refuse to start without next time, since that is the lesson in a form you can check.
What is the largest scale you have run in production, and what broke on the way there?
Why ask it
Let them choose the unit, whether that is users, transactions, data volume or the number of customers on one database, then compare it with where you expect to be in two years. Experience far above your scale can be as poor a match as experience far below it, because the problems and the budgets differ. The breakage is the proof: people who were there remember which component gave out first.
Strategy
Where do you draw the line between what to build in-house and what to buy?
Why ask it
You are checking whether they can tell the part of the product customers pay you for from everything around it. A habit of building tends to produce handsome internal platforms and slow product delivery, which is a trade to make knowingly. The follow-up that tests it is one thing they built and should have bought.
How much engineering time should go to technical debt, and how do you justify it to people who cannot see the debt?
Why ask it
Any figure they give is less interesting than how they defend it. Good answers turn debt into something a chief executive can weigh: a release that takes a week when it should take a day, a feature quoted at three times its size because of what sits underneath. Be careful with a candidate who promises to clear it all, and with one who has never asked for the time.
When would you rewrite a system from scratch instead of improving it in place, and have you ever done it?
Why ask it
A full rewrite is about the most expensive promise a new CTO can make, because the old system has to keep running and changing while the new one catches up. People who have been through one remember how long the two ran side by side and what was cut to finish. A proposal to rewrite yours before reading it is habit talking.
If the budget covered only one this year, making what we already run more reliable or building something new, which would you choose?
Why ask it
Forcing the choice stops the answer that both matter. A sensible candidate will ask about your uptime, your churn and your competitors before picking, and that request for facts is the answer you want. Whoever picks at once, in either direction, is describing their temperament and not your company.
How do you leave room for engineers' own ideas without letting the roadmap slip?
Why ask it
Hack days and a fixed slice of free time are the usual replies, so go one step further and find out what came of them: a feature customers now use, a tool the team depends on, or nothing anyone can name. An idea from a junior engineer that reached production means there is a working route for ideas and not only a calendar entry.
Where does AI belong in a business like ours, and where would you keep it out?
Why ask it
A prepared view on AI is standard now, so you learn more from where they would refuse it. The limits worth hearing are tied to your situation: customer data that should not leave your systems, a feature where a wrong answer costs someone money, a cost per request that eats the margin. Enthusiasm with no line anywhere usually means they have not yet run it in front of paying customers.
How do you keep up with new technology, and what have you adopted and later dropped?
Why ask it
The reading list matters less than the filter. Someone who can describe a tool they trialled, the date they set to judge it, and the reason they pulled it out has a method for telling fashion from value. If everything they adopted is still in use, either their judgement is unusually good or nothing ever gets switched off.
How do you make a large technical decision: who is consulted, what gets written down, and who can overrule you?
Why ask it
Ask for the last one and not the principle. You are checking for two failures at once: the CTO who decides alone and announces it, and the one who seeks consensus until the decision makes itself. The overrule clause earns its place because the honest reply names the chief executive or the board, and that opens a conversation about authority worth having before any offer.
Delivery and risk
How do you decide what engineering works on when product and sales both want something urgently?
Why ask it
What you want is a mechanism: a weekly meeting with named people, one ranked list, a rule for what is allowed to interrupt it. 'Aligning stakeholders' with nothing behind it tends to mean that whoever shouts loudest wins. Have them tell you what was bumped the last time sales got its way.
How do you work with the head of product: who owns the roadmap, and what happens when the two of you disagree?
Why ask it
What ships depends heavily on how these two people get on. Some CTOs expect to own product as well, some want a strong equal, and a few treat product as a source of tickets. Match the answer to the person you already have in that seat, or to the fact that nobody is in it yet.
How do you arrive at delivery dates, and how do you communicate them to a board?
Why ask it
A board often knows its CTO mainly through the dates they give, so a hire who cannot explain one loses its trust quickly. The practised answer offers a range, says what would move it and narrows it as the scope firms up. Refusing to give dates at all and agreeing to whatever date the board names are the two replies to mark.
A project is three months late and the team says it needs two more. What do you do in the first week?
Why ask it
It is a hypothetical, so listen for the order of the steps. Finding out what is truly finished, cutting scope and resetting the date in one go is the experienced sequence; adding people or asking for weekends is the reflex of someone who has not lived through it. Then ask when this last happened to them and how late the thing finally was.
How do you know what is really happening in delivery without everything having to pass through you?
Why ask it
The reply shows whether they lead through managers and a few numbers or by reviewing the work themselves. Reviewing everything works at eight engineers and jams at forty, and managing by dashboard can miss a team that is quietly stuck. Hold their habit up against the size of team you are handing over.
Which numbers tell you whether engineering is healthy, and which popular ones do you ignore?
Why ask it
Listing measures is easy: how often the team releases, how long a change takes to reach customers, how often a release is rolled back. Fewer candidates can say what they did when one of them moved. Counting each person's tickets or lines of code is a poor sign at this level, because people learn to feed whatever is counted.
When is it right to ship something you know is rough, and who gets to make that call?
Why ask it
Perfectionists and corner-cutters both make expensive CTOs, and this finds out which way a candidate leans. A considered reply separates what can be fixed quietly next week from what cannot be taken back, such as lost data, a billing error or a broken promise to a customer. Notice too whether the call belongs to them, to product or to whoever is on duty that night.
Take me through the worst outage on your watch. What was different a month later?
Why ask it
The month-later part is the one to weigh. A structural change, such as an alert that now fires, a deploy step that was removed or a second person who can make the fix, shows the review led somewhere. 'We were more careful after that' means nothing was changed.
Tell me about a disaster recovery plan you owned: when was it last tested for real, and what did the test find?
Why ask it
Plenty of companies have the document and have never run the drill. Anyone who has run one will remember what went wrong in it, because something always does: a backup that would not restore, a password only one person knew, a recovery that took a day when the plan said two hours. If their last company never tested, ask whether they pushed for it.
How do you deal with security and compliance before a customer forces the issue?
Why ask it
Security work often starts the day a large customer's questionnaire arrives, so any account of doing something earlier stands out. Notice whether security is a certificate to obtain or a habit of the team: access reviewed, systems patched, someone reading the alerts. The first buys you a document and the second buys you fewer incidents.
Have you been through a security incident or a data breach, and what did you do in the first day?
Why ask it
You should hear steps in order and without drama: contain it, work out what was reached, bring in the chief executive and a lawyer, then decide who must be told. Who has to be notified, and how fast, depends on the country, the industry and your contracts, so the careful reply includes taking advice. Never having had an incident is possible, but then the interesting part is how they would know.
Who should be able to see customer data, and how have you enforced that in practice?
Why ask it
Loose handling of customer data is a risk the whole company carries, not only engineering. Practical answers are about access that is granted for a reason and removed afterwards, logs somebody reads, and test systems that do not hold real records. The rules differ by country and by industry, so ask which ones they have worked under and who advised them, and take your own advice on which apply to you.
People
How would you describe your leadership style, and how has it changed as your teams grew?
Why ask it
The label itself is cheap: nearly everyone says collaborative or hands-off. The change over time is the evidence, because leading eight engineers and leading eighty through managers need different habits, and whoever has done both can name what they gave up. Compare the description with what a former report tells you.
How many engineers have you hired, and how many have you had to let go?
Why ask it
Candidates tend to skip the second number, and hearing it plainly tells you whether they will manage performance or leave it to you. After several years in charge of a team of real size, a zero more often means hard conversations were put off than that none were needed.
What do you look for when you hire an engineer, and who was the last strong candidate you turned down?
Why ask it
The turned-down candidate shows where their bar really sits: skill without care for colleagues, a brilliant interview with no shipped work behind it, or simply someone unlike the existing team. Probe the last of those, because a CTO shapes who gets hired for years. It is also worth knowing how long their process takes from first call to offer.
What do you say to a strong engineer who holds a better-paid offer from a larger company?
Why ask it
Unless you are the best payer in your market, your CTO will have this conversation again and again. You are hearing their pitch, so judge it as the engineer would: is it about the work, the ownership and the people, or is it a speech about mission? Ask how often it has worked, and what they do when it does not.
Who would follow you here from a previous team, and why would they come?
Why ask it
Names are the point. A leader worth following can usually list two or three people who would take the call, and can say what those people got from working for them. Check any non-solicitation terms in their current contract before anyone acts on the list, since those vary by employer and by country.
How do you organise engineering teams, and what made you last change the structure?
Why ask it
Teams built around products, around layers of the stack or around customers each solve one problem and cause another. The trigger for the last reorganisation tells you whether they change structure to fix a bottleneck they can describe or because a new shape was in fashion. Every reorganisation costs some weeks of lost work, and a candid candidate will put a number on theirs.
How do you handle a senior engineer who quietly resists a direction you have set?
Why ask it
Quiet resistance is harder than open disagreement because it shows up as slow work and not as an argument. Some candidates escalate, some persuade, some rewrite the plan. The reassuring version has them going to the person directly and early, and includes one occasion when the engineer turned out to be right.
Tell me about a dispute between two of your senior people that you had to settle.
Why ask it
Two leads who cannot agree on an approach, or cannot stand each other, will stall a team for a quarter if nobody steps in. Listen for how early the candidate noticed and whether they dealt with the technical disagreement and the personal one separately. If the story ends with one of the two leaving, ask whether that was the plan or the failure.
If a dependable engineer's work dropped off sharply, how and when would you raise it?
Why ask it
Timing is most of the answer: within a couple of weeks and in private, before the rest of the team has started routing work around the person. A good manager begins by asking what has changed, because the cause is often outside work and none of the company's business beyond offering some room. Waiting for the review cycle lets the problem sit for months.
How do you turn good engineers into good managers, and who have you brought up that way?
Why ask it
Once a team is too large for one person to manage directly, the CTO's results arrive through other people, so this matters more than their own technical skill. Ask for a name, what that person runs now, and what they got wrong in their first year in charge. Someone who has always hired managers from outside is not wrong, but your senior engineers will want to hear it before that person starts.
How do you hold a team together through a bad stretch, such as a layoff, a failed launch or months of crunch?
Why ask it
Avoid anyone whose answer is mostly about morale events. People in a bad stretch want to know what is happening, what is being dropped to make room, and when it ends, and candidates who have led through one talk about those three things. Ask what they told the team the morning after the worst day.
What does a healthy engineering culture look like to you, and what would I see on an ordinary Tuesday that shows it?
Why ask it
Asked on its own, the first half gets a list of virtues. The Tuesday clause forces something you could observe: how a code review reads, who talks in a planning meeting, whether a junior engineer can question a senior one's design. Compare the picture with what your own engineers would recognise. A large gap is not disqualifying, but it tells you how much change this hire brings with them.
How have you run a team spread across cities or time zones?
Why ask it
Distributed teams depend on writing things down and on a few hours of overlap that someone protects. Find out what they changed when the team first spread out, such as decisions recorded in documents or on-call handed between regions, and what they never solved. If your team shares one office and they have only led remotely, or the reverse, put that on the table now.
Business
What is the largest engineering budget you have held, and how did it split between people, infrastructure and tooling?
Why ask it
A budget they really held comes back as rough proportions from memory, along with the line that grew fastest, which is often the cloud bill. Follow with what they renegotiated or switched off. If the budget was never theirs, find out whose it was and how much say they had.
From what you have seen, how does this company make its money, and where could technology move that number most?
Why ask it
A CTO is an executive first, and this checks whether they prepared like one. A wrong guess matters less than how they reason: do they reach for revenue, for the cost of serving each customer, or for speed of delivery? Someone who has not looked at your pricing page before a final-round interview has told you how curious they are about the business.
How much time do you spend with customers, and what did you last change because of something one told you?
Why ask it
Technical leaders who never hear a customer build for an imagined one. A recent, specific change is the evidence, for instance a feature reordered after a support call or an integration fixed after a sales visit. If you sell to other companies, find out whether they have sat in on a security review or a renewal, because your sales team will need them there.
Pick something technical that matters to this business and explain it to me as if I had never worked with engineers.
Why ask it
You will rely on this person to explain engineering to the board, to customers and to you, so sample it now. A clear explanation uses an everyday comparison, says what the thing costs and what goes wrong without it, and takes about two minutes. If a technical person on your panel winces at the simplification, ask them afterwards whether it was wrong or merely plain.
How do you choose a major vendor, and when did you last walk away from one?
Why ask it
Cloud, data and security suppliers are among the largest commitments a CTO signs, and they are hard to reverse. Good practice sounds like a short trial against your own data, a look at the exit terms before the price, and one named owner for the relationship. Walking away is the test of whether the exit was ever real.
When have you used contractors, an agency or an offshore team, and how did it work out?
Why ask it
Each of these can work and each can fail, so what counts is whether they have run it and what it cost in coordination: time zones, handovers, code nobody in-house understood afterwards. A flat always or never tends to be one bad experience speaking.
Tell me about a time you told a chief executive something they did not want to hear.
Why ask it
If your CTO cannot do this, you hear about the slipped date or the security gap from a customer. You want the occasion, the words they used and how long they waited before saying them. Notice whether the chief executive in the story comes across as a fool or as someone with other pressures.
What have you been through with investors or buyers: a fundraise, technical due diligence, an audit?
Why ask it
If a funding round or a sale is anywhere on your horizon, the CTO will spend weeks answering an outsider's questions about code ownership, licences, security and the people the system depends on. Someone who has sat through it knows what to tidy up a year ahead. Lack of the experience is not a reason to pass, but then make sure someone on your board has it.
Fit
What do you think the CTO's job is at a company of our size, and which parts would you hand off first?
Why ask it
The title covers very different jobs: chief architect, manager of managers, the technical voice in sales meetings, or all three at a small company. Set their version beside the one you wrote down before the search began. Where a VP of engineering exists or is planned, the line between the two roles belongs in this answer.
Why this company, and what would you be giving up to come here?
Why ask it
Most candidates have the reason for joining rehearsed. What they would leave behind is less polished: a larger team, a higher salary or a well-known employer is a real cost, and how they describe it shows what they expect in return, whether scope, equity or a problem they care about. If they are giving up nothing, ask what else is on their list.
Why are you leaving your current role, and what would have kept you there?
Why ask it
Senior people often leave over authority, money or the person they report to, and all three could recur with you. Whatever would have kept them is the condition to check against your own offer. Take a calm account of a disagreement as a good sign, and a long list of other people's failings as a preview.
Which stage of company do you do your best work in, and what happens when we grow past it?
Why ask it
Few people are equally good at building the first version, scaling the team and running a mature organisation, and the self-aware ones know which is theirs. A candidate who says they would hire a successor or move to a narrower role when the time comes is easier to work with than one who claims every stage. It also gives you both words for a conversation that otherwise arrives as a surprise.
Talk me through your first ninety days here: who would you meet, what would you read, and when would you start changing things?
Why ask it
A grounded plan starts with listening: the code and the incident history, time with the engineers one to one (all of them on a small team, a cross-section on a large one), and the existing meetings sat through before any are changed. What they want to have learned before the first change says more than the date they give for it. A reorganisation planned before day one is a template, not a diagnosis.
From what you know so far, what would you change here and what would you leave alone?
Why ask it
Naming something worth keeping takes real attention to what you have told them during the process, so that part of the answer sorts candidates quickly. Be wary of anyone who would keep nothing, and equally of anyone who would change nothing.
What should we hold you to at the end of your first year?
Why ask it
Letting the candidate write their own measures shows how they define the job. Look for a mix you could check without being technical: releases reaching customers on the dates given, fewer incidents, key hires made, a budget kept. Write the answer down and bring it to the offer conversation, because agreed measures are much harder to set once someone has started.
What kind of chief executive do you work best with?
Why ask it
This is a direct compatibility check, so the person they would report to should be the one asking. A candidate who wants wide autonomy and a founder who reviews every decision tend to grind against each other, and it is cheaper to find that out now. Describe how you really work and watch the reaction.
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 do you want to ask us that you suspect we would rather not answer?
Why ask it
Serious candidates are interviewing you as well, and their questions show how they would examine any big decision. Expect runway, why the last technical leader left, who really sets the roadmap and how the board behaves under pressure. Answer straight: a candidate who accepts on a rosy picture tends to leave once the real one appears.
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.
Share the groups out between interviewers
Nobody gets through this list in one sitting, and a candidate asked the same thing by four people learns little about you. Give Track record and Strategy to whoever can judge a technical answer, Delivery and risk and Business to the chief executive or a board member, and People to the engineers and managers who would report to the hire. Keep Fit for the last conversation, with the person the CTO would report to. An hour holds six to eight of these once the follow-ups are counted.
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 usually tells you more than a prepared presentation about strategy, and it is hard to bluff 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. Tell the candidate before you contact anyone: what a former employer is willing or allowed to say varies by company and by country.
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 can mean 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 in an interview tends to show up later in how engineering treats 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.
Straying into personal territory
Questions about age, family plans, health, religion and similar subjects are restricted or unlawful in hiring in many places, and the rules differ by country and state. Nothing on this list needs them. If you are unsure what applies where you hire, ask whoever advises you on employment before the interviews start.
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.