Questions to Ask CTO During Interview
For engineers and engineering managers who have a slot with the CTO in a hiring loop, usually thirty minutes with ten left for your questions. These are the ones that tell you what the job is actually like rather than what the careers page says, with notes on what a weak answer sounds like.
The questions
Open any question for the note
Is this a new role or a backfill, and if it is a backfill, what happened?
Why ask it
New headcount means budget and a mandate; a backfill means you are inheriting someone's unfinished work and possibly their reasons for leaving. A CTO who answers this straightforwardly is usually straightforward about the rest.
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 is the first thing you would want me to ship?
Why ask it
A specific answer means someone has thought about your first month, which correlates strongly with a decent onboarding. A vague answer about ramping up usually means you will spend your first six weeks reading code and guessing at priorities.
How does an idea get from someone's head onto an engineer's plate here?
Why ask it
You are looking for the actual path: a planning cycle, a product review, a founder who walks over and asks. Every company has one, and if the described process sounds cleaner than any you have worked in, ask what happened to the last urgent request.
How long does a pull request usually wait for review?
Why ask it
This is a number, so evasion is informative. Days rather than hours usually means reviewers are overloaded or ownership is unclear, and it will be the thing that most affects how your week feels.
How often do you deploy, and what does a deploy involve?
Why ask it
Deploy frequency is the single best proxy for engineering health because it depends on tests, environments and confidence all working. A weekly release with a manual checklist is not disqualifying, but it tells you what your first year will contain.
What is the on-call rotation, and when was the last time someone was woken up?
Why ask it
Asking for the last incident rather than the policy gets you the truth about alert noise. A CTO who cannot remember either has a quiet system or does not carry the pager, and it is worth finding out which.
What share of engineering time went to maintenance and bug work last quarter, and how much to new features?
Why ask it
Naming last quarter rather than asking in general prevents an aspirational answer. If the split is heavily towards keeping things running, that is the job you would be taking, whatever the role description says.
Which part of the system are you least happy with?
Why ask it
Every CTO has an answer and most enjoy giving it, so a refusal is a red flag about candour. The specific complaint also tells you which service you will end up owning, since new hires are usually pointed at the worst part.
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.
When engineering and product disagree about scope, who decides?
Why ask it
There is always an answer, and it is either a person, a process, or whoever escalates loudest. If the CTO says these disagreements do not happen, either they are not close to delivery or engineering has stopped pushing back.
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.
How do you decide whether to build something or buy it?
Why ask it
The answer reveals both engineering taste and budget reality. A CTO who has a rule about core versus supporting systems has thought about it; one who defaults to building tends to run teams that are permanently maintaining infrastructure.
Who was promoted on this team most recently, and what did they do to get there?
Why ask it
This is far more informative than asking about the career ladder, because it turns a document into evidence. If nobody comes to mind, promotions here are rare, and you should ask about that directly rather than assuming.
How do you handle a strong engineer who is difficult to work with?
Why ask it
The answer tells you what behaviour is tolerated when output is high, which shapes daily life more than any stated value. Concrete stories about coaching or exits are good; a claim that it has never come up is not credible in any team of size.
Has anyone left this team in the past year, and what were their reasons?
Why ask it
Turnover is the most useful signal you can get in an interview and one of the least asked about. You are not looking for zero departures, you are looking for a CTO who knows why people left and does not blame them for it.
What will you personally be judged on this year, and where does this role fit into that?
Why ask it
This connects your work to whatever the CTO is actually under pressure to deliver, which is the best predictor of whether your projects will get support. If your role does not clearly sit inside their goals, expect to be deprioritised.
What can you tell me about funding and runway, or about how this team's budget is set?
Why ask it
Phrased as an invitation, this is a fair question at any stage and a CTO expects it from senior candidates. What matters is whether they answer with something concrete or with reassurance, because the second usually means the situation is tighter than they can say.
What do you expect will be hardest about this job in the first six months?
Why ask it
Asking for the difficulty rather than the opportunity tends to produce the most honest thirty seconds of the interview. An answer naming a specific system, stakeholder or migration is a genuine warning you can act on.
What is your biggest hesitation about my background, so I can address it now?
Why ask it
This gives you the chance to answer an objection that would otherwise be discussed after you leave the room. Take the answer seriously rather than defending immediately, and note whether the concern is about skills, which you can argue, or level, which you usually cannot.
How to use these questions
Practical guidance for the conversation itself
Using the time you actually get
Plan for three questions, not twenty
A CTO slot is usually thirty minutes and the last ten are yours, which is three questions with follow-ups. Pick the three whose answers would change your decision, and put the one you care about most first in case the time disappears.
Ask for the last instance, not the policy
Every question here works better as "when was the last time" than "how do you usually". Policies are written down and often aspirational; the most recent example is what the team really does.
Save funding and turnover for the CTO
A recruiter will deflect these and a peer interviewer may not know. The CTO slot is the one place in the loop where questions about runway, budget and departures get a real answer.
Do not spend a question on anything published
Tech stack, headcount and product basics are usually on the site or in the job description. Read them beforehand and use your questions on things only this person can tell you.
What the answers tend to reveal
- Whether numbers appear unprompted. Deploy frequency, review turnaround and last quarter's maintenance split are all countable, and a CTO who knows them is close to the work.
- How they describe people who left or were let go. Contempt here predicts how you would be described later.
- Whether the process they describe matches what your peer interviewers said. Contradictions between levels are more telling than anything either of them says alone.
- How they answer a question they would rather not. Straight discomfort is a better sign than a smooth non-answer.
- Whether your first project is already specific. Someone has planned your arrival, or nobody has.
Common pitfalls
Treating the question slot as no longer an evaluation
The questions you choose signal what you care about, and a CTO will read them. Asking only about perks and hours lands differently from asking about the deploy pipeline, even when both are reasonable things to want to know.
Asking a question you have already been given the answer to
If an earlier interviewer explained the release process, do not ask again from scratch. Reference what you heard and ask what they would change about it, which shows you were listening.
Interrogating rather than asking
Three sharp questions in a row with no reaction in between reads as an audit. Respond to each answer briefly before moving on, the same as you would in any working conversation.
Ignoring a bad answer because you want the job
Candidates routinely hear that the team has no process, high turnover and a two-year migration, and then take the offer anyway. Write the answers down the same day and read them again before you decide.
Follow-ups worth keeping ready
- "When was the last time that happened?" The single most useful follow-up in any interview.
- "What did you try before that didn't work?" Turns a tidy story about a decision into a real one.
- "Who would disagree with that inside the company?" Reveals internal tension without asking about it directly.
- "If I asked the engineer doing that job today, what would they complain about?" Often gets you the most candid answer of the conversation.