VP or Director of Engineering interview preparation
Use this guide to prepare for VP or Director of Engineering interviews, with a focus on managing someone out, delivery metrics, delivery predictability. Explain your reasoning and connect it to experience you can substantiate.
These preparation themes come from the questions in this role’s bank. They help you organise your examples; individual employers may assess different things.
Managing someone out
Delivery metrics
Delivery predictability
Underperforming senior
Engineering culture
Team topology
A useful preparation sequence
Choose your experience level and the round you expect.
Answer one question in your own words before opening its guide.
Compare your reasoning, evidence and trade-offs; adapt the answer to your experience.
Practise the follow-up, then revisit one answer you want to improve.
Representative questions and answer guidance
Open any question to read its answer. The complete guidance is included on this page.
Behavioural · Leadership
1. Can you tell me about a time you had to move a manager or senior engineer out of the organisation?
Answer guide
I would choose a case where I can show a fair process. I describe how the gap appeared, what feedback and support I gave first, how I documented it and that I worked with HR so the process was lawful. I explain the decision point and why further coaching was unlikely to help. Then I cover the conversation itself: direct, respectful and with a transition plan for their work and team. I close with the effect on the team, how I communicated without gossip, and what I learned, such as acting sooner and examining my own part.
What this question explores
Whether you can describe a hard people decision with fairness, process and empathy, and reflect honestly on your own role.
Common mistakes
Telling the story as blame of the individual, with no mention of feedback, support or process.
Skipping what happened to the team afterwards and what you would do differently.
Practise a follow-up
How soon after you noticed the problem did you act?
2. Which metrics would you use to measure engineering delivery performance, and what are the risks of using them?
Answer guide
I would use the four widely used delivery measures: deployment frequency, lead time for changes, change failure rate and time to restore service. Together they balance speed and stability. I add outcome measures like customer impact and reliability objectives, since delivery speed alone does not show value. Risks come from misuse: if metrics are used to rank individuals or teams, people game them, for example by splitting changes artificially. Definitions differ across teams, so comparisons need care. I use them for trends within a team and to find constraints, discuss them openly, and never as a performance rating tool.
What this question explores
Whether you know common delivery metrics and understand how to use them for improvement without creating perverse incentives.
Common mistakes
Listing metrics without explaining how they can be gamed or misused to judge individuals.
Measuring only output volume such as lines of code or number of tickets closed.
3. How do you make engineering delivery predictable across several teams without turning planning into bureaucracy?
Answer guide
I separate commitments from forecasts. Teams commit to a small scope each cycle and give ranged forecasts for larger initiatives, based on observed throughput and cycle time rather than gut feel. I keep work items small, limit work in progress, and surface dependencies during planning, not mid-sprint. Leaders review a simple trend of slippage reasons, such as scope change, unplanned work or dependency delays, and we fix the biggest cause first. I share confidence levels with product and reset dates early when risk appears. Predictability comes from honest signals and fast adjustment, not heavier documents or more status meetings.
What this question explores
Whether you understand predictability as a system of honest forecasting and feedback, and can improve it without adding process overhead.
Common mistakes
Promising fixed dates for large initiatives based on optimistic estimates instead of historical throughput.
Adding more status reports and meetings, which consumes capacity without improving the underlying signals.
Practise a follow-up
What metrics would you show the executive team each month?
How do you handle a team that keeps missing its own commitments?
4. A well-liked senior engineer has been underdelivering for two quarters, and his manager hesitates to act. What do you do?
Answer guide
I first meet the manager to understand what evidence exists and why action has stalled, since this may be a coaching need for the manager too. I check that expectations were clearly stated and fed back with examples. If not, we start with a documented improvement plan with specific goals, support and a defined timeline, usually a few weeks to a couple of months. I explore external causes such as role mismatch or personal difficulties, and handle them with care. If there is no progress after genuine support, we follow the HR process toward a role change or exit, keeping dignity and fairness for everyone.
What this question explores
Whether you handle underperformance fairly and decisively, including the manager who avoids the conversation.
Common mistakes
Letting popularity delay action, which signals to the team that standards do not apply to everyone.
Moving straight to exit without clear expectations, documented feedback or a real chance to improve.
Practise a follow-up
What if the engineer's performance dropped because of personal issues?
How do you coach the manager to have this conversation?
5. How do you shape and measure engineering culture without relying on slogans or posters?
Answer guide
Culture is what gets rewarded and tolerated, so I begin with the behaviours I want, such as ownership, candid code review and learning from failure, and reinforce them through hiring, promotion criteria and how I react to incidents. I model them myself, for instance by owning my mistakes openly. For measurement I use a few signals: engagement survey themes, review turnaround and tone, post-mortem participation, how often people raise concerns, and retention of strong performers. None is perfect, so I combine them with conversations. When I see a gap, I address it with specific practices, not a general campaign.
What this question explores
Whether you see culture as observable behaviour shaped by incentives and leadership example, and can measure it sensibly.
Common mistakes
Defining values on slides while promotions and rewards favour different behaviour.
Relying on one survey score as proof of a healthy culture.
Practise a follow-up
What would you do if a high performer behaves badly toward colleagues?
How do you change culture in a team you have just inherited?
6. How would you decide between feature teams, platform teams and component teams as the organisation grows?
Answer guide
I start from the flow of value. Feature teams owning a customer outcome end to end should be the default, because handoffs are what slow delivery. I add a platform team only when several feature teams keep rebuilding the same capability, and I run it like a product with internal customers, a roadmap and adoption measures. I avoid component teams, since they create queues and weak ownership, except for genuinely specialised areas. Team size should allow shared context, and cognitive load matters: if a team cannot reason about everything it owns, I split the domain. I revisit the topology whenever delivery friction shows up.
What this question explores
Whether you can reason about organisation design from flow of work and ownership, rather than copying a popular model.
Common mistakes
Creating a platform team too early, before there is repeated demand, which builds unused shared tooling.
Organising by technical layer, which forces every feature through several teams and slows delivery.
Practise a follow-up
How would you know the topology is wrong?
How do you keep a platform team from becoming a bottleneck?
7. How do you coach and evaluate engineering managers who report to you, as opposed to individual engineers?
Answer guide
Their output is the team's outcomes, so I look at delivery health, retention, quality of hiring and how well their people grow, not at their personal technical contribution. In one on ones I ask about their team's biggest risks, how they handle feedback and whether they are building successors. I use skip levels and survey signals to cross-check what I hear. I coach on delegation, because new managers tend to stay too hands-on. I give direct feedback on judgement calls, and I am willing to move someone back to an individual role if the fit is poor.
What this question explores
Whether you understand that managing managers means judging leverage and team health, not personal output, and can coach accordingly.
Common mistakes
Evaluating a manager mostly on their own technical contribution instead of what their team achieves.
Skipping skip level conversations and relying only on what the manager reports upward.
Practise a follow-up
How often do you hold skip levels and what do you ask?
How do you help a manager who is still doing most of the coding?
8. How do you set and protect a consistent hiring bar as you scale hiring across many teams?
Answer guide
I define the bar through role scorecards listing specific competencies, with examples of what meets and exceeds expectations. Interviewers are trained, calibrated and shadow before they score alone. Each interviewer writes feedback independently before the debrief, so one loud opinion does not sway the group. For key roles I use a senior calibrator from outside the hiring team. I track offer acceptance, ramp-up time and early performance by interviewer, and compare them with the ratings given, so drift becomes visible. Pressure to fill seats is real, so I tell leaders plainly that a mis-hire costs more than a vacant seat.
What this question explores
Whether you can run hiring as a calibrated, measurable process that resists schedule pressure rather than relying on individual instinct.
Common mistakes
Letting each hiring manager define the bar informally, which produces inconsistent decisions across teams.
Lowering standards quietly when a role stays open for long and leaders push for closure.
Practise a follow-up
How do you handle an interviewer who is consistently too lenient or too harsh?
How would you measure whether the hiring process works?
9. How would you design and roll out an engineering career ladder that people trust?
Answer guide
I begin with the levels the business needs and describe each by scope, impact, autonomy and influence, not years of experience or technology lists. Managers and senior engineers co-write it so it reflects real work, and I include a parallel individual contributor track so promotion does not require managing people. Expectations are written as observable behaviours with examples. Promotions go through a committee for consistency, using evidence gathered over time, and people not promoted receive written feedback. I run calibration each cycle, check outcomes across groups for bias, and publish the process so nobody has to guess how decisions are made.
What this question explores
Whether you can build a fair, transparent growth framework that supports both management and individual contributor paths.
Common mistakes
Defining levels by years of experience or tool knowledge instead of scope and impact.
Rolling out the ladder without a calibration process, so promotions feel arbitrary and political.
Practise a follow-up
How do you stop title inflation over time?
How would you map existing engineers to the new levels?
10. How do you plan engineering budget and headcount for the next year when product priorities are still shifting?
Answer guide
I anchor on the company's top outcomes and translate them into capacity by team, not a wish list of heads. I build a baseline of run costs such as salaries, cloud, licences and vendor spend, then model scenarios, typically lean, expected and stretch, each with clear trade-offs. I include hiring lead time and ramp-up, since a hire in the third quarter rarely delivers much that year. I keep a small reserve for unplanned work and attrition backfill. I agree triggers with finance that release or freeze funds, and review quarterly so the plan adapts without relitigating everything.
What this question explores
Whether you can connect engineering spend to business outcomes and plan under uncertainty using scenarios rather than a single number.
Common mistakes
Requesting headcount without linking it to outcomes, which finance reads as an unsupported wish list.
Ignoring hiring lead time and ramp-up, so planned capacity arrives too late to matter.
Practise a follow-up
How do you justify cloud spend growth to finance?
What do you do if approved headcount is cut mid-year?
11. Attrition in your engineering organisation has risen over two quarters. How do you find the cause and respond?
Answer guide
I first separate the numbers: regretted versus non-regretted exits, by team, manager, tenure and level. Patterns point to causes, such as one weak manager, a pay gap for a skill, stalled growth or heavy on-call load. I read exit interview themes, not only survey scores, and talk to people who stayed. Then I act on the largest driver with specific fixes, for example manager coaching, a pay correction, clearer promotion paths or workload relief. I tell the organisation what I heard and what I am changing, because silence reads as indifference. I track leading indicators monthly, not just exits.
What this question explores
Whether you diagnose attrition with data and conversations before acting, and close the loop with the people who remain.
Common mistakes
Treating attrition as one number and launching company-wide perks instead of finding the specific cause.
Relying only on exit interviews, where leavers often give polite reasons rather than the real ones.
Practise a follow-up
How do you tell regretted from non-regretted attrition?
What would you do if the main cause is compensation and budget is tight?
12. How do you negotiate the roadmap with product when engineering capacity cannot cover everything product wants?
Answer guide
I make the trade-offs visible. I bring capacity numbers per team, the cost of each initiative as a range, and what is displaced if something is added. Then we rank by outcome and risk together, not engineering versus product. I reserve an agreed share of capacity for reliability, security and debt, so it is not renegotiated every quarter. When product pushes a date, I offer options: reduce scope, change sequencing, or accept more risk with named consequences. I keep the conversation on customer and business results, and escalate jointly with my product counterpart only for conflicts we cannot resolve.
What this question explores
Whether you can negotiate priorities with product using shared data and options rather than saying no or silently overcommitting.
Common mistakes
Saying yes to everything and letting teams absorb the overload through overtime and cut corners.
Framing the discussion as engineering against product instead of a joint ranking by outcomes.
Practise a follow-up
How do you protect capacity for non-feature work?
What do you do when product and engineering disagree after the data is shared?
Choose one answer containing an example or practical sequence. Explain what you would actually do, what you would check and when you would ask for help. Keep claims about your experience honest.
For technical or regulated work, check current documentation and applicable local requirements alongside this practice material.