Questions to Ask an Engineering Manager in an Interview

The best questions to ask an engineering manager are about how the team works week to week: how on-call runs, how long code waits for review, when tech debt actually gets paid down, who sets priorities, what your 1:1s look like and how promotions happen. Ask for recent, specific examples instead of opinions (“Who was promoted most recently, and what did their case look like?”), and judge each answer by its detail, not its polish. Pick the three or four topics that matter most to you; you rarely get time for more.

Your future engineering manager (EM) shapes more of your day than anyone else you meet in the loop. This guide groups questions by topic, explains what a strong answer sounds like and what deserves a follow-up, gives you a table for reading answers, and ends with a plan for fitting it all into the last ten minutes of the call. For general questions that work with any interviewer, start with our broader list of questions to ask the interviewer.

Why the engineering manager conversation is different

Peers can tell you what the work feels like. The EM can tell you what they control: what the team takes on, how your performance is judged, whether your promotion case gets written and how much interrupt work lands on you. Spend your questions on the things only they can answer.

Two habits make the answers far more useful:

1. Ask about the past, not the philosophy. “How do you think about tech debt?” invites a speech. “What was the last tech debt project the team finished?” invites evidence. Engineer Julia Evans made the same point in her list of questions she asks in interviews: concrete facts, such as when people actually leave the office, tell you more than stated policy.
2. Ask the same question twice. Put the on-call or code review question to an engineer later in the loop and compare the answers. Evans notes it can be worth asking the same question to more than one person.

On-call and incidents

On-call decides how many of your evenings and weekends belong to the job, so it deserves a direct question.

• “How is on-call structured: rotation size, shift length, and how often would I be on?”
• “How many pages does a typical on-call week get, and how many come outside working hours?”
• “Tell me about the last significant incident. What happened in the week after it?”
• “Who owns fixing noisy or useless alerts?”

A strong answer includes numbers and a recent example, and describes a postmortem that focused on what failed rather than who failed, with follow-up work that actually got scheduled. Probe further if you hear “it's not bad” with no detail, “everyone is kind of always on call,” or a story that ends with an engineer being blamed. Questions about on-call pay or time off in lieu are reasonable too; if the EM can't answer them, add them to your questions for the recruiter.

Code review and shipping

How code moves from your laptop to production tells you whether you will spend your days building or waiting.

• “How long does a typical pull request wait for its first review?”
• “How many approvals does a change need, and who can give them?”
• “How often do you deploy, and what does a deploy involve?”
• “What happens when a reviewer and an author disagree?”
• “What testing do you expect with a normal change?”

Google's public engineering-practices guide says one business day is the maximum time it should take to respond to a code review request, and it encourages splitting large changes into smaller ones. A team doesn't need to match Google, but an answer measured in hours or a day is a good sign; reviews that routinely sit for most of a week are worth asking about. Probe further if a single senior engineer approves everything (a bottleneck and a single point of failure), if deploys are rare, manual and dreaded, or if the answer is “it depends who's around.”

Tech debt

Every codebase has debt. What you want to learn is whether the team has a way to pay it down or just a way to talk about it.

• “Which part of the codebase does the team least like touching, and why?”
• “When did the team last spend planned time on tech debt, and what came of it?”
• “How does cleanup work get onto the roadmap: a standing share of each sprint, dedicated projects, or case by case?”
• “How do bugs compete with feature work for time?”

The last one is a modern take on an old idea: Joel Spolsky's 2000 “Joel Test” asked teams, “Do you fix bugs before writing new code?” A strong answer names a specific system, a recent cleanup that shipped and the mechanism that got it scheduled. Probe further if you hear “we don't really have tech debt,” “we'll get to it after the next launch” (ask what happened after the last launch), or if cleanup only happens when engineers do it on their own time.

How priorities are set

This is where you find out how much say you will have over your own work.

• “Who decides what the team works on next quarter, and where do engineers get input?”
• “Walk me through how a recent project went from idea to tickets.”
• “What happens when the team says a deadline isn't realistic?”
• “Roughly how much of the team's time goes to unplanned work: support, interrupts, requests from other teams?”
• “Has the roadmap changed a lot in the last six months? What drove that?”

A strong answer names who owns the roadmap (a product manager, the EM, a tech lead, or a mix), shows engineers writing or reviewing designs before work starts, and describes a time pushback led to a smaller scope or a moved date. Probe further if priorities change every week without explanation, if deadlines are set before anyone has scoped the work, or if “leadership decides” is the whole answer. Changes in direction are normal, especially after a reorg; unexplained ones are the problem.

1:1s and feedback

