What the panel reads from a vision presentation
The brief sounds like an invitation to describe a great engineering organisation. In an executive interview it is closer to a test of whether you can do the first quarter of the job before you have it. A director or VP turns a business plan into an organisation. The vision presentation is a compressed sample of that: can you form a view from incomplete information, commit to it, and defend it to people who know their company better than you do?
Formats vary, so ask rather than guess. Some panels let you present uninterrupted; others interrupt from slide two. Some send a brief with numbers, others only the title. The audience might be the CEO and two peers, or a founder and an investor. One email to the recruiter or search consultant settles most of it: who will attend, how long questions run, whether slides are expected, and whether you may speak to anyone beforehand. Ask for those conversations if they are not offered. Two calls with an engineering manager and a product leader give you a diagnosis built on evidence.
Where the material comes from
You will not have their internal data, and the panel knows that. What separates candidates is how honestly they label what they do know. Before you write a slide, sort your material into three piles. The first is what you were told in the loop. The second is what is public: product announcements, job adverts, an engineering blog if there is one, the annual report if the company is listed. The third is what you are inferring. Inference is allowed on the slides, provided it is marked as inference. Job adverts are underrated here: a dozen open roles in one product area and none in another tells you where the company is betting.
A worked outline for twenty minutes
The outline below is for an illustrative company: a business-software scale-up of about 120 engineers that bought a smaller competitor a year ago and now wants to sell to larger enterprise customers. Every fact about it is an assumption for the example, of the kind you would assemble from the loop and public sources.
| # | Slide | Minutes | What it says |
|---|
| 1 | The answer | 1 | In two years: four product groups that each own a customer outcome end to end, one platform group, one stack, and reliability the sales team can sell |
| 2 | Where I think you are | 3 | Three observations, each marked as heard, public or inferred |
| 3 | What the business needs | 2 | The company's own goal restated as engineering requirements |
| 4 | Three choices | 5 | Each choice, what it costs, and the alternative rejected |
| 5 | What we will not do | 2 | Three tempting moves ruled out, with the reason |
| 6 | Sequence | 3 | Three phases, each ending on an outcome rather than an activity |
| 7 | How we will know | 2 | Five measures and what each one guards against |
| 8 | What I would test first | 1 | The two assumptions that would most change the plan if wrong |
That is nineteen minutes, leaving one for a slow start. Rehearse and cut towards seventeen, because a panel that interrupts will take the buffer for you.
Slide 2 carries the most weight. In the example it reads like this. Releases are batched weekly because the two codebases share a release train (heard from two interviewers). Enterprise deals stall on audit logging and single sign-on (public, from the roadmap page and adverts). On-call load falls on a small group who know both stacks (inferred from adverts asking for experience of both platforms). If one is wrong, the panel will say so, and you have been handed free diagnosis in front of the people deciding.
Slide 4 is where most candidates go generic. A choice is only a choice if a reasonable leader might choose otherwise. Here the three are:
- Organise around customer outcomes, not the two legacy products. The cost is a year-one reorganisation that slows delivery for a quarter. The rejected alternative keeps the acquired team intact: kinder now, but it preserves two cultures and two release trains.
- Converge on one stack by migration, not rewrite. The cost is eighteen months of running both. A rewrite would freeze the enterprise features the sales plan depends on.
- Make reliability a product commitment for the enterprise tier. Published service-level objectives, an error budget that can pause feature work for that tier, and a named owner. The cost is feature capacity, and the panel should hear roughly how much and why.
Slide 5 matters more than its two minutes suggest. "We will not adopt microservices as a goal in itself, we will not build our own observability tooling, and we will not plan on doubling headcount" tells the panel you can say no, which is much of the job.
Slide 6 phases the work. Months 0-6 end with one release train and a published reliability target for the enterprise tier. Months 6-12 end with the new group structure in place and the first domain running on the converged stack. Months 12-24 end with the old stack closed to new feature work. Each phase ends on something a person outside engineering could verify.
Slide 7 offers measures that cannot all be gamed at once. Lead time for changes and change failure rate sit together, so speed cannot be bought with breakage. Add enterprise deals blocked on an engineering item, the share of time on unplanned work, and regretted attrition, because a reorganisation that loses the people who know both stacks has failed. Set targets once you have a baseline, not on the slide.
Why a generic future state loses the room
The failure that separates adequate from strong is a destination with no starting point. A deck about platform teams, delivery metrics, AI assistants and a learning culture could be shown to any company, and the panel can tell. It also hides the one thing they want to see: how you reason from their facts.
The opposite failure is false certainty about an organisation you have seen for six hours. Telling the people who built it what is wrong, without sources, previews a leader who will spend the first quarter fixing problems that do not exist. The cure for both is the same. State the diagnosis as a hypothesis with evidence, commit to the choices it implies, and name what would change your mind.
Preparing the questions
The questions are the closest an executive interview panel gets to watching you in a real leadership meeting. Before the day, write down the three questions you least want and answer them on paper. For the example they might be: why a year-one reorganisation will not cost the enterprise launch, what happens to the acquired team's leaders, and where the reliability capacity comes from.
When a challenge lands, separate the fact from the conclusion. If the panel corrects a fact on slide 2, say aloud what it changes downstream: "If releases are already independent, the second choice matters less and I would move that capacity to enterprise features." That is the behaviour being hired. If they challenge a choice without new facts, restate the reason and the condition under which you would drop it, rather than defending the slide.
The executive conversation that often follows is covered in the guide to surviving a multi-stage interview process, and the written form of this executive interview exercise in the take-home assignments and case studies guide.
The panel is not asking what a good engineering organisation looks like. It is asking what you would do with theirs, and how you would find out you were wrong.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).