VP and CTO: ninety seconds with the CTO

"You get fifteen minutes with the CTO at the end of the loop. What do you ask, and what are they assessing?"

What the round is

The final conversation, usually short, with someone who will not evaluate your technical depth because four other people already did. They are assessing three things and none of them is whether you can code.

1. WOULD I PUT THIS PERSON IN FRONT OF THE BOARD, A
   CUSTOMER, OR MY PEERS?
   Can they hold an altitude, be concise, and be honest
   about uncertainty in a room where the other people are
   not engineers.

2. DO THEY THINK ABOUT THE BUSINESS, OR ONLY ABOUT THE
   SYSTEM?
   Staff and above are expected to connect technical
   decisions to outcomes without being prompted.

3. DO I WANT TO WORK WITH THEM?
   Unfashionable to say, and it is a real component of a
   final-round conversation with a senior leader.

Commonly confused with a formality. It is frequently a veto round rather than a scoring round: it rarely rescues a weak loop and it can end a strong one, which makes the downside asymmetric and worth preparing for.

Also commonly confused with a chance to demonstrate depth. Going deep is the specific failure here. The CTO has read that you are technically strong; demonstrating it again at the wrong altitude demonstrates that you cannot calibrate.

The problem it solves, from their side

A CTO hiring a staff engineer is buying judgement they will not personally supervise.

They will not review this person's designs. They will hear
about them second-hand, in a room, from someone else.

So the question they are actually answering is: when this
person is the most senior engineer in a room with a VP of
Product and a customer, does the company come out of that
room better or worse?

That reframing is what makes the round predictable, and it explains why the questions are about trade-offs and communication rather than about systems.

Mechanics

The questions you will be asked, and what they are testing

"Tell me about yourself in two minutes."
  -> Testing: can you be concise and choose what matters.
     A five-minute chronological answer fails here and it is
     the most common failure in the round.

"What's the most interesting technical problem you've
 solved?"
  -> Testing: altitude. Can you make it interesting to
     someone who will not follow the mechanism.

"What would you change about how we build software?"
  -> Testing: whether you formed a view during the loop, and
     whether you can criticise constructively.

"Why us?"
  -> Testing: whether you have a reason beyond compensation
     and whether it is specific to them.

"What are you worried about?"
  -> Testing: honesty, and whether you have actually
     evaluated them rather than only being evaluated.

The two-minute self-introduction is worth rehearsing to the second, because it is asked almost always, it sets the tone, and the failure (chronological, five minutes, every job) is easy to avoid and extremely common.

THE SHAPE THAT WORKS

  Where you are now and what you own.      (20 s)
  The through-line: what kind of problem
    you have repeatedly solved.            (30 s)
  One concrete example with a number.      (40 s)
  Why this role, specifically.             (30 s)

"I lead search at [company], about four thousand queries a
second across nine locales. The through-line in my career is
systems where relevance and latency trade against each other,
which I've done in e-commerce search and more recently in
retrieval for LLM applications. The thing I'm proudest of is
taking our p99 from 1.4 seconds to 210 milliseconds by
finding that our small locales were over-sharded, which
nobody had spotted because we were alerting on aggregate
latency. What draws me here is that you're at the point where
retrieval quality becomes the product rather than a feature,
and that's the problem I want to be working on."

Answering technical questions at CTO altitude

The mistake is depth. The correct move is impact with one technical detail as evidence.

THE QUESTION
  "What's the most interesting technical problem you've
   solved?"

WRONG ALTITUDE
  "We had a connection pool exhaustion issue where the
   batch job was holding eighteen of twenty connections and
   Little's Law meant with two usable connections at 8
   millisecond service time we capped at 250 requests a
   second..."
  -> Correct, and the CTO has stopped listening. They cannot
     evaluate it and it tells them nothing about judgement.

RIGHT ALTITUDE
  "We had checkout failing for forty minutes and about four
   percent of people abandoned. The cause turned out to be a
   background job competing with checkout for a shared
   resource, and the interesting part was that it was the
   second incident from the same pattern. So rather than fix
   it twice, I proposed a policy that batch work never
   shares a resource pool with a user-facing path, which
   took about a week across three services. The judgement
   call was spending a week on a policy rather than a day
   on the fix, and I made that case by showing it was
   already the second occurrence."
  -> Impact, then the judgement, then how you made the case.
     One technical detail (shared resource pool) as evidence
     rather than as content.

