The CTO interview: what one hour reveals in due diligence

The data room shows artifacts. The CTO session shows judgment. In most of our engagements, the single hour that changes the most findings is not spent reading code or documents, it is spent in conversation with the person who built the system, and the difference between a good CTO interview and a bad one in due diligence is almost entirely in how it is run.

Run badly, it is a deposition: a checklist read aloud, defensive answers, an hour of mutual performance that confirms whatever the data room already said. Run well, it is two engineers talking shop, and within twenty minutes you learn things no document will ever contain: where the bodies are buried, what the team is actually proud of, and how this person thinks when something is on fire.

Before the CTO interview: read everything

The session earns its value through preparation, and the rule is absolute: never spend the hour on facts the data room already answers. Asking a CTO to recite the stack, the headcount, or the deployment cadence wastes the scarcest resource in the deal and signals that you did not do the reading, which changes how seriously everything else you ask is taken.

We schedule the session late, after the document review and most of the code read. By then we arrive with something better than questions: hypotheses. The architecture diagram says one thing and the repo suggests another. The incident history looks suspiciously short for a system this size. The eval results in the data room stop three months ago. Each gap becomes a line of conversation, and the session becomes what it should be: the place where the story in the documents gets tested against the person who lived it.

Questions that open people up

Interrogation produces guarded answers. Shop talk produces true ones. The questions that work are the ones a respected colleague would ask, and after enough sessions we keep returning to the same few.

What would you rebuild if you had six months of peace. Every real CTO has this list ready, and the answer maps the system’s actual weak points faster than any scan. What breaks most often, and what do you do about it. Walk me through the worst incident of the past year, from first alert to postmortem. What does the engineering team argue about. What did you try that did not work.

Notice what these have in common: none can be answered from marketing material, all invite honesty about imperfection, and each has a natural follow-up thread. A CTO who engages with them is showing you the system as it is. And the conversation stays technical enough that evasion is visible: an engineer talking to an engineer cannot hand-wave for long before both sides know it.

The signals in how failures are discussed

Of everything in the session, the way a CTO talks about failure carries the most information, because it is a direct read on the organization’s maturity.

A healthy answer to the incident question has texture: a specific date, the misleading first symptom, the wrong turn taken before the right one, what changed afterward, all delivered without embarrassment. That texture means incidents are examined rather than survived, and that the person in charge holds the details because the details were worked.

The concerning answers form a pattern too. Everything serious is attributed to a vendor, a departed employee, or bad luck. Or the opposite claim: we have never really had a major outage, which for a production system of any age means either monitoring that cannot see or a definition of "major" doing heroic work. Precision is the general-purpose signal here: operators who actually run their systems answer with numbers, latencies, dates and counts, without reaching for a dashboard. Vagueness from the top, on a system this person supposedly runs, is a finding in itself. The same precision test applies when performance claims come up, where the session feeds directly into how we verify AI performance claims.

Testing the system, respecting the person

One constraint shapes the whole hour: if the deal closes, this person may be the most important employee in the portfolio company, and they will remember exactly how diligence treated them. A session run as a trap poisons a relationship the investor is about to depend on, and it does not even produce better findings, because people under attack stop talking.

So we are explicit about the frame: we are here to test the system, and the more honestly its weaknesses are on the table now, the fewer surprises hurt everyone later. Said plainly, this changes the session. Most CTOs are relieved to talk to someone who can follow the technical detail, and known weaknesses honestly presented move from red flags to line items. The session is also where the key person question gets its most useful data, not by asking "are you a single point of failure" but by watching which topics only this person can discuss.

What the session produces, finally, is not testimony to be quoted but claims to be checked. Everything material gets cross-referenced against the repo, the logs, and the documents, and the divergences, in either direction, are what actually enter the report with a severity attached. That triangulation between conversation, code, and data room is the core mechanism of our technical and AI audit: any one source can mislead, but they rarely all mislead in the same direction.