Questions to Ask a Director of Engineering
Questions to ask a director of engineering, whether they are interviewing you, you have a skip-level with them on the calendar, or you sit on a panel hiring for the job. The 59 questions cover the organisation and its priorities, how work is decided and shipped, on-call and technical debt, promotions and attrition, and how the director leads. One group is for candidates asking about the role itself, and the last is for your own engineering director.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The org
What are engineering's top priorities for the next twelve months?
Why ask it
Two or three outcomes, such as a migration finished or a product line launched, mean the argument about what to drop has already been had. A list of eight means that argument has been handed down to the teams, who will have it sprint by sprint.
What is the biggest challenge the engineering team is facing right now?
Why ask it
Whatever they name first is where the director's own attention is going, and probably where a new hire's will too. Follow up with what has been tried so far. A challenge with two failed attempts behind it is harder, and more honestly described, than one nobody has touched.
How would you describe the engineering culture to someone who has never worked here?
Why ask it
Adjectives are cheap, so wait for the habit behind each one. Ownership should come with who gets paged, and moving fast with what shipped last month and what it broke. If only adjectives arrive, pick one and ask for the most recent example of it.
How do you measure whether the engineering organisation is doing well?
Why ask it
The metrics they reach for say what they optimise. Delivery counts, incident rates, retention and internal survey scores each pull behaviour in a different direction, and an answer built only on velocity is a warning about how teams will be pressured.
How many engineers report up to you, and how many layers are between you and them?
Why ask it
The number sets the scale of everything else you hear. With thirty engineers a director probably knows each one by name. With three hundred, everything reaches them through managers, and what they say about culture is second-hand.
How are the teams divided up: by product area, by layer of the stack, or some other way?
Why ask it
The shape decides who you wait on. Teams split by layer pass every feature across a queue, while product-area teams ship alone but tend to solve the same problem three times. Either is workable if the director can say which cost they chose.
Who do you report to, and who speaks for engineering when dates are promised?
Why ask it
A director under a chief technology officer has a technical advocate above them. One who reports to a product or business executive may be the most senior engineer in the room, or may not be in the room at all. Where nobody from engineering is present, deadlines tend to arrive already set.
What has changed in how engineering is organised over the last year?
Why ask it
A reorganisation changes who owns what, and teams lose time relearning it. Ask what problem the latest one was meant to solve and whether it did. A second one inside the same year, undoing the first, deserves a question about who has been choosing the shape.
Is the engineering organisation growing, holding steady or shrinking this year?
Why ask it
Headcount is the most concrete plan a company has. Fast growth puts a large share of your first year into interviewing and onboarding, and a freeze means the team you meet is the team you get. Check whether the number is approved budget or a hope.
What will engineering need to be able to do in three years that it cannot do today?
Why ask it
This is the vision question with the slogans taken out. Someone thinking past the current roadmap names a capability: releasing every day, running in a second region, carrying ten times the traffic. Then ask which part has been started, because that separates a plan from a wish.
Delivery
How does work reach the teams, and who decides what gets built?
Why ask it
Work can arrive as a product roadmap, as tickets from sales and support, or as proposals from the engineers themselves, and most organisations run on a blend. Ask for the rough share of each. Where almost nothing on the list began with an engineer, expect to be handed specifications more often than problems.
How far ahead is the roadmap planned, and how often does it change mid-quarter?
Why ask it
A roadmap rewritten every few weeks is really a list of current requests. Find out who asked for the most recent change and how much warning the teams had. If new work went in and nothing came out, the plan is being met with overtime.
How long does a change take to go from an engineer's laptop to production?
Why ask it
One of the few answers in an engineering conversation that is hard to spin. Minutes, days, and a monthly release window are three different working lives, and the reason it is slow tells you what has been tolerated.
How are deadlines set, and what happens when a team says a date cannot be met?
Why ask it
The director's level is where a team's estimate meets a commitment someone has already made to sales or the board. A good answer describes a negotiation and gives a recent example. A poor one describes engineers being asked to try harder, which means the estimate was never an input.
How is engineering time split between new work, maintenance, and unplanned interruptions?
Why ask it
Rough percentages are enough, and they beat a philosophy. If nobody has measured it, nobody can say why the roadmap slips, and the missing time is often in the third bucket: support requests, incidents and favours for other teams.
How do you handle technical debt, and where does the time for it come from?
Why ask it
Look for a mechanism: a standing share of each sprint, a reserved week each quarter, a backlog with an owner. If it depends on engineers making the case one item at a time, it mostly waits until something breaks.
What is in the tech stack today, and which part of it would you replace if you had the time?
Why ask it
The list itself tells you what you would be learning. The follow-up finds the system everyone avoids, and a director close to the work names it without a pause: the billing service, the deploy scripts, the oldest corner of the monolith. A new hire often starts right there.
Who makes the big technical calls: you, the staff engineers or the teams themselves?
Why ask it
Written proposals reviewed by peers, an architecture group and plain service ownership can all work. The telling detail is whether a team's decision has ever been overruled from above, and how that was explained to the people who made it.
How do you keep quality up: code review, automated tests, a QA team, or some mix?
Why ask it
The mix shows who is trusted with what. Where a separate group signs off each release, find out how many days that adds. Where tests are the only gate, the follow-up is how often a bad change reaches customers and who hears about it first.
What is on-call like, and when did you last carry it yourself?
Why ask it
The figure to get is how many nights someone was woken during the last rotation. If the director cannot guess it, the pager load is not being watched from above and tends to stay as it is. Whether on-call is paid or given back as time off differs by employer and country, so ask how it works there.
What happened after your last serious outage?
Why ask it
You are listening for whether the review produced changes anyone can name, and whether one person took the blame. If no outage comes to mind at all, ask how they would find out about one, since that can mean a very stable system or thin monitoring.
Where do AI coding assistants fit into the way your teams work?
Why ask it
Some organisations buy a tool for every engineer, some forbid sending code to an outside service, and many have written nothing down, so the reply is specific to this employer. Listen for whether the director now expects more output as a result, and who is accountable for code that no person wrote line by line.
People
What does the career path look like for an engineer who does not want to manage?
Why ask it
A working technical track has titles above senior, people holding them now, and pay that keeps pace with the management line. If every staff engineer is a founder's early hire or a former manager, the track exists mostly on paper.
How do promotions work here, and how many people were promoted last cycle?
Why ask it
A named process plus a number is a working system. A described philosophy with no recent examples means promotion depends on your manager's ability to campaign, which is worth knowing before you join.
How is an engineer's performance judged, and who has a say besides their manager?
Why ask it
One manager's opinion and a view compared across teams produce very different outcomes for the same work. It also helps to hear what counts besides shipped features, since mentoring, incident response and careful reviews go unrewarded wherever nobody records them.
How do you handle a manager who is not performing?
Why ask it
Managing the managers is the part of the job nobody else can do for a director. Ask what happened the last time and how long it took. Coaching, a move back to engineering and a departure are all fair endings. A year of everyone knowing and nothing changing is the answer to worry about, because the engineers under that manager were waiting too.
What do you look for when you move an engineer into management?
Why ask it
The strongest coder on a team and the one who already unblocks everybody else are rarely the same pick. Two follow-ups matter: whether new managers get any training, and whether someone who dislikes the job can go back to engineering without it reading as a demotion.
What is attrition like, and where did the people who left go?
Why ask it
Both halves matter. People leaving for bigger jobs elsewhere and people leaving for the same job at a competitor mean different things. If the destinations are a blank, either nobody held the exit conversations or nobody passed them up.
How much of the hiring do you do yourself?
Why ask it
Directors who still interview know what the market looks like and what their bar actually is. Full delegation is defensible at scale, but it means their descriptions of team quality are inherited from other people.
How do engineers here keep learning: a training budget, time set aside, moves between teams?
Why ask it
A director controls the two things that make learning possible: money and slack in the schedule. The money is the easy half. Whether anyone moved teams last year, or was given real time to pick up an unfamiliar system, shows if the schedule has room too.
How often do your teams work evenings or weekends, and what usually causes it?
Why ask it
The cause matters more than the count. A launch week twice a year is something a team can plan around, while evenings that come from dates promised without an estimate will be back next quarter. Expectations and overtime rules differ by employer and country, so ask what is normal there and whether the time is given back.
How does the organisation work across offices, time zones and remote engineers?
Why ask it
Decisions tend to get made wherever the director sits. If you would be somewhere else, two facts are worth having: who at your location was last promoted, and whether design discussions leave a written record that someone in another time zone can read the next morning. Office-day rules vary by employer and change, so get the current one.
What separates the engineers who thrive in your organisation from the ones who struggle?
Why ask it
The traits a director lists are the ones that get noticed at promotion time, written down or not. Comfort with vague requirements points to little direction from above, and strong writing points to work that spans teams and time zones. Decide whether the person being described sounds like you.
Leadership
How would you describe your leadership style, and what would your managers say about it?
Why ask it
The self-portrait will be flattering, which is why the question has a second part. Being able to quote a criticism from their own managers, and to say what changed because of it, shows they have asked for feedback and done something with it.
Why did you join, and what has kept you here?
Why ask it
The two halves can have different answers. The reason for joining is often the pitch you are hearing now, and the reason for staying is the part that turned out to be true. A recent, specific reason, a system rebuilt this year or a team they are proud of, counts for more than loyalty to the mission.
What are you personally spending your time on this quarter?
Why ask it
Compare the answer with the priorities they gave you earlier. A quarter spent on hiring, or on one struggling team, is a different job from one spent on architecture or planning, and a mismatch tells you which list is the real one.
How do you keep enough technical context to be useful, and where do you rely on others?
Why ask it
Both extremes cause problems. Directors who still want to make technical decisions block their staff engineers; directors with no context cannot tell when an estimate is nonsense. Listen for how they describe the boundary they have drawn.
What do you do when a senior engineer and a product manager cannot agree?
Why ask it
A real case is worth more than the policy here. Whether they decided it themselves, sent it upward or left the two to sort it out tells you how much backing the engineers under them can count on.
How do you find out what is really going on inside the teams?
Why ask it
Every layer of management rounds a problem down a little before passing it up. A director with a real answer names a routine: reading incident reviews, joining a team's planning now and then, time with engineers and no manager present. Saying that anyone can come and talk to them describes a hope, since few engineers will.
What would you change about how engineering works here if it were entirely your call?
Why ask it
The answer shows where the director's authority stops. Something specific that they are blocked on, a release process owned by another group or a planning cycle set by finance, is unlikely to change soon however much they agree with you. Nothing at all, from someone a year into the job, means you are still in the sales conversation.
What decision here did you get wrong?
Why ask it
Look for a real cost and a real correction: a platform investment abandoned, a reorganisation reversed, a hire kept too long. An answer about learning to communicate more is a non-answer.
What will your own boss judge you on this year?
Why ask it
The answer is often narrower than the priorities they opened with: one launch date, a cost figure, a hiring number. Whatever it is, expect it to win when it collides with anything else on the list, including the project you would be joining.
What did you find here that you did not expect when you accepted the job?
Why ask it
Unless they were promoted from inside, the director was a candidate here once and can say how the pitch compared with what they found. The gap they describe, an older codebase, less budget, a narrower mandate, is one to allow for in your own first months.
The role
Why are you hiring for this position now?
Why ask it
From a director you get the budget-level reason, which a recruiter may not know: a team being built, a project running late, or a departure. Each one sets up a different first month. After a departure, the detail to get is whether the work was kept moving or has been waiting for you.
What would you want me to have delivered by the end of my first ninety days?
Why ask it
Directors approve headcount against a need, so a concrete answer should exist: a service taken over, a migration finished, an on-call rotation joined. If the whole reply is to learn the codebase, onboarding has probably been left to chance.
Which team would I join, and how is it doing compared with your others?
Why ask it
Few directors will rank their teams out loud, so the wording carries the answer. Listen for words like steady, newly formed or in transition, and for how long the current manager has been in place. Frequent changes of manager on one team deserve a follow-up of their own.
How often would you and I talk once I had started?
Why ask it
At this level the honest answer may be a skip-level each quarter and the all-hands. That is normal, and it means the manager between you matters more than this conversation does. Try to meet that manager before accepting.
What does a senior engineer do here that a mid-level engineer does not?
Why ask it
Levels mean different things at every company, so the title on an offer says little by itself. A description in terms of scope, such as owning a service or leading a project across teams, suggests a ladder managers apply consistently. Years of experience as the only difference suggests they do not.
Is there anything in my background that makes you hesitate about me for this role?
Why ask it
Save it for the end of the interview. By then the director has formed a view and will often simply say it: too little experience at this scale, no time spent on call, a short stay somewhere. Give the one fact that answers the doubt, briefly, and thank them for being direct.
What happens after this conversation, and when should I expect to hear?
Why ask it
The process differs by company: the director may be the final interview, or another panel and a sign-off from above may follow. Get a date, and ask who to write to if it passes. If you want the job, this is also the moment to say so plainly.
Your own director
What do you wish engineers told you sooner?
Why ask it
Slipping dates, a design nobody believes in, a colleague about to quit: whatever is named, you now have explicit permission to bring exactly that, which is worth more than a general invitation to speak up.
If my team could finish only one thing this half, which would you choose?
Why ask it
Teams tend to assume leadership is watching the work that feels largest from the inside. A director's pick is often a smaller item that another group is blocked on. Ask what makes it the one, and whether your manager would give the same reply.
How does my team look from where you sit?
Why ask it
From two levels up, a team is mostly its dates, its incidents and what other teams say about it. Ask what yours is known for and what it is not yet trusted with. If the picture is out of date, the remedy may simply be reporting your own work better, and you can offer to help with that.
Where do you see the gap between the work I do now and the next level?
Why ask it
Your manager writes the promotion case, but at many companies the director is present when it is decided, so find out how it works at yours. Then take what you hear back to your manager, so that both of them end up describing the same gap.
What does the rest of the company complain about when engineering comes up?
Why ask it
Directors sit in rooms engineers never see, where sales wants dates, support wants fixes and finance wants the cloud bill explained. Once you know the complaint, you can explain your own work by what it does about it.
In the last big decision, what was the trade-off that did not make it into the announcement?
Why ask it
Choose one real decision, a reorganisation, a cancelled project or a moved deadline, and ask about that alone. You are not after secrets, only the trade-off that was weighed. Hearing it usually makes the decision easier to explain to your own team.
Which technical problem cuts across teams and keeps getting put off?
Why ask it
Shared build tooling, a flaky test suite, three versions of the same login library: these sit between teams and belong to none. Offering to take one is how many engineers first do work that is seen beyond their own team. Agree what finished means before saying yes, because such problems have no natural end.
What are you worried about that the teams are not?
Why ask it
Budget, hiring plans and customer contracts reach a director months before they reach anyone else. Details may be off limits, but even the category, cost, a competitor, a key person leaving, tells you which of today's priorities could move.
How did you get from writing code to running an engineering organisation?
Why ask it
Worth asking if you are weighing management yourself. Listen for how they describe the step from managing engineers to managing managers, when reading the code stops being a way to know how things stand. Then ask whether they miss building, and what they would tell an engineer who is unsure about making the same move.
Talking to an engineering director
Practical guidance for the conversation itself
If you are the candidate
Spend your questions on mechanisms, not values
Almost any engineering leader will say they value quality, autonomy and growth. Ask where the time for technical debt comes from, how promotions were decided last cycle, and how long a change takes to reach production, since those answers cannot be given aspirationally.
Check their answers against an engineer on the team
Ask to speak to someone two levels down and put two of the same questions to them: on-call load and how work arrives. Where the two accounts differ, the engineer's is the one you would be living with.
Ask about the last time, not the policy
"How do you handle X?" invites the intended process. "What happened the last time X came up?" gets you what actually occurs, and the difference between the two answers is the useful part.
If you are hiring for the role
Turn the list on the organisation they last ran
Most of the questions under The org, Delivery and People work on a candidate for the job if you point them backwards: where the time for debt came from there, what the last outage changed, where the people who left went. The Leadership group can be asked as written.
Make them do arithmetic out loud
Ask for headcount, attrition, promotion counts and time to production as numbers. Candidates who have run an organisation carry these; candidates who have narrated one do not.
Ask how they manage managers
The distinguishing skill at this level is managing managers, not engineers. Ask how they coached a struggling manager, how long they gave it, and what they did when it did not improve.
Test the technical boundary deliberately
Give them a scenario where a staff engineer wants to rewrite a system and the roadmap cannot absorb it. You are looking for someone who neither overrules on instinct nor abdicates the decision.
If the director is already yours
Bring two questions, not ten
A skip-level is often half an hour, and the director will have questions of their own. Pick one from the Your own director group and one about the organisation, and let the follow-ups use the rest of the time.
Tell your manager what you plan to raise
A director who hears a concern will often take it to your manager soon afterwards. If your manager is hearing it for the first time, the meeting has cost you something. Say beforehand what you intend to ask, and afterwards what you heard.
Ask for their view, not a ruling
"Which piece of our work would you finish first?" gets you information. "Can you tell the other team to prioritise our request?" asks the director to go around two managers, and most will decline. Use the meeting to understand how they see things and act on it through the usual route.
Answers to treat as warnings
- No number available for attrition, promotions, or how long a change takes to reach production.
- Technical debt handled entirely by engineers persuading their manager case by case.
- A recent outage with no changes anyone can name, or one attributed to a single person.
- Two or more reorganisations in a year, each described as fixing the last.
- Nothing they would change about the organisation, from someone who has been there over a year.
- Success measured only by delivery volume or velocity.
- A promotion philosophy with no examples from the last two cycles.
- A technical career track with nobody on it above senior.
- Dates promised to customers before any engineer was asked for an estimate.
- Regular evening and weekend work that nobody can trace to a cause.