I have been in many discussions on the best way to interview and hire engineering managers. Here are my thoughts, having done this both successfully and less successfully, including some things that I have looked for in the past when being interviewed.
First: Be thoughtful about what you are looking for. There are people out there who are looking for the opportunity to go into management. Lots of them, in my experience. These are good people to hire, because many of them will turn out to be good, thoughtful managers. Most of the time I hired this sort of person into a senior engineering role that quickly became a tech lead role. I was explicit at hiring that we didn't have a team to give them immediately but that I would be expecting that as the overall team grew they would move into such a role when it became available.
Now, I should be clear, this exchange requires a lot of trust on both parties, as well as the possibly unspoken assumption that they still have to prove themselves capable of doing the job once on the team. I have turned down jobs that asked me to make this bet, and I would not hold it against anyone who felt that it was too risky. But on the flip side, if you really want to grow your management from within, hiring people who both want to be eventually moving to leadership roles but are comfortable coming in as individual contributors first is pretty essential to making that work. If you want to grow management from within but don't bother to look for people who want to grow into management roles when you're hiring, you may end up with mostly people who just want to code, and that is not good for anyone.
What you are looking for: Someone who answers with more than just "I designed the architecture, chose the libraries, and wrote the most technically challenging pieces of the code." They should have taken an active role in the project management, even if there was another person explicitly or implicitly in that role. They should have contributed to predicting problems with the delivery and working with the people on the team or cross-team to ensure success.
What you are looking for: Someone who is actively engaged in the work of bringing on new people, and thoughtful about making that process better. Someone who respected the work of mentoring, who isn't just trying to shed human interactions quickly to get back to code.
What you are looking for: Some strong examples of seeing process/people/systems problems and raising their hand to suggest improvements.
One suggestion I have heard, but not tried, is to do a role-playing exercise with the candidate. Set up a circumstance that might happen, such as, an employee is unhappy that they did not get promoted. Provide an overview to the candidate and give the interviewer some details that may include information that the manager doesn't necessarily know. Have a third party observe the interaction, and then at the end of the role play all three talk about what went well and didn't. This could be an interesting tool for hiring either the experienced manager or the potential-driven manager, but I also suspect it is easy on the flip side for it to go poorly if the interviewer isn't good at guiding the roleplay and knowing what to look for. (Credit to Marc Hedlund for this idea!)
Finally, when hiring this type of candidate, you are probably going to get (and maybe even should be intentionally seeking out) someone who is going to not only manage people but drive technical decision-making. Make sure that the people who currently drive technical direction (if they exist) are aligned on that front with the candidate. If the candidate is gung-ho about functional programming and microservices and you are happy in a more conservative technical space, you may end up with someone who wants to make big technical changes that you might not agree with. The team should feel a general alignment to their technical perspective, and ideally people are excited about working for this person because they feel that they will learn something, but don't just hire them as a manager because people are excited about their technical chops.
Overall, when screening for potential, look for signs of stepping up, caring about the people on the team, and thoughtfulness about the processes. In general you should also be looking for excellent communication skills, and everyone who interviews the person should feel pretty comfortable with the idea of working for them. Be wise to potential bias here. The best managers are often overlooked because they don't pattern match to certain characteristics, whether they are "tall and male" or "forceful personality" or whatever. Talk to the team before the interview and give them examples of great managers who sit outside of those stereotypes to reset their stereotype bias a little bit.
When you mishire on potential, it tends to come from overvaluing technical skills + pattern matching on "what a leader looks like", and the failure mode is managers who just don't deliver coherent teams and/or can't deliver projects effectively. Never ever hire a person you feel is overly ego-driven.
One final word on this candidate: If you hire someone for potential, be prepared to train them. They are going to need help. Whether it is formal training or a lot of mentorship from you or a mix of both, no one is born knowing how to manage. I think it is worth sometimes taking a risk on people like this (I'm glad someone did that for me once!) but they will struggle if they have to do it all alone.
First: Be thoughtful about what you are looking for. There are people out there who are looking for the opportunity to go into management. Lots of them, in my experience. These are good people to hire, because many of them will turn out to be good, thoughtful managers. Most of the time I hired this sort of person into a senior engineering role that quickly became a tech lead role. I was explicit at hiring that we didn't have a team to give them immediately but that I would be expecting that as the overall team grew they would move into such a role when it became available.
Now, I should be clear, this exchange requires a lot of trust on both parties, as well as the possibly unspoken assumption that they still have to prove themselves capable of doing the job once on the team. I have turned down jobs that asked me to make this bet, and I would not hold it against anyone who felt that it was too risky. But on the flip side, if you really want to grow your management from within, hiring people who both want to be eventually moving to leadership roles but are comfortable coming in as individual contributors first is pretty essential to making that work. If you want to grow management from within but don't bother to look for people who want to grow into management roles when you're hiring, you may end up with mostly people who just want to code, and that is not good for anyone.
OK, so you're hiring a specific management position. What do you look for?
There are two camps here. The first camp is that you look for incredibly smart tech lead-level developers who may have had limited management experience and put them in the role. They will easily pass whatever technical screens you put in front of them, but hiring is a risk because they may not really be good managers. If this is the way you want to go about hiring managers, you need to spend a good deal of time focused on screening for management potential. Screening for potential is different than screening for experience. Right now, I'm going to talk about screening for potential; in part 2, I'll talk about experience.Questions to tease out potential:
Tell me about a project where you have acted as the tech lead. What was your role like, as tech lead? What were things you did that were different from the rest of the team? How did you ensure that the project was successful?
What you are looking for: Someone who answers with more than just "I designed the architecture, chose the libraries, and wrote the most technically challenging pieces of the code." They should have taken an active role in the project management, even if there was another person explicitly or implicitly in that role. They should have contributed to predicting problems with the delivery and working with the people on the team or cross-team to ensure success.
When you bring a new team member onto your team, what kinds of things do you personally do as part of their onboarding? Have you ever been a mentor to a new hire or intern? What was that like, what did you learn from it?
What you are looking for: Someone who is actively engaged in the work of bringing on new people, and thoughtful about making that process better. Someone who respected the work of mentoring, who isn't just trying to shed human interactions quickly to get back to code.
Tell me about some things you have done to make the process of writing or delivering code in your organization better.
What you are looking for: Some strong examples of seeing process/people/systems problems and raising their hand to suggest improvements.
One suggestion I have heard, but not tried, is to do a role-playing exercise with the candidate. Set up a circumstance that might happen, such as, an employee is unhappy that they did not get promoted. Provide an overview to the candidate and give the interviewer some details that may include information that the manager doesn't necessarily know. Have a third party observe the interaction, and then at the end of the role play all three talk about what went well and didn't. This could be an interesting tool for hiring either the experienced manager or the potential-driven manager, but I also suspect it is easy on the flip side for it to go poorly if the interviewer isn't good at guiding the roleplay and knowing what to look for. (Credit to Marc Hedlund for this idea!)
Finally, when hiring this type of candidate, you are probably going to get (and maybe even should be intentionally seeking out) someone who is going to not only manage people but drive technical decision-making. Make sure that the people who currently drive technical direction (if they exist) are aligned on that front with the candidate. If the candidate is gung-ho about functional programming and microservices and you are happy in a more conservative technical space, you may end up with someone who wants to make big technical changes that you might not agree with. The team should feel a general alignment to their technical perspective, and ideally people are excited about working for this person because they feel that they will learn something, but don't just hire them as a manager because people are excited about their technical chops.
Overall, when screening for potential, look for signs of stepping up, caring about the people on the team, and thoughtfulness about the processes. In general you should also be looking for excellent communication skills, and everyone who interviews the person should feel pretty comfortable with the idea of working for them. Be wise to potential bias here. The best managers are often overlooked because they don't pattern match to certain characteristics, whether they are "tall and male" or "forceful personality" or whatever. Talk to the team before the interview and give them examples of great managers who sit outside of those stereotypes to reset their stereotype bias a little bit.
When you mishire on potential, it tends to come from overvaluing technical skills + pattern matching on "what a leader looks like", and the failure mode is managers who just don't deliver coherent teams and/or can't deliver projects effectively. Never ever hire a person you feel is overly ego-driven.
One final word on this candidate: If you hire someone for potential, be prepared to train them. They are going to need help. Whether it is formal training or a lot of mentorship from you or a mix of both, no one is born knowing how to manage. I think it is worth sometimes taking a risk on people like this (I'm glad someone did that for me once!) but they will struggle if they have to do it all alone.