In this article
Scope and the role
What does a director of engineering do?
A director of engineering sets direction for a group of teams, builds the managers who lead them, and answers for delivery, quality and cost. The U.S. Bureau of Labor Statistics (BLS) says computer and information systems managers plan, coordinate and direct computer-related activities, typically need five years or more in a related occupation, and projects 16 percent growth from 2025 to 2035 (BLS, last modified August 2026). An engineer owns code, a manager owns a team, and a director owns managers and their teams.
Why it is asked: it checks that you understand the job is no longer your own output. Read the full explanation: the leadership interview guide.
What is the difference between managing managers and managing individual contributors?
An individual contributor is an engineer who builds without managing people, and a manager of managers is a leader whose direct reports are themselves managers. With contributors you can see the work and fix it directly. With managers you see it through their teams, so you work by setting context, coaching and checking outcomes rather than approving details. A director works mainly by setting context and coaching managers. The main risk is stepping in to do a manager's job and teaching them to wait for you.
Why it is asked: it is the central test of director scope.
Text description of the diagram
- An engineer owns code, a manager owns a team, and a director owns managers and their teams.
- A director works mainly by setting context and coaching managers.
What is the largest team or organisation you have managed?
Answer with the real figures and what they meant: how many people, how many teams and managers, the budget you owned if any, and what the organisation delivered under you. Then describe how the scale changed your habits. Do not stretch the number. Interviewers check it, and a smaller honest scope with a clear story beats an inflated one that falls apart in follow-up.
Why it is asked: it calibrates the level, and then the questions get harder from there.
How do you decide where to spend your influence?
Spend it where the organisation has the greatest effect and the lowest chance of fixing itself: a decision that blocks several teams, a manager who needs coaching, or a cross-team conflict. Say what you deliberately leave alone, because trusting managers to decide is part of the answer. Give an example of something you let go and what happened.
Why it is asked: a director's time is the scarcest resource, and the answer shows your filter. Read the full explanation: driving a big cross-team change.
How do you scale technical excellence across an organisation of 100 or more engineers?
You cannot review everything, so you set standards and let the system carry them. Agree a short list of engineering practices, such as review expectations, testing and on-call readiness, give each a named owner among your managers and senior engineers, and publish examples of good work. Check adoption through the delivery measures you already track. Say which standards you made mandatory and which you left to teams.
Why it is asked: it shows whether your impact comes from mechanisms rather than your own attention.
How do you fix systemic problems instead of individual ones?
When the same failure appears in several teams, look for the shared cause before blaming a person: unclear ownership, a missing tool, a conflicting incentive or an overloaded interface. Fix that cause once, then check whether the pattern stops. Give an example where you first suspected a person and found a process problem, and what changed after the fix.
Why it is asked: a director who treats every issue as a people problem cannot scale.
Organisation design
How do you design an engineering organisation?
Start from the product and system boundaries and draw team boundaries to match, because the two tend to copy each other. Melvin Conway's 1968 paper states that organisations which design systems are constrained to produce designs that copy their communication structures (Conway, 1968), which is called Conway's law. A group of 6 people has 15 pairwise channels, 8 has 28 and 12 has 66, so small teams with clear interfaces keep communication manageable.1
Why it is asked: it tests whether you design for outcomes, not for an org chart.
When do you reorganise, and how do you run one?
Reorganise when the current structure causes a repeated, named problem such as slow cross-team work or unclear ownership, not because a new leader wants a new chart. Decide the goal, test options against real work, tell people early and plainly why, keep the number of simultaneous changes small, and check afterwards whether the problem improved. Say honestly that every reorganisation costs a few months of focus.
Why it is asked: it shows judgement about a high-cost move.
How do you handle two teams that depend on each other?
Make the dependency explicit: name an owner for the shared interface, agree what each team delivers and when, and put the shared work on one visible plan. If the teams keep colliding, treat the structure as the problem and consider merging them or moving the boundary. Escalate early with data rather than waiting for the deadline to expose it.
Why it is asked: dependencies are the main source of delay at director scale.
How do you decide what to build, buy or outsource?
Build what differentiates the product or is cheaper to own over its life, buy what is a commodity, and outsource only what you can specify and verify. Compare total cost over several years, not only the first quarter, and include integration, maintenance and the cost of switching later. State who owns the decision and when you will revisit it.
Why it is asked: it tests commercial judgement as well as engineering judgement.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Delivery and reliability
How do you measure engineering performance?
Measure the delivery system, not individuals. DevOps Research and Assessment (DORA), the research programme behind the DevOps metrics, lists five: change lead time, deployment frequency and failed deployment recovery time as throughput, and change fail rate and deployment rework rate as instability (DORA, updated January 2026). Use them per application or service, compare a team only with its own past, read them together, and pair them with outcome measures such as customer impact. Never rank people by them.
Why it is asked: it separates leaders who measure for learning from those who measure for control. Read the full explanation: team health as an engineering manager question.
How do you balance reliability against shipping features?
Agree a reliability target with product and use it as a budget. An error budget is the amount of unreliability a service is allowed within a quarter. Google's site reliability engineering (SRE) book calls it a clear, objective metric, and says it gives product and reliability teams a common incentive to find the right balance (Google SRE book, 2017). A 99.9% target over 90 days allows about 129.6 minutes of downtime; 99.99% allows about 13.1 When the budget is spent, reliability work comes first.
Why it is asked: it tests whether you settle the argument with a rule instead of a veto. Read the full explanation: the site reliability engineering guide.
How do you decide between technical debt and new features?
Treat debt as a cost with a measurable effect: slower delivery, more incidents or higher risk. Rank each debt item by what it costs the roadmap, fund the ones that block planned work, and reserve a steady share of capacity so debt does not become a crisis. Say how you explain the trade to product in their terms, such as delay and risk.
Why it is asked: it is the standing tension in every engineering organisation. Read the full explanation: technical debt versus features.
What do you do when a major incident hits your organisation?
First make sure someone is clearly in charge of the response, and that customers and executives get regular, plain updates from one voice. Support the responders and stay out of their way. Afterwards hold a blameless review focused on how the system allowed the failure, and track the follow-up actions to completion. The director's job is the process and the communication, not debugging.
Why it is asked: incidents show how you behave under pressure and how you treat people.
People and managers
How do you coach a manager who reports to you?
Coach on the manager's own skills: how they run one-to-ones, give feedback, set goals and handle conflict. Google's Project Oxygen study, based on over 10,000 data points, found that teams with highly effective managers were more likely to get better results, be happier and have lower turnover, and "be a good coach" heads its list of ten behaviors (Google re:Work, August 2025). Hold regular one-to-ones with each manager, and ask questions before giving answers.
Why it is asked: coaching managers is how a director multiplies impact. Read the full explanation: one-to-ones and hard feedback.
What do you do when one of your managers is struggling?
Find out whether the cause is skill, context or fit. Give specific, written feedback with examples, set a short plan with clear expectations, and offer coaching or a peer mentor. Look at the team's own signals, such as attrition and delivery, rather than relying on impressions. If it does not improve, move them to another role or out, with care and human resources (HR) guidance.
Why it is asked: it tests whether you act early and fairly on a hard people problem. Read the full explanation: handling a low performer.
How do you run skip-level meetings?
A skip-level meeting is a conversation between a leader and the people who report to their direct reports. Hold them on a regular rhythm with everyone, not only when something is wrong, and say up front that they are for listening and not for going around the manager. Ask about priorities, obstacles and what they would change. Share patterns with the manager and never repeat who said what.
Why it is asked: skip-levels reveal what managers may not see, and misuse destroys trust fast.
What do you do if your report's report is struggling?
Go to your direct report first. Ask what they already see and what they have tried, and offer help instead of taking over. If the problem is performance, the manager owns the plan and you check that it is specific and timely. Step in directly only for safety, legal or fairness issues. Say how you would avoid undermining the manager in the person's eyes.
Why it is asked: it tests whether you coach through the chain or bypass it.
How do your one-to-ones differ with managers and with individual contributors?
With an individual contributor, one-to-ones centre on their work, growth and blockers. With a manager they centre on the manager's own craft: how their team is doing, how they handle hard conversations, where they need your support and what they are learning. Spend less time on task status and more on judgement and decisions. Keep the slot fixed and let the manager set the agenda.
Why it is asked: it separates leaders who changed how they work from those who kept doing the old job.
How do you set the hiring bar across teams?
A structured interview is an interview that asks every candidate the same job-related questions and scores them against the same written scale. The U.S. Office of Personnel Management (OPM) calls the structured interview "among the most valid assessment tools available" and says that, designed and used properly, it has relatively low adverse impact (OPM FAQ, read October 2026). Train interviewers, calibrate on sample answers and review decisions for consistency.
Why it is asked: hiring quality compounds across the organisation. Read the full explanation: how interview loops stage senior rounds.
How do you retain strong senior engineers?
Give them problems that matter, real influence over technical direction, a visible growth path that does not require managing people, and fair pay. Ask what would make them leave before they say it, and fix the systemic causes such as unclear priorities or constant firefighting. Retention is mostly the day-to-day experience, not retention bonuses.
Why it is asked: losing senior engineers is expensive and often avoidable.
How do you handle a cut in headcount or budget?
Be honest and early with managers, decide the criteria before choosing the outcomes, and tie the choices to the strategy, not to who complains loudest. Protect the work that matters most and say clearly what will stop. Follow your company's legal and human-resources process exactly, and support the people who stay as well as those who leave.
Why it is asked: it tests values and judgement when there is no good option.
Strategy and stakeholders
How do you connect engineering work to business strategy?
Translate company goals into a small number of engineering outcomes, then show each team how its work contributes. Review the plan against the strategy on a fixed rhythm and drop work that no longer fits. In the interview, give one example of a technical bet you justified in business terms and what it returned.
Why it is asked: directors are judged on outcomes the business can see. Read the full explanation: building a roadmap and prioritising.
How do you say no to a senior stakeholder?
Say yes to the goal and no to the plan, and show the trade. Lay out what the request would cost in capacity and what would have to wait, offer alternatives that meet the underlying need, and let them choose with the facts. Stay calm and consistent, and keep your word once a decision is made.
Why it is asked: it tests influence without authority. Read the full explanation: stakeholder management for engineering managers and influence without authority.
How do you plan budget and headcount?
Start from the outcomes you owe, estimate the people and tooling they need, and show the cost of each option and what you would drop if funding is lower. Keep a small buffer for attrition and surprises, and review spend against plan monthly. Use real figures from your own experience in the interview, not rules of thumb.
Why it is asked: ownership of money is a defining part of the director role.
How do you communicate with the executive team?
Lead with the outcome and the decision you need, then give the two or three facts that support it. Report risks early with options, and use the same simple measures every time so trends are visible. Keep status in terms of customer and business impact, and put detail in a linked document for those who want it.
Why it is asked: executives promote leaders whose updates they can trust and act on.
Follow-up questions
What questions should I ask during a director of engineering interview?
Ask what the first six months should deliver, how the organisation is structured today and why, how engineering and product decide priorities, and how the company measures success for this role. The questions to ask the interviewer page covers the general version.
How do you coach a new manager who still codes too much?
Agree what the manager's work is now: the team's outcomes, not their own commits. Move their coding off the critical path, pair them with someone who can take their tasks, and praise the team results they produce. Review it in each one-to-one until the habit changes.
What do you inspect weekly and what never?
Weekly: delivery against commitments, incidents and follow-ups, attrition risk and whether managers hold their one-to-ones. Never: individual code, daily task lists or how an engineer spends their hours, because those belong to the manager.
- A director works through managers: set context, coach and check outcomes instead of fixing details.
- Draw team boundaries to match system boundaries, because the systems an organisation builds tend to copy its communication structure.
- Measure delivery per application or service, against a team's own past, with the five DORA metrics, and settle reliability trade-offs with an error budget.
- Coach managers, set the hiring bar with structured interviews and report to executives in business outcomes.
- Give real figures for scope, and never inflate them.
Sources
- Computer and Information Systems Managers, Occupational Outlook Handbook — U.S. Bureau of Labor Statistics, 27 Aug 2026
- DORA's software delivery performance metrics — DORA (Google Cloud), 5 Jan 2026
- Following the data: the research behind great managers — Google re:Work, 1 Aug 2025
- Embracing Risk, Site Reliability Engineering — Google (O'Reilly Media), 1 Jan 2017
- How Do Committees Invent? — Datamation (Melvin E. Conway), 1 Apr 1968
- Should agencies use structured interviews in the employee selection process? — U.S. Office of Personnel Management, 24 Oct 2026