The structure: outcome, decision, how you got agreement. That is what a CTO can evaluate, and it is what they will hear about second-hand in future.

The questions you ask, which matter more than usual

In this round your questions are a substantial part of the signal, because they reveal what you pay attention to.

STRONG, because they require a real answer and show you
think about the business

  "What's the thing you'd most want fixed in engineering
   that you haven't been able to fix yet?"
     -> Their answer tells you a great deal, and asking it
        signals you expect an organisation to have real
        problems.

  "Where does the company need to be in eighteen months for
   this to have been the right bet?"
     -> Business framing, and the answer tells you whether
        the strategy is coherent.

  "What's the technical decision you're least confident
   about right now?"
     -> Invites honesty, and a leader who can answer it is
        someone you can work with.

  "How do engineering and product decide what not to do?"
     -> Prioritisation is where organisations actually
        differ, and this question is hard to answer with
        platitudes.

  "What does a staff engineer here do that a senior one
   doesn't?"
     -> Direct, and their answer tells you whether the
        level is real or a title.

WEAK, because they are answerable from the careers page or
they signal the wrong things

  "What's the tech stack?"          -> ask an engineer
  "What's the culture like?"        -> unanswerable, and
                                       everyone says the
                                       same thing
  "What are the growth plans?"      -> in the press release
  Anything about compensation       -> this is not that
                                       conversation
  Nothing at all                    -> the worst option, and
                                       it reads as
                                       indifference

"What's the thing you'd most want fixed that you haven't been able to fix yet" is the single best question in this list, because it is hard to deflect, the answer is genuinely useful to you, and asking it signals that you expect a real organisation with real constraints rather than a brochure.

Reading the answers

You are evaluating them, and this is your best opportunity.

GOOD SIGNS
  Specific answers with numbers or names.
  Willingness to name a problem they have not solved.
  A coherent story about where the company is going that
  matches what you heard from other interviewers.
  Curiosity about your questions rather than defensiveness.

WARNING SIGNS
  Every answer is a positive framing with no tension named.
  The strategy contradicts what earlier interviewers said,
  which usually means it is not communicated internally.
  Dismissiveness about a problem you know is real from the
  earlier rounds.
  They cannot articulate what staff means beyond scope
  words.
  They spend the whole time selling rather than assessing,
  which can mean they are desperate to fill the role.

The consistency check across the loop is the most useful thing you can do here: if the CTO's account of priorities differs from what the hiring manager and the engineers told you, that gap is the most reliable signal available about the organisation, and it will not appear anywhere else.

The failure modes, specifically

GOING TOO DEEP
  The most common. They stop listening, and the conclusion
  is that you cannot calibrate.

BEING TOO SHORT
  A two-word answer to an open question reads as
  disengagement. This round is a conversation.

CRITICISING WITHOUT CONSTRUCTION
  "Your architecture seems dated" is a strong claim from
  someone who has seen four interviews. "I noticed X, and
  I'd want to understand the history before forming a view"
  is the same observation, credibly.

HAVING NO QUESTIONS
  Reads as indifference, and it wastes the one round where
  you can actually learn something.

TREATING IT AS A FORMALITY
  It is frequently a veto round, and preparing for it is
  cheap.

A worked example: the fifteen minutes

0:00  "Tell me about yourself."
      -> The rehearsed two minutes. Now, through-line,
         one example with a number, why here.

2:00  "What drew you to us specifically?"
      -> Something concrete from the loop, which proves you
         paid attention: "the retrieval quality problem
         [interviewer] described in round two is the same
         one I've been working on, and you're further into
         it than I expected."

3:30  "What's the hardest technical decision you've made?"
      -> Outcome, decision, how you got agreement. Under two
         minutes. ONE technical detail as evidence.

6:00  "What would you change here?"
      -> Constructive, hedged appropriately: "I only have
         four conversations of evidence, so I'd want to
         check this. But three people mentioned deploy pain
         unprompted, and nobody mentioned it as something
         being worked on, which makes me curious whether
         it's under-prioritised or whether I'm missing
         context."
      -> That is a real observation, honestly bounded, and
         it invites a real answer.

