Hiring Engineering Managers Part II

In Part I of this series, I talk about shaping the role and how to think about who to hire. In Part II, we’ll cover how to hire and what to ask to ensure you make the best possible hire.


In Part I we discussed what an EM role is shaped like and what competencies we expect candidates to have. These cover both leadership and technical skills. Our final list looked like this:

  • Coach and mentor your team members to ensure everyone understands their responsibilities.
  • Conduct 1:1s with the team to understand their status and needs and ensure everyone is performing well.
  • Manage team members’ career goals, professional growth, and ambitions.
  • Own developing and maintaining a healthy team culture.
  • Help convert the businesses needs into Engineering plans
  • Help set technical direction
  • Help the team plan and validate estimates
  • Understand if what is built is architecturally correct, built with the correct patterns, and represents quality
  • Support and grow the skills of their team

In this post I’m going to articulate how we validate that candidates have the skills we need and are the right fit for our organization.

Interview Process

There is a myriad of different approaches to the interview process. I am presenting the approach I have had the most success with when hiring EMs. I’ve done this or variants of it for several years, tweaked for specific circumstances and different types of organizations.


Let’s walk through each interview step.

Recruiter screen

A recruiter friend of mine calls this “the human check.” It’s usually about 30 minutes and has got three primary purposes.

The first is to validate that the candidate is who they say they are and confirm the basic details around their resume. Understand their interest in the role and the timing of their job search, and any logistical information, like what time zones they are in or trips they have planned.

The second purpose is to lay out the interview process, talking the candidate through each step and what is involved, who they will be meeting, etc. I have tried, in the past, to put this into a one-pager. You can send the candidate a rough workflow of the process, the intent of each interview step, and a list of people they’ll meet with background/LinkedIn link on each. If specific people aren’t assigned to each step, then include an archetype of who will interview them.

The third purpose, and arguably the most important, is to see how the candidate interacts with the recruiter. Are they polite and friendly? Do they treat the recruiter like a human being and with respect? You can tell a lot from how people treat people they don’t think are important: if they treat them disrespectfully or with disdain, that’s a clear red flag.

A friend’s company always quizzes the receptionist/office manager and the interview coordinator about how the candidate interacted with them. I know of at least one instance where that company declined a candidate because they acted like an entitled arsehole to the staff supporting the interview process.

People get nervous in the interview process, which can lead to awkward interactions. Other folks do have neuro-divergent behaviors that could be misconstrued as rudeness. The feedback from this stage, and the support staff, should be considered in the context of the whole interview process.

Hiring Manager Screen

This stage is usually a 1-hour call with the hiring manager. I open with introductions, a restatement of why we’re here, and a breakdown of how we will structure the call.

“Hi - I’m James Turnbull. I’m a VPE at AnyCorp. We’re hiring an EM for our Platform Team, and I’d love to hear a bit about you, ask some questions, and then give you a chance to ask me some questions about the role, the company, our culture, and anything else you’d like to cover.”

I ask them to talk about their career at a high level, with more detail for recent roles. I find this usually takes about 10 minutes. I then ask them what interests them about the role and the company. This response is an excellent signal to see how engaged they are, did they do research, and do they seem genuinely interested in the role.

Next, I ask some questions. Here’s a selection of my favorites.

  • Describe your leadership style?
  • What’s different about being a manager from being an IC? What is challenging about that transition?
  • What does managing up mean to you? What’s involved?
  • What do you look for in a manager?
  • What’s important to do if you’re managing a remote team or remote team members?
  • During Covid, have you changed your management approach? Have you done different or new things?
  • How do you motivate your team?
  • How do you identify burnout in a team member?
  • How do you manage and measure your team’s velocity?
  • What’s your approach to planning your team’s work?
  • You don’t think you have enough resources in your team. How do you confirm this, and what do you do about it? What do you do if there isn’t the capacity to add new team members?
  • It looks like a deadline is going to slip. What do you do?
  • How would you handle a conflict between two of your team members? What about a conflict between a member of your team and a member of another team?
  • A senior engineer from outside your team harshly critiques a PR written by a junior engineer on your team. What do you do next?
  • You have an engineer who is not performing well and failing to deliver. What would you do?
  • Have you ever had to let anyone go? Tell me about the situation and how you approached it?
  • Tell me about your mentoring approach.
  • What qualities do you look for when hiring engineers?
  • What’s your favorite interview question for engineers? Why is it your favorite?
  • What’s your process for onboarding a new engineer?

I usually reserve about 30 minutes for some subset of these questions.

I then take five minutes to overview the role, the team they’ll be joining, and a bit about our current process, stacks, plans, or projects. I find this helps seed questions for candidates. I always leave about 15 minutes in the end for the candidate to ask me questions about the role, the company, or anything else they’d like to know. It’s a red flag for me if a candidate has no questions. I block out the 15-30 minutes after a call to write my notes while they are still fresh in my head, so I am usually happy to go overtime if the candidate is amenable and available. I always offer to answer further questions via email if something pops up later for the candidate.