Your 1:1s are the main channel between you and the person who writes your performance review. Ask how they work in practice.

• “How often do you hold 1:1s, and who sets the agenda?”
• “How do you give feedback, and how would I know where I stand before review time?”
• “How many direct reports do you have right now?”
• “In general terms, can you tell me about a time you gave someone hard feedback? What happened next?”

A strong answer describes a regular cadence the manager actually keeps, an agenda you own, and feedback that arrives as things happen so the formal review holds no surprises. Some managers make a point of asking new reports early on how they prefer to receive feedback and recognition; management author Lara Hogan's list of questions for a first 1:1 has a section on exactly that. If an EM mentions something similar, it's a good sign they adapt to the person. Probe further if 1:1s are mostly status updates, often get canceled, or are replaced by “my door is always open.” A very large number of direct reports is worth a gentle follow-up about how they keep time for each person.

Promotion and career growth

• “How does promotion work here: who writes the case, who decides, and how often does it happen?”
• “Is there a written career ladder or level guide I could read?”
• “Who on the team was promoted most recently, and what did they do to get there?”
• “Is there a path to grow as an individual contributor past senior without moving into management?”
• “What would I need to show in my first year to be on track for the next level?”

Processes vary a lot. At many larger companies a promotion passes through a committee or calibration step beyond your manager; at smaller ones the EM may decide directly. Either can work. What matters is that the manager can describe the steps, point to a recent example and show you criteria in writing. Probe further if the answer is “we promote people when they're ready” with no criteria, if no one on the team has been promoted in a long time, or if growth seems to require leaving the team. Keep questions about raises and pay bands for the recruiter; our salary negotiation guide covers that conversation.

How to read the answers

Most managers will give a reasonable-sounding answer to every question. The signal is in how they answer.

Three follow-ups work on almost any vague answer: “Can you give me a recent example?”, “What would you change about that?” and “How would I know if it wasn't working?”

Keep it in proportion. One weak answer is not a dealbreaker: a manager who is new to the team, or a team that was just reorganized, may honestly not know yet. And don't read too much into tooling. As the open-source “reverse interview” question list on GitHub points out, having a bug tracker doesn't make bug handling efficient, and having CI/CD doesn't mean changes ship quickly. Weight each answer by how much that topic would affect whether you stay.

Fitting it into ten minutes

1. Pick three or four questions. Choose them by thinking about what made you want to leave a past job, or what you would hate in a first one. If on-call burned you out before, lead with on-call.
2. Order them. Open with the role (“What would a great first six months look like?”), then your one or two priority topics, and close with growth.
3. Adjust for your level. New grads get the most from questions about onboarding, mentorship and how junior engineers get code review feedback. Senior engineers should lean toward priorities, scope and the path to staff.
4. Write the answers down right after the call, while you still remember the exact words. You will want them when comparing offers.
5. Ask for more time if you need it. If you get an offer and still have open questions, it is reasonable to ask the recruiter for a short follow-up call with the EM or an engineer on the team.

The EM will often ask about you too, usually through past-project and behavioral questions, so have a strong challenging-project story ready. To see where this session sits in the day, our guide to the full loop interview walks through a typical onsite. Say your questions out loud a few times beforehand so they come out naturally. For the behavioral half of the round, a free AI mock interview in CoPilot Interview lets you answer questions built from your résumé out loud and scores each answer with what to improve.

FAQ

What should I ask an engineering manager in an interview?

Ask how the team works in practice: on-call load, how long code waits for review, how tech debt gets scheduled, who sets priorities, how 1:1s run and how promotions happen. Ask for recent examples rather than opinions so you get evidence you can compare.

How many questions should I ask the engineering manager?

Plan three or four and keep two backups in case they get answered earlier in the conversation. Time for your questions is usually short, so lead with the topics that would most affect whether you stay in the job.

Is it okay to ask an engineering manager about on-call?

Yes. On-call affects your evenings and weekends, and a good manager expects the question. Ask how often you would be on and how many pages a typical week gets; details about on-call pay or time off can go to the recruiter.

Should I ask about promotions in a first interview?

Yes, if you frame it around the process rather than your own timeline: ask how promotions work and what the most recent one on the team looked like. Save questions about raises and pay bands for the recruiter.

What is a red flag in an engineering manager's answers?

Vague answers to concrete questions, no recent examples, claims of zero tech debt, or a story that contradicts what an engineer on the team told you. One weak answer is not decisive, but a pattern is.

What if the person interviewing me will not be my manager?

Some companies match you to a team after the interview loop, so the manager you meet may not be the one you report to. In that case, ask how team matching works and save the team-specific questions for the team-matching conversation.