8:00  YOUR QUESTIONS. Two or three, not five.
      "What's the thing you'd most want fixed in engineering
       that you haven't been able to fix?"
      "What does a staff engineer here do that a senior one
       doesn't?"
      "Where does the company need to be in eighteen months
       for this to have been the right bet?"

13:00 Their close, your close.
      -> One sentence on why you want it, if you do. If you
         genuinely are not sure, saying "I'd want to
         understand X before I could say" is more credible
         than false enthusiasm and it frequently gets you
         the answer.

Time discipline is part of the signal. Fifteen minutes with three questions of yours means your answers were about two minutes each, and a candidate who used twelve minutes answering the first two questions has told the CTO something about how they run meetings.

Production evidence

Executive interview practice across large technology companies consistently places a senior leader at the end of a staff-and-above loop, and the published purpose is culture and communication assessment rather than technical evaluation, which is why the altitude expectation differs from every previous round.

Will Larson's Staff Engineer contains accounts of these conversations and notes that they are frequently where an otherwise successful loop ends, which is the basis for treating it as a veto round.

Research on executive communication finds that perceived competence in senior conversations correlates with concision and calibrated confidence rather than with demonstrated technical depth, which is the empirical basis for the altitude advice.

Camille Fournier's The Manager's Path covers what senior leaders look for in staff-plus hires, and the recurring theme is judgement exercised without supervision, which is why the questions are about trade-offs rather than systems.

The consistency-across-the-loop check is standard reverse-due-diligence practice and appears in most credible interview-preparation guidance, because a gap between what leadership says and what engineers say is one of the few reliably observable organisational signals.

The debate

The case for treating it as a formality: the technical rounds decided it, the CTO is confirming a decision already made, and over-preparing for a fifteen-minute chat is anxiety rather than strategy.

The case for treating it as decisive: it is asymmetric. It rarely rescues a weak loop and it can end a strong one, and a fifteen-minute conversation with an unrehearsed two-minute introduction is a cheap way to lose an offer.

The case for using it to evaluate them: it is your only access to the person setting technical direction, and the consistency check against what engineers told you is the most reliable organisational signal available anywhere in the process.

My position: rehearse the two-minute introduction to the second, answer at impact altitude with one technical detail as evidence, and bring three questions you actually want answered.

The introduction is the highest-return preparation in the entire loop relative to its cost. It is asked almost always, it sets the tone, and the failure is stereotyped: chronological, five minutes, every job. Where I am now, the through-line, one example with a number, why here takes an evening to write and thirty seconds to fix.

On altitude, the specific instruction is outcome, then the judgement call, then how you got agreement, with exactly one technical detail serving as evidence rather than as content. Going deep is the most common failure and it does not read as depth, it reads as an inability to calibrate, which is precisely what this round is assessing.

The question I would always ask is "what's the thing you'd most want fixed in engineering that you haven't been able to fix yet", because it is hard to deflect, the answer is genuinely useful to you, and asking it signals that you expect an organisation with real constraints. A leader who cannot name one is either not close to engineering or is selling, and both are worth knowing.

And the evaluation I would actually run is the consistency check: does the CTO's account of priorities match what the hiring manager and the engineers said? A gap there is the most reliable signal in the whole process, it appears nowhere else, and it is available for free in the one round people treat as a formality.

Where I would push back on the "formality" position: the cost of preparing is one evening and the downside is losing an offer you had already earned. That asymmetry settles it regardless of how often the round is decisive.

Follow-up Q&A

"What is the CTO actually assessing?" Three things, none of them technical depth, because four people already assessed that. Whether they would put you in front of the board, a customer or their peers, which is about holding an altitude and being honest about uncertainty. Whether you think about the business or only about the system. And whether they want to work with you. The useful reframing is that a CTO hiring a staff engineer is buying judgement they will not personally supervise, so the question is what happens when you are the most senior engineer in a room with a VP of Product and a customer.

"What's the most common failure?" Going too deep. The CTO has read that you are technically strong, so demonstrating it again at the wrong altitude demonstrates that you cannot calibrate, which is the opposite of the signal you want. The second most common is a five-minute chronological answer to "tell me about yourself", which is asked almost always and is easy to fix.