At this point, I decide whether a candidate will advance to the additional steps in the process or if we’ll decline. If we decline, we try to get back to them quickly. It sucks not getting a role you’re excited about, but I hate it more not knowing the status.

If you proceed with the candidate, we now go into the more intensive steps. In the olden days, this would have been the on-site stage of the process. This process is now done remotely for many organizations, either due to Covid or because you’re hiring remotely and logistics make getting the candidate on-site difficult.

Working together exercise

We’re looking for people who will support and grow the team to deliver on their objectives. The “working together” exercise aims to tease out these skills by working on an actual problem they might experience in the role. I usually put aside 45 minutes to an hour and run the exercise as I would a pairing session writing code.

Another approach is to have another Engineering leader other than you give the interview to get more third-party input.

I aim to find a problem or problems that combine planning, technical design, and some obstacles that need to be worked on. I try to find scenarios relevant to the organization and or problems we’ve had, so it’s as realistic an exercise as possible. Here’s two examples:


“Your team and a peer’s team are building two products that do different things. But the data both your teams are using from the backend is almost identical. There is currently no API that exposes any of this data for your products. How should you proceed with designing and developing your team’s product and the API to support it?”

You can also extend the scenario with new prompts, depending on their responses:

“You’ve decided to build a shared API endpoint for the two products. Your most senior engineer has designed the API, but the engineers in your peer’s team don’t believe the design is the right approach. How do you resolve this?”

“The business has requested a feature that your peer’s team must deliver urgently. Your plan depends on having both teams available. What do you do next? How does this impact the plan?”

“You’ve built the backend API, and now you want to roll it out into production. Your peer thinks your team should be responsible for managing and maintaining it. You don’t think you have the resources to manage it alone. How do you respond?”


There are a few things we’re looking for as a rubric for a successful response, based on the competencies that we’re seeking, here’s some examples:

  • Do they propose to build a shared service? If not, why not? If they do, do they collaborate directly cross-team or divide the work into half? Why or why not?
  • How do they propose to manage dependencies on the same shared services between the two teams?
  • Do they resolve any conflict between the two teams with collaboration and communication?
  • How did they negotiate shared responsibilities for the service?

Onboarding and mentoring

“You’ve been asked to build an onboarding and mentoring program for new engineers coming into the team. The objective is to introduce them to the company, the product, the codebase, tools, and processes and help them become productive members of the team as quickly as possible. The mentoring program would provide continued education and support new engineers, primarily for junior engineers but open to everyone. What does your program look like? Write up a short document or presentation explaining how the programs would work.


There are a few things we’re looking for as a rubric for a successful response, based on the competencies that we’re seeking, here’s some examples:

  • Are the outcomes of the programs measurable?
  • Is the emphasis of the onboarding process based on collaborative learning or does it rely only on self-learning? Or a mix thereof?
  • Does the mentoring program support mentees? Check ins? Follow-up? Skip level discussions?

Some people rocket through an exercise like this. If they get through it, I usually run through a second if we still have time for more.

Product call

The product call is conducted by a Product Manager, preferably one associated with the team for which you’re hiring an EM. This call aims to discover two things:

  • What’s their product sense and skills
  • How good a partner will they be for the Product Manager

The call usually covers concepts like planning, estimates, requirements analysis, story creation and management, deployment, and rollout of new features. Using these areas, they can determine if the candidate knows how to work within a development workflow and whether they will be collaborative, communicative, and a good peer.

Leader call

This last step in the “on-site” phase of the interview process is the candidate meeting another senior technology leader; this could be a people leader or a Staff or Principal Engineer. This leader could be someone from elsewhere in the technology organization, another department, or division. Their role is to quiz the candidate on their leadership and collaboration skills. I think about this as my “objective third-party viewpoint.” Amazon calls similar interviews “bar-raising,” and Microsoft and Google do similar things.

I find the best way to approach the format of this interview is to focus on the competencies you’re interested in validating and sharing those with the interviewer. Most senior people have an approach they take to interviewing and if you’re working with a wide pool of people then standardizing the approach is usually quite hard. Tying the interview back

Hiring Manager Closing (optional)

Lastly, I may do a follow-up call with the candidate. I usually only do this if questions are raised during the interview process that we would like to explore further, such as contradictory behavior or areas of weakness we want to probe further. I also use this call to sell the candidate on the role if we have any concerns that they might need a push. If we think the candidate needs a significant push, we will pull in a senior leader like the CEO, CTO, CPO, etc., to help close the candidate.


I hope this proves useful for folks, and I’d love to here from you on what works for you or if you disagree with the approach I’ve laid out. I am always interested in hearing about successful and unsuccessful) hiring techniques!