Director, VP, head-of and CTO interviews test whether you can own strategy, organisation, budget and risk for a business, not a team. The loops lean on cases, written exercises, presentations and panels, they vary widely by company type and region, and they reward specific, owned decisions over frameworks.
Steady demand20 min readDirector of Engineering, Senior Director of Engineering, VP of Engineering, Head of Engineering, Chief Technology Officer, Site or Centre Leader, Global Capability CentreUpdated 2026-10-10
Assumes you know: Several years managing managers, or owning an engineering function end to end, Comfortable reading a budget, a business case and an incident report
Overview
What this area actually covers
Executive engineering leadership is accountability for an engineering function as
a part of a business. A director, VP, head of engineering or CTO owns what the
function is for, how it is organised, what it costs, what it is betting on, and
what happens when it fails in public. The unit of work is no longer a team's
delivery or a single system's design. It is a set of choices about where money,
people and attention go, and the consequences of those choices arrive a year or
two later, usually after the interview panel has forgotten your name.
That shift is why these interviews feel unfamiliar even to strong senior
managers. An engineering manager loop asks how you handled a person or a
project. An executive loop asks how you decided what the organisation should
stop doing, how you justified a budget to someone who does not care about
technology, how you restructured without losing the people you most needed, and
what you told a board when something broke. The answers draw on management
experience, but the frame is the business, and an answer that stays inside
engineering is scored as an answer from the level below.
The section covers six bodies of judgement and two bodies of format. The
judgement areas are strategy, organisation design, AI adoption, build versus buy
and vendor decisions, budgets and business cases, and reliability and incident
leadership. The format areas are the interview mechanics themselves, such as
30-60-90 day plans, presentations, executive and board panels, bar-raiser style
rounds and reference checks, and a set of worked case studies and take-home
exercises with actual answers rather than advice about answering.
Several things are wrongly bundled in. Principal and distinguished engineering
roles are senior and influential, but they are individual-contributor roles and
are covered under the staff-level material, not here. Line management of a team,
including one-to-ones, feedback and hiring for a single team, lives in the
engineering management section. And deep technical design, the kind tested in a
system design round, is assumed rather than taught: an executive candidate is
expected to be able to read a design and ask the question that matters, not to
draw one under time pressure.
Now practise it
44 interview questions in Executive & Engineering Leadership, each with the rubric the interviewer is scoring against.
The subsections follow the decisions an executive is accountable for, then turn
to the formats in which those decisions are examined. Candidates are usually
strong in two or three of the judgement areas from their own history and thin in
the rest, and the format areas are where otherwise strong candidates lose an
offer through unfamiliarity rather than weakness.
Subsection
What it is for
Strategy & Vision
Turning a business goal into a technical strategy with real choices
Organisation Design & Scaling
Structure, spans, ownership and growth from tens to hundreds
AI Adoption & Transformation
Rolling out AI tools and features, measuring change, managing risk
Build, Buy & Vendors
Total-cost decisions, vendor exits and platform bets
Budgets & Business Cases
Headcount, cloud spend, cuts, modernisation cases, due diligence
Reliability & Incident Leadership
Leading through outages and making reliability a habit
Executive Interview Formats
Plans, presentations, panels, bar raisers and references
Leadership Case Studies & Take-homes
Worked answers to the written and live cases loops set
Strategy & Vision
This is the work of turning "the CEO wants growth in a new market" into a
technology strategy: a diagnosis of the actual situation, a guiding policy that
makes some options more attractive and others off the table, and a coherent set
of actions with measures. It exists as its own area because the most common
failure at this level is presenting a roadmap, which is a list of things you
will do, and calling it a strategy, which is an argument about what matters and
what you will deliberately not do. Inside you will find questions on writing a
two-year strategy, choosing between competing rewrite proposals, answering a
board that thinks engineering has slowed down, and holding your ground when a
peer executive challenges your plan in front of the CEO.
Organisation Design & Scaling
Organisation design covers spans of control, team boundaries, ownership of
services, when to introduce a platform team, how to hire and grow managers of
managers, and how to grow or shrink an organisation without breaking it. It sits
apart from the engineering management material because the questions are about
the shape of the system of teams rather than the health of one team. The pages
include before-and-after organisation charts, a fifty-to-two-hundred scaling
question, a shared-ownership dispute taken at organisation level, and a
reduction in headcount handled with care for the people who remain, with a clear
statement that the legal and HR steps vary by country and must involve the
right specialists.
AI Adoption & Transformation
This area deals with rolling AI coding assistants and AI-powered product features
out across an organisation: the pilot, the policy on what code and data may be
sent to which tools, the guardrails before a customer-facing feature ships, the
evidence you bring to a board, and what the change means for how junior
engineers are hired and grown. It is separate because it is now a near-certain
topic in senior loops, and because the honest answer involves uncertainty about
measurement that candidates are tempted to paper over. The pages are explicit
about what can and cannot be attributed to a tool, and they avoid productivity
figures that nobody can substantiate.
Build, Buy & Vendors
Build versus buy is a cost and risk decision dressed up as a technical one. This
subsection works through a total-cost comparison for an internal developer
platform, replacing an expensive vendor with an in-house build, responding to a
large price rise at renewal, the single-cloud versus multi-cloud decision, and
what to insist on before signing a strategic vendor so that leaving later is
possible. It earns its own area because these decisions commit money and people
for years and are among the clearest tests of whether a candidate thinks in
terms of the business. Every cost table states its assumptions and labels its
figures as illustrative.
Budgets & Business Cases
Budgets covers headcount planning across product lines, cutting cloud spend
without hurting reliability, a mid-year budget cut, showing what a platform team
returns for its cost, and a short technical due diligence on an acquisition
target. It is distinct from build versus buy because the audience is usually a
CFO or a finance partner, and the skill is translating engineering realities
into cost, risk and speed in a form that survives scrutiny from someone who does
this for a living. Accounting treatment, such as what can be capitalised, is
described as something to agree with finance rather than stated as a rule,
because it depends on jurisdiction and company policy.
Reliability & Incident Leadership
The executive role in reliability is different from the on-call engineer's or
the incident commander's. This subsection covers the first hour of a major
outage from the executive's chair, presenting an outage to a board, changing an
organisation where reliability work always loses to features, and leading
through a security incident that exposes customer data. It exists because these
moments are where executives are most visibly judged, and because the instinct
to take over the technical response is usually the wrong one. Regulatory and
notification obligations are presented as varying by jurisdiction, with the
leader's job framed as knowing whom to bring in and when.
Executive Interview Formats
This area is about the mechanics: preparing a 30-60-90 day plan, building a
twenty-minute presentation on an organisation's future, what a CEO and board
panel is evaluating, which stories survive a bar-raiser style round at director
level, how reference and back-channel checks tend to work, and how to evaluate
an offer pitched a level below your current title. It is separate because the
formats are unlike anything in an engineering loop and are rarely explained to
candidates in advance. Everything here is hedged: formats differ between
companies and between hiring processes at the same company, and no page claims
that a particular organisation uses a particular format.
Leadership Case Studies & Take-homes
The final area contains worked answers to the written and live cases senior
loops set: a two-page technical vision memo, an organisation redesign as a
written exercise, a migration business case, scaling a global capability centre
from fifty to five hundred engineers, a retrospective on a programme you led, a
press-release-style narrative for a platform not yet built, and a post-merger
integration plan. It sits last because it draws on all the other areas, and
because what candidates most often lack is not advice but a concrete example of
what a good submission looks like on the page.
Where it sits in a real business
An engineering executive sits between the executive team, which decides what the
company is trying to achieve, and an engineering organisation that has to make
it real. Above or beside you are the CEO, the CFO, the product leader and, in
many companies, a board that sees you a few times a year. Below you are
directors and managers whose judgement you rely on and whose teams you no longer
see directly. Around you are finance, legal, HR, security and procurement, each
of which can stop a plan you thought was settled.
Money moves through this role in two forms. Headcount is the largest line in most
engineering budgets, and it is committed for years once someone is hired.
Non-people spend, such as cloud infrastructure, licences and vendors, is the line
that finance can see changing month to month and will ask about first. A large
part of the executive job is explaining both lines in terms the rest of the
executive team cares about: what the money buys in revenue protected, risk
reduced or time to market, and what would happen if it were spent differently.
Information moves upwards in a compressed form. A board does not want the
incident timeline; it wants to know the impact, the cause, what has been fixed,
what systemic change follows, and whether the risk posture has moved. An
executive who cannot compress without distorting will be distrusted by the board
and resented by the engineers whose work has been misrepresented, and both
groups notice.
Who does this work
Titles at this level are even less stable than below it, and the same title can
describe very different jobs.
Title
Typical scope
What the job tends to emphasise
Director of Engineering
Several teams through managers
Delivery across teams, managers of managers, hiring at scale
The engineering organisation or a major part of it
Execution, organisation, people systems, cost
Head of Engineering
Varies from a small company's whole function to a regional unit
Whatever the company lacks, often both strategy and execution
CTO
Technology direction for the company
Strategy, external credibility, board relationship, sometimes the whole function
Centre leader in a capability centre
A site of a global company
Scaling, ownership split with headquarters, retention, local leadership
The CTO and VP of Engineering split deserves a sentence. In some companies the
CTO owns technology direction and external representation while the VP owns
running the organisation; in others one person does both; in a small startup the
CTO may still write code. A candidate who prepares for the wrong version of the
job will give polished answers to questions nobody is asking, so establishing
which job is on offer is the first piece of preparation, not the last.
The week looks nothing like a manager's. Much of it goes on planning and
budget conversations, staff meetings with directors, cross-functional reviews,
hiring of senior people, written documents for the executive team, and a steady
background of escalations that need a decision rather than more analysis. Very
little of it involves direct contact with individual engineers, which is the
loss most new executives underestimate.
What these loops test
Across the eight areas, panels at this level tend to probe the same six
capabilities, and it helps to know which one a given question is really after.
Capability
What a strong answer shows
What a weak answer sounds like
Strategy
Explicit choices, what you will not do, measures
A list of initiatives with no trade-off
Organisation
Ownership, spans and sequencing of change
A new org chart with no transition plan
AI adoption
Pilot, policy, guardrails, honest measurement
Enthusiasm, or blanket refusal, without evidence
Build versus buy
Total cost with assumptions, exit, non-cost factors
What unites them is ownership at business scope. A panel is listening for
whether you made the decision, why you made it given what you knew, what it cost,
and what you would do differently, all at a scale where the team was an
organisation and the stakeholder was the executive team.
The formats, and how they tend to work
Executive loops are less standardised than engineering loops, and first-hand
accounts at this level are thin, so treat everything in this section as a
description of common patterns rather than a promise. Ask the recruiter or the
search firm what each stage is; at this level that question is expected rather
than awkward.
A loop often starts with a recruiter or search-firm conversation, moves to the
hiring executive, and then expands to some combination of the formats below
before references and an offer.
Loading diagram…
The stage to notice is the last but one. References are frequently taken before
an offer at this level rather than after it, and they can include people you did
not nominate, so the reputation you built in previous roles is part of the loop
whether or not you prepare for it.
Format
What it usually involves
What it is really testing
Live case study
A business scenario discussed or whiteboarded with a panel
Structuring ambiguity, trade-offs, thinking aloud under challenge
Take-home written exercise
A memo, strategy or org redesign submitted in advance
Clear writing, explicit choices, quality of assumptions
Presentation
A vision talk, a past programme, or a 30-60-90 day plan
Specificity to their context, executive communication, handling questions
Executive or board panel
Conversation with the CEO, peers or board members
Business literacy, judgement, how you would work with them
Bar-raiser style round
An interviewer from outside the team with a veto or strong voice
Depth of stories under repeated "why", consistency with the bar
Reference checks
Formal references and informal back channels
Whether your account of yourself matches others'
Two of these deserve a further note. The 30-60-90 day plan is not a commitment
document; panels generally know you lack the information to commit. What it
shows is how you would learn, what you would diagnose, and which early outcomes
you would aim for, so a plan made of activities with no outcomes reads badly. And
in the bar-raiser style round, stories set at team scope tend to fail, not
because they are weak, but because they answer a question from the level below.
How loops differ by company type and region
The same title is hired very differently depending on who owns the company and
where it is. These are tendencies, not rules, and any individual process can
break them.
Company type
What tends to be emphasised
Early-stage startup
Founder fit, hands-on credibility, building from little, speed
Scale-up
Scaling hiring and management layers, process without bureaucracy
Value creation plans, cost and efficiency, integration, pace
Global capability or captive centre
Scaling a site, ownership split with headquarters, retention, local leadership
Region shifts the picture again. In the US, loops at larger technology companies
can be long and highly structured, while smaller companies may move quickly
through a handful of conversations. In the UK and the rest of Europe, notice
periods are often longer, which affects timing and how much a 30-60-90 plan can
assume, and employment law shapes how restructuring questions should be
answered. In India, a large share of senior engineering leadership hiring is for
global capability centres, where the questions often turn on scaling a site,
negotiating ownership with headquarters, and retaining people in a competitive
market. In the Gulf, roles in government-linked or family-owned groups may
weight relationship, transformation programmes and vendor management more
heavily. In South-East Asia, Australia and Canada, the mix depends heavily on
whether the role is regional leadership for a multinational or a local company.
None of this changes what a good answer is; it changes which questions you are
most likely to be asked and which context you should show you understand.
Demand, adoption and how that is changing
Executive roles are few by construction. Each organisation has a small number of
them, they turn over less often than individual roles, and many are filled
through networks and search firms rather than open postings, so the visible
market understates the real one and the competition for each role is high. The
honest bucket is steady: the roles exist wherever companies have engineering
functions, but they do not expand quickly.
Three forces are reshaping what the roles ask for. Cost discipline since the
early 2020s has put budget and efficiency questions into almost every loop,
including questions about flattening management layers. AI adoption has become
an expected topic, and candidates are now asked both how they would roll tools
out and how they would know whether anything improved. And the growth of global
capability centres has created a substantial set of senior leadership roles
outside headquarters, with a distinctive set of problems. None of this predicts
how many roles there will be; it describes what the existing roles now test.
What makes it hard
The first difficulty is that the evidence is old and indirect. Your best stories
are about decisions whose results took a year to arrive, made with people who
have since moved on, and you have to tell them with enough specificity to be
believed and enough honesty about what went wrong to be trusted.
The second is scope translation. Many candidates were genuinely good at the
level below and tell stories that prove it. Converting "my team shipped the
migration" into "I decided which of three migrations the organisation would
fund, and here is what we gave up" requires you to have actually made the larger
decision, and if you have not, the panel will find out under follow-up.
The third is that there are few right answers and many defensible ones. A panel
can accept either side of build versus buy, or a different organisation design
from the one they chose. What they will not accept is a choice without stated
criteria, a plan without a sequence, or a cost figure without assumptions.
The fourth is that the boundaries with law, accounting and HR are real. A
question about a reduction in headcount, a data breach or capitalising
development cost has a legal or accounting dimension that varies by country. A
strong candidate names who must be involved and what varies; a weak one states a
rule they cannot know applies.
A preparation order
Prepare in the order that builds the most transferable material first. The
stories and the written artefacts underpin everything else; the format practice
only works once those exist.
Loading diagram…
The step people skip is the third. Writing a memo and a business case in your own
words, with your own assumptions, is what makes the live case and the
presentation feel familiar rather than improvised, and it surfaces the gaps in
your stories before a panel does.
In more detail, the order looks like this:
Clarify the job. Which of the CTO, VP, head-of or centre-leader versions
is this, who does it report to, what is the company type, and what problem is
the hire meant to solve.
Build your stories. Six to eight, at organisation scope, covering a
strategy you set, an organisation you changed, a cost decision, a vendor or
build decision, an incident you led through, a senior hire or removal, and a
decision that went wrong. Each needs your choice, the alternatives, the cost
and the outcome.
Write the artefacts. One two-page strategy memo and one business case with
a cost table and stated assumptions, about a real or realistic situation.
Rehearse the formats. A twenty-minute presentation with time for
questions, and a 30-60-90 plan with outcomes per phase rather than
activities.
Practise live cases. Ask someone to interrupt, challenge your assumptions
and add a complication halfway through.
Brief your references. Choose people who saw you at the relevant scope,
tell them what the role is, and remind them of the specific work they saw.
What assessors tend to score
Scoring at this level is less formal than in an engineering loop, but panels
tend to converge on a similar set of questions, and it is worth preparing against
them deliberately.
What is assessed
What earns credit
Business framing
Starting from the company's goal, not engineering's preference
Explicit choices
Saying what you will not do, and why
Quality of assumptions
Numbers derived from stated assumptions, labelled as such
Sequencing
A plan with phases, decision points and kill criteria
Ownership
"I decided" with reasons, including decisions that went badly
Communication
Compressing for the audience without distorting
Judgement about specialists
Knowing when legal, finance, HR or security must be involved
Self-awareness
Honest misses and what you changed as a result
The one that most often separates candidates is the last. A panel hiring an
executive is hiring someone who will make expensive mistakes, and they want
evidence that you notice your own and change course, rather than a record that
appears to contain none.
Why study it
Study this section if you are a senior manager or director aiming at the next
level, if you have an executive loop booked and have never seen the formats, or
if you lead a capability centre and are being considered for broader scope. It
is also useful for staff and principal engineers who work closely with
executives, because understanding how a strategy, a budget or a vendor decision
is argued at that level makes your own proposals far easier to land.
Do not study it as a shortcut to the title. The material cannot substitute for
having owned the decisions, and a well-rehearsed answer about an organisation
you never ran will not survive a second follow-up question. If you have not yet
managed managers, the engineering management section is the better next step,
and this one will make more sense afterwards.
Your first hour
Write a one-page brief for a role you might apply for, real or imagined. The
artefact at the end is a document you can reuse for every company you consider.
ROLE BRIEF - VP of Engineering, illustrative
The job on offer
Reports to: CEO. Scope: whole engineering function, about 120 people
(assumed). Company type: scale-up. Why the role exists: delivery has
become unpredictable as the team grew.
What I think the first problem is
Ownership is unclear between teams, and planning is done per team
with no organisation-level trade-offs. Evidence I would look for to
confirm or reject this in the first month.
The three stories that best fit this job
1. The reorganisation I led, what I chose and what it cost.
2. The budget cut I handled, what I stopped and why.
3. The decision that went wrong, and what I changed afterwards.
What I do not know and would ask
Budget ownership, the board's view of engineering, who decides
build versus buy, and what the last person in the role struggled with.
Now read it critically. If the stories you chose are all at team scope, that is
the gap to close before anything else. If the first problem is a guess with no
way of testing it, your 30-60-90 plan will be a list of activities. And if the
questions section is empty, you have not yet worked out which version of the job
this is.
What this is not
It is not a more senior version of the engineering management loop. The skills
build on management, but the questions are about the organisation and the
business, and team-level answers are marked down even when they are excellent.
It is not a technical architecture interview. You will be expected to discuss
technology credibly and to recognise a weak design, but nobody is hiring an
executive for their whiteboard diagrams.
It is not legal, accounting or HR advice. Where those areas arise, the pages say
what a leader must involve and what varies by country, and they stop there.
And it is not a set of formats that every company uses. The patterns described
here are common, not universal, and the most useful thing you can do before any
executive loop is ask what each stage actually involves.