"How do you answer a technical question at that altitude?" Outcome, then the judgement call, then how you got agreement, with exactly one technical detail as evidence rather than as content. "Checkout failed for forty minutes and four percent of people abandoned; the cause was a background job sharing a resource pool with a user-facing path; the interesting part was that it was the second incident from that pattern, so I proposed a policy rather than a fix, and made the case by showing it had already happened twice." That is what a CTO can evaluate.

"What should you ask?" Three questions you actually want answered, not five. The best one is "what's the thing you'd most want fixed in engineering that you haven't been able to fix yet", because it is hard to deflect, the answer is genuinely useful, and asking it signals that you expect a real organisation with real constraints. Then "what does a staff engineer here do that a senior one doesn't", which tells you whether the level is real. And a business-framed one, like where the company needs to be in eighteen months for this to have been the right bet.

"What are you evaluating in their answers?" Specificity, willingness to name an unsolved problem, and coherence with what you heard earlier in the loop. That last one is the most valuable thing available: if the CTO's account of priorities differs from what the hiring manager and the engineers told you, that gap is the most reliable organisational signal in the whole process and it appears nowhere else. Warning signs are every answer being a positive framing with no tension named, and spending the whole time selling rather than assessing.

"How do you answer 'what would you change here'?" Constructively and honestly bounded. "I only have four conversations of evidence so I'd want to check this, but three people mentioned deploy pain unprompted and nobody mentioned it as something being worked on, which makes me curious whether it's under-prioritised or whether I'm missing context." That is a real observation, the hedge is genuine rather than defensive, and it invites a real answer. "Your architecture seems dated" is the same observation stated in a way that is not credible from someone with four interviews of evidence.

"Is this round actually decisive?" Asymmetrically. It rarely rescues a weak loop and it can end a strong one, which makes preparing for it worth an evening regardless of how often it decides anything. The cost of preparation is a rehearsed two-minute introduction and three questions; the downside of not preparing is losing an offer you had already earned in the technical rounds.

"What if you're genuinely unsure about the company?" Say so, bounded. "I'd want to understand how the platform and product teams split ownership before I could say I'm certain" is more credible than manufactured enthusiasm, and it frequently gets you the answer, which is what you actually need. A senior leader can tell the difference, and false enthusiasm at that altitude reads worse than honest uncertainty.

Common misconceptions

"It's a formality." It rarely rescues a weak loop and can end a strong one. The asymmetry is what makes preparation worth it.

"Show technical depth." They have four rounds of evidence for that. Depth at the wrong altitude demonstrates an inability to calibrate.

"Have lots of questions ready." Three you actually want answered beats five performed. Time discipline is itself part of the signal.

"Don't criticise anything." A bounded, specific observation is a strong signal. An unbounded claim from four interviews of evidence is not.

"You're only being evaluated." This is your only access to the person setting technical direction, and the consistency check against the rest of the loop is the best organisational signal available.

Interview delivery note

Have the two-minute introduction rehearsed to the second, because it is asked almost always and the failure is stereotyped: "Where I am now and what I own, the through-line of what kind of problem I've repeatedly solved, one concrete example with a number, and why this role specifically. Four parts, two minutes, and I'd rehearse it because the default is chronological and five minutes."

Answer technical questions at impact altitude with one detail as evidence: "Checkout failed for forty minutes and four percent abandoned. The cause was a background job sharing a resource pool with a user-facing path, and the interesting part was that it was the second incident from that pattern, so I proposed a policy rather than a fix and made the case by showing it had already happened twice."

Bring three questions and lead with the best one: "What's the thing you'd most want fixed in engineering that you haven't been able to fix yet?" It's hard to deflect, the answer is genuinely useful, and asking it signals that I expect a real organisation rather than a brochure."

Handle "what would you change" with a genuine hedge: "I only have four conversations of evidence, so I'd want to check this. But three people mentioned deploy pain unprompted and nobody mentioned it as something being worked on."

And run the consistency check silently throughout: "the most useful thing I'd do in that room is compare the CTO's account of priorities against what the hiring manager and the engineers said. A gap there is the most reliable organisational signal in the whole process, and it's available for free in the round people treat as a formality."

The Staff & Team Lead Interview Reference