In this article
How to use this list
The questions are the kinds candidates report in engineering manager interviews, reworded in our own words. No question is claimed for a named company, and the answers are general guidance, not any company's scoring. Say each answer aloud in your own words, with a real example from your work. For other topics, the learning hub lists every guide, and the AI diagrams draw related systems step by step.
People management and feedback
How do you give hard feedback to an engineer?
Say it soon, in private, and about specific behaviour and its effect, not about the person. State the expectation, ask for their view, and agree the next step and a follow-up time. A strong answer includes an example where the person improved, and what you changed in how you gave feedback.
Why it is asked: it shows whether you avoid hard conversations or handle them with care.
How do you manage an underperforming engineer?
First find the cause: unclear goals, a skill gap, a bad fit for the work or a personal issue. Set clear, written expectations and support, check progress often, and keep the person's dignity. Escalate to a formal process only after real chances to improve have passed.
Why it is asked: it tests judgement between patience and fairness to the rest of the team.
How do you grow and promote the people on your team?
Learn each person's goals, give them work slightly beyond their current level, and name the gap to the next level in plain terms. Coach, sponsor them in rooms they are not in, and keep notes on their impact so promotion cases rest on evidence.
Why it is asked: it separates managers who build people from managers who only use them.
How do you keep a team motivated through a hard stretch?
Be honest about the situation, explain why the work matters, remove blockers you can, and protect the team from avoidable noise. Recognise effort specifically and watch for burnout signs, such as quiet withdrawal or slipping quality. Ask the team what would help most, since people often know which friction costs them the most energy.
Why it is asked: it checks whether you can lead when morale is low.
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 →Hiring and team building
How do you run a hiring process for your team?
Define the role and the signals you need first, then design interview questions that test those signals. Use the same structure for every candidate (the practice behind structured interviews), collect written feedback before the group discusses, and decide against the agreed bar, not on a gut feeling.
Why it is asked: it shows if you can hire fairly and consistently.
How do you decide whether to hire a strong candidate who is a poor fit for the team?
Separate fit as shared values and working style from fit as sameness. Weigh what the candidate adds against the concern, test the concern with a follow-up conversation, and say no if the concern is about how they treat people.
Why it is asked: it probes bias, culture thinking and your bar.
How do you build a diverse and balanced team?
Widen where you source, remove vague requirements from job posts, and use structured interviews. Balance skills and levels across the team, and make sure people who join are supported and heard once they are in. Look at each stage of your hiring pipeline to see where candidates drop out, and fix those stages.
Why it is asked: it checks that you treat inclusion as a practice, not a slogan.
How would you onboard a new engineer?
Prepare a plan before the first day: access, a buddy, a small first task that ships quickly, and clear expectations for the first months. Check in often and ask what is confusing, then improve the plan for the next hire.
Why it is asked: onboarding shows how you think about team systems.
Delivery and execution
How do you keep a project on schedule?
Break it into milestones with visible risks, review progress often, and raise slips early. When a date is at risk, offer options: cut scope, add time or add help, and let the stakeholders choose with the trade-offs in view.
Why it is asked: it tests planning and honest communication about risk.
How do you balance delivery speed against quality and technical debt?
Treat debt as a deliberate loan: take it knowingly, record it and schedule its repayment. Protect a steady share of time for reliability and cleanup, and explain debt to stakeholders in terms of future speed and risk.
Why it is asked: it shows if you can defend long-term health against short-term pressure.
How do you handle a missed deadline or a production incident?
Restore service first, then communicate clearly and keep updates regular. Afterwards, run a blameless review, a practice described in Google's postmortem guidance and in the workbook chapter on postmortem culture, that finds the process causes, assign owners to fixes and follow up until they are done.
Why it is asked: it reveals your calm, ownership and learning habits.
Conflict and stakeholders
How do you resolve a conflict between two engineers?
Speak to each person separately to understand their view, then bring them together around the shared goal and the facts. Agree on a decision method, and step in with a decision yourself if they cannot settle it. Afterwards, check in with both people to confirm the working relationship has recovered and the agreement is being kept.
Why it is asked: it tests fairness and willingness to mediate.
How do you say no to a product manager or senior stakeholder?
Start from their goal, show the cost and the trade-off of the request, and offer alternatives that serve the goal within the constraints. Put the decision in writing, and stay open to new information. Offer a condition or a date at which you would revisit the request, so the answer reads as "not now, and here is why" rather than a flat refusal.
Why it is asked: it checks that you can protect the team without damaging relationships.
How do you work with a peer team that is blocking you?
Learn their priorities first, then find a change that helps both teams. Meet their lead early, before the blocker becomes urgent, and write down what each team needs and by when, so the disagreement is about facts. If that fails, agree on a shared owner for the decision and escalate together, with facts, not blame.
Why it is asked: it shows influence without authority.
Technical judgement and architecture oversight
How do you stay technical as a manager?
Read design documents and code reviews selectively, join architecture discussions to ask questions, and keep a small, low-risk hands-on habit. Keeping up with the basics of deep learning and transformers helps if your team builds machine learning products. The aim is to judge trade-offs well, not to be the best coder on the team.
Why it is asked: it separates managers who keep technical credibility from those who drift.
How do you review a technical design you did not write?
Ask what problem it solves, what alternatives were considered, how it fails and how it will be tested and operated. A machine learning system design review follows the same questions. Focus on risk and reversibility, and let the authors own the decision unless the risk is high.
Why it is asked: it tests oversight without micromanagement.
Strategy and prioritisation
How do you prioritise a long list of requests with limited people?
Tie each item to a team goal, estimate value and effort roughly, and drop or delay what does not move the goals. Share the ordering openly so stakeholders see the trade-offs and know what is not being done.
Why it is asked: it tests whether you can say no with a reason.
How do you set a technical direction for your team over the next year?
Start from the business goals and the main pain points, gather input from the engineers, and choose a few bets with clear outcomes. Write the plan down, review it regularly and change it when facts change.
Why it is asked: it shows whether you can think beyond the current sprint.
Behavioural stories
Tell me about a time you failed as a manager.
Pick a real failure with real cost, state your part without excuses, and explain what you changed afterwards. A strong answer ends with a lasting change in how you work, not a lesson in general terms.
Why it is asked: it measures self-awareness and growth.
Tell me about a hard decision you made with incomplete information.
Describe the situation, the options and the risks, how you gathered what you could in the time you had, and the decision you took. Then say what happened and what you would do differently.
Why it is asked: it shows judgement under uncertainty.
Follow-up questions
What does EM 100 mean?
EM 100 is the name of this page's set of engineering manager interview questions. It is not a company's official list, and it makes no claim about what any company asks.
Is an engineering manager the same as a tech lead?
No. A tech lead guides the technical direction of a team and usually still writes code. An engineering manager is responsible for the people, their growth and the team's delivery, though the two roles overlap and differ by company.
How long should a spoken answer be?
Aim for an answer you can say in about a minute: the situation, what you did and the result. Offer to go deeper if the interviewer asks.
Do these answers suit a first-time manager?
Yes. If you have not managed before, use examples from leading a project, mentoring or running a process, and say how you would approach the part you have not done.
- An engineering manager answers for both a team's people and its results.
- Strong answers use a real example, name the trade-off and end with the result.
- Hard feedback, hiring and conflict questions test fairness as well as skill.
- Technical questions test judgement and oversight, not who codes fastest.
- Each question here is reported by candidates, not claimed for any company.
Sources
- Site Reliability Engineering: Postmortem Culture: Learning from Failure — Google (Site Reliability Engineering book), 1 Apr 2016
- The Site Reliability Workbook: Postmortem Culture: Learning from Failure — Google (Site Reliability Workbook), 1 Jul 2018
- Structured Interviews — U.S. Office of Personnel Management, 26 Oct 2026
