Ask HN: How to prepare for an Engineering Manager interview?
75 comments
I maintain a list of engineering management resources here: https://github.com/charlax/engineering-management
I think it provides a pretty comprehensive list of topics that you could chat about during your interviews. Rather than making a good impression, you should talk truthfully about those topics. Worst case you'll learn something about them. Management is a great role that requires constant learning.
Good luck for the interviews!
I think it provides a pretty comprehensive list of topics that you could chat about during your interviews. Rather than making a good impression, you should talk truthfully about those topics. Worst case you'll learn something about them. Management is a great role that requires constant learning.
Good luck for the interviews!
Read The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier
OP - do yourself a favor and read this short book (or just the first few chapters applicable to you). It's the best, most practical book on software engineering management that I've seen, and I'm only half-way through it.
You don't have the experience for the role. And that may be okay as long as you're honest and upfront about that and show a willingness to learn.
A big component of managing a dev team is performance-management- managing good and bad performers. Don't try to BS your way through that or other questions, but rather acknowledge where your gaps are and let them know that they are known unknowns rather than being oblivious to their existence.
A big component of managing a dev team is performance-management- managing good and bad performers. Don't try to BS your way through that or other questions, but rather acknowledge where your gaps are and let them know that they are known unknowns rather than being oblivious to their existence.
Ten years and you have never led anybody? Think back, I am sure there were moments where you led/guided/coached peers or were a sparring partner.
You should sell those experiences as first steps into being a leader.
However, you should be aware that managing and coding are so different, even if it's in the same field. Managing people is tough and you learn it by doing.
You should sell those experiences as first steps into being a leader.
However, you should be aware that managing and coding are so different, even if it's in the same field. Managing people is tough and you learn it by doing.
The author seems to be pretty clear about having been a team lead but never having directly managed anyone. Huge difference. Having a similar background myself, I can say this is probably one of the biggest hurdles if you're looking to get into management. You can talk at length about mentorship and leading through influence and judgment and all the stuff that goes with being a "technical lead" but it doesn't make much of a difference--they want someone who's had direct reports.
It's the typical hiring chicken-and-egg problem: You need experience doing X to get a job doing X. People management is no different.
It's the typical hiring chicken-and-egg problem: You need experience doing X to get a job doing X. People management is no different.
I would agree that I wouldn't typically hire a manager from outside my company if they have no previous time in that role, mostly because ramping up on all of the internal company structure, technology and processes is enough to keep people quite busy without having to learn how to be a people manager.
That being said, I feel the opposite about internal hires. One of the great joys of being a manager is coaching and mentoring the next generation of managers and having a healthy pipeline of candidates serves your company well.
That being said, I feel the opposite about internal hires. One of the great joys of being a manager is coaching and mentoring the next generation of managers and having a healthy pipeline of candidates serves your company well.
The book What Color Is Your Parachute? recommended that people looking to make a career change do it in two steps: changing your job/role and then industry/company (or vice versa).
I've heard lots of names for managers, but never had someone called a "team lead" and not had direct reports.
It's reasonably common for there to be a "first among equals" type situation where the person with a title like "technical lead" or "team lead" has technical decision-making authority within the team, but isn't formally a manager of any of the team members in the HR sense.
Yep, "technical lead" is that in my head, but perhaps that's because a "team lead" is line manager everywhere I have been.
Never thought about it as "first among equals", this is true.
Well now you have. Nice to meet you!
If you don’t mind me asking, how did you bridge that gap and how have you liked that move in career? Just curious about your experience
I'm not the person you responded to, but I did also recently make a transition from an individual contributor role into a management role and can share some experiences.
In addition to taking on more leadership roles in engineering projects, I began finding and taking on opportunities on the side that have a managerial element to them, for instance recruiting (sourcing, behavioral interviews, selling candidates, redesigning our interviewing processes), mentoring/coaching people, driving our company's internship program, etc. I found that I enjoyed that sort of nontechnical work. In particular, I liked thinking about how to grow other people and help them be effective.
I vaguely started thinking that I wanted to just switch into management, and I advertised that fact (mostly to managers). I wasn't too urgent about it, and an opportunity showed up [after a few months] and the management team thought of me first as someone who could be a good fit. Part of what made it a good fit was that the team was not 'on fire' or anything, so if I were to do a bad job or realize I didn't like management and thus needed to switch back, the company wouldn't be in a particularly bad situation.
In addition to taking on more leadership roles in engineering projects, I began finding and taking on opportunities on the side that have a managerial element to them, for instance recruiting (sourcing, behavioral interviews, selling candidates, redesigning our interviewing processes), mentoring/coaching people, driving our company's internship program, etc. I found that I enjoyed that sort of nontechnical work. In particular, I liked thinking about how to grow other people and help them be effective.
I vaguely started thinking that I wanted to just switch into management, and I advertised that fact (mostly to managers). I wasn't too urgent about it, and an opportunity showed up [after a few months] and the management team thought of me first as someone who could be a good fit. Part of what made it a good fit was that the team was not 'on fire' or anything, so if I were to do a bad job or realize I didn't like management and thus needed to switch back, the company wouldn't be in a particularly bad situation.
Sadly, I have not bridged that gap (YET!). In the past I've made lateral transitions into product management and project management, but these roles, like "engineer" are individual contributor roles and have similar career limitations.
Here's some random things I'd consider green flags during an interview:
- A desire to help others accomplish their goals, not simply extract work from them. Sometimes this means moving them to another team/project or even out of the company.
- Proficiency in *-manager skills (product manager, project manager, etc.). Frontline managers often end up filling the roles that their team doesn't have anyone else for.
- You mentioned mentorship, which is great to talk about. Sometimes you're a direct mentor, sometimes you're identifying potential mentors, but it's important to understand what works well.
- For this situation in particular, be honest about the fact that you're new to management and looking to skill up. Part of managing people is understanding their career goals and how to help them move up, and understanding your own career, where you are, and where you'd like to go will illustrate that skill.
- A desire to help others accomplish their goals, not simply extract work from them. Sometimes this means moving them to another team/project or even out of the company.
- Proficiency in *-manager skills (product manager, project manager, etc.). Frontline managers often end up filling the roles that their team doesn't have anyone else for.
- You mentioned mentorship, which is great to talk about. Sometimes you're a direct mentor, sometimes you're identifying potential mentors, but it's important to understand what works well.
- For this situation in particular, be honest about the fact that you're new to management and looking to skill up. Part of managing people is understanding their career goals and how to help them move up, and understanding your own career, where you are, and where you'd like to go will illustrate that skill.
Read _Behind Closed Doors The Secret of Great Management_ by Johanna Rothman and Esther Derby.
Look for opportunities to do supervision. Non-profits are always looking for help, and it makes you look well rounded on your resume. There's no substitute for doing to learn how to manage.
Look for opportunities to do supervision. Non-profits are always looking for help, and it makes you look well rounded on your resume. There's no substitute for doing to learn how to manage.
In general you should be more than capable of explaining your lead role as a coaching role and helping people to get better. Ideally some of that experience was not just with juniors but also mid level - senior engineers.
Did you start anything up in the company - ideally yes. Shows you can spot opportunities.
Do you understand the role of the manager in this company, in the context, probably good to show some self awareness (Are you being hired in for a new team, existing team, if so why not hire internally etc.)
After that expect to explain how you deal with poor performers, how do you reward people etc.
Did you start anything up in the company - ideally yes. Shows you can spot opportunities.
Do you understand the role of the manager in this company, in the context, probably good to show some self awareness (Are you being hired in for a new team, existing team, if so why not hire internally etc.)
After that expect to explain how you deal with poor performers, how do you reward people etc.
I'd gather you'll want to think fairly hard about scenarios you have encountered in the past where you helped a team you were on through a rough patch, or helped ship a product on time, or pull people together. You'll probably also want to have some sort of hypothesis about what makes a successful manager, what makes for a successful team, how to deal with failure, etc. If you haven't though about these things or are not interested then you may not enjoy management.
Edit: I would also come ready with any sort of anecdotes about how you took initiative to do something and managed it end to end. Could be an event, could be a product, could be a code release - but that track record is definitely an indicator.
Edit: I would also come ready with any sort of anecdotes about how you took initiative to do something and managed it end to end. Could be an event, could be a product, could be a code release - but that track record is definitely an indicator.
I don't often hire people into manager roles if they have no management experience (usually there are internal people who are looking for that career growth, if we are pulling from outside then it's about experience). That said, there are a few things that would make me at least consider it.
1) the person wants a management career path and seems to understand what it means (org builder, team player, perf reviews, hiring and firing) vs person who thinks their only option for career growth is management and thinks they've done it already as a tech lead and wanna do that role more
2) lots of cross-functional hat wearing and a clear appreciation and happiness with doing project and product management work, a willingness to do any shit work happily in order to make the team better
3) an awesome growth mindset willing to have determination in getting better at it with or without my help, lots of autonomy
4) preternatural judgement and ability to see the forest from the trees, clear potential to help us get better
Interviewed somebody like this recently and it's honestly just hard to say no
1) the person wants a management career path and seems to understand what it means (org builder, team player, perf reviews, hiring and firing) vs person who thinks their only option for career growth is management and thinks they've done it already as a tech lead and wanna do that role more
2) lots of cross-functional hat wearing and a clear appreciation and happiness with doing project and product management work, a willingness to do any shit work happily in order to make the team better
3) an awesome growth mindset willing to have determination in getting better at it with or without my help, lots of autonomy
4) preternatural judgement and ability to see the forest from the trees, clear potential to help us get better
Interviewed somebody like this recently and it's honestly just hard to say no
There are already some great suggestions on here, but I love this topic so here are mine.
For the interview, come up with an answer to this: Tell me about a time you leveraged your experience and knowledge to multiply the efforts of your team.
A lot of what you will be doing is spending your time helping your team do good work on the right things, so any experience you have where you have done that as a senior or lead is relevant.
When you become a manager:
1. Find a mentor
2. https://www.manager-tools.com/get-started - Some really good fundamentals in podcast form. You can listen on your commute(if you have one)
3. http://randsinrepose.com/archives/category/management/ - Articles on management from an engineering manager.
I would pick one article and one podcast to consume each week so you have time to actually absorb it. If you try to implement some kind of perfect program from the beginning you will likely fail.
For the interview, come up with an answer to this: Tell me about a time you leveraged your experience and knowledge to multiply the efforts of your team.
A lot of what you will be doing is spending your time helping your team do good work on the right things, so any experience you have where you have done that as a senior or lead is relevant.
When you become a manager:
1. Find a mentor
2. https://www.manager-tools.com/get-started - Some really good fundamentals in podcast form. You can listen on your commute(if you have one)
3. http://randsinrepose.com/archives/category/management/ - Articles on management from an engineering manager.
I would pick one article and one podcast to consume each week so you have time to actually absorb it. If you try to implement some kind of perfect program from the beginning you will likely fail.
In the startup world finding a mentor may be hard, and if you are in that situation you may want to look outside for a mentor. But if you are at a large organization, there is often a support network or mentor program already available. Take advantage of it!
If you can, ask your current manager to write a SWOT and use it to pair you up within a mentor to make strengthen your weaknesses. Try to find a mentor outside of your reporting chain.
If you can, ask your current manager to write a SWOT and use it to pair you up within a mentor to make strengthen your weaknesses. Try to find a mentor outside of your reporting chain.
I often suggest having an external mentor regardless, because you can be more candid with confidence that the conversation isn't going anywhere. It's easier said than done, but finding a mentor from a high performing company who is 1-2 levels above you has been really ideal for me.
[deleted]
One of the things you should think about in your interview is how you're planning on interviewing them to make sure they're the right fit for your first managerial role. Managing a team, even for those who have been tech leads or in some leadership position without management responsibilities, is a very different role than being an individual contributor. You should think about this the same way you might if you were coming in as a Junior SE, or pivoting into a different specialty within the profession.
So, a few things I would think about would be:
[1] Who will you report to, and what is their management experience? How do their direct reports (likely other managers) view their management skills? Are they a teacher, or do they expect you to "pick things up" on your own? If they expect you to pick things up on your own, will they work with you and potentially pay for training classes or professional coaching?
[2] What is the structure of the team? Is it mostly senior members, or mostly junior members? What are their expectations of a new manager? Does the company typically promote from within, and you'll be an abnormal outsider?
[3] What are the expectations around the management responsibility, beyond day to day team issues? Will they be expecting you to hire new employees? Do you need to handle raises, promotions, and firing? Will you be expected to put together a budget every year?
All of the above is meant to help you to assess whether the role is going to be one that you can be successful in. Management is a great job, and I loved helping my teams grow in their careers; however, I think I would have floundered had I not had a great mentor who helped coach me specifically in these skills. I also think I would have struggled mightily had I jumped into a management role, without prior management experience, with a new team and a new company. Managing a team as an outsider is one of the toughest new roles in a company, even if you have a ton of experience.
Quick shameless plug: I'm co-founder of a venture-backed startup focused on helping people grow in their careers, such as yourself. My email is in my profile if you have any questions and I can be of help to you.
So, a few things I would think about would be:
[1] Who will you report to, and what is their management experience? How do their direct reports (likely other managers) view their management skills? Are they a teacher, or do they expect you to "pick things up" on your own? If they expect you to pick things up on your own, will they work with you and potentially pay for training classes or professional coaching?
[2] What is the structure of the team? Is it mostly senior members, or mostly junior members? What are their expectations of a new manager? Does the company typically promote from within, and you'll be an abnormal outsider?
[3] What are the expectations around the management responsibility, beyond day to day team issues? Will they be expecting you to hire new employees? Do you need to handle raises, promotions, and firing? Will you be expected to put together a budget every year?
All of the above is meant to help you to assess whether the role is going to be one that you can be successful in. Management is a great job, and I loved helping my teams grow in their careers; however, I think I would have floundered had I not had a great mentor who helped coach me specifically in these skills. I also think I would have struggled mightily had I jumped into a management role, without prior management experience, with a new team and a new company. Managing a team as an outsider is one of the toughest new roles in a company, even if you have a ton of experience.
Quick shameless plug: I'm co-founder of a venture-backed startup focused on helping people grow in their careers, such as yourself. My email is in my profile if you have any questions and I can be of help to you.
I read this book a few years back and enjoyed it, it’s good for understanding both sides of managing (up & down). The title is pretty flipping clickbaity but the book is pretty balanced, and I saw myself in some of the “tyrant” habits and it was helpful in an introspective way:
https://www.amazon.com/Tame-Your-Terrible-Office-Tyrant/dp/0...
https://www.amazon.com/Tame-Your-Terrible-Office-Tyrant/dp/0...
I've never hired for an engineering manager before, but it just popped up on our OKR this quarter. I think what I'd be interested in knowing about someone's management background:
- tell me about a time you had to let someone go. How did you deliver the news? How did the other person react? How did you communicate it to the engineering team and broader organization? Was there any fallout, and if so, how did you help people through the transition?
- tell me about a time you had to deal with layoffs. How did you communicate it to your team?
- tell me about a time you helped level an engineer up or multiplied their productivity. How did you give them feedback? What was the most difficult conversation you had with them? How did you help them reach the next level?
- tell me about your own progression from an IC to a manager. What was the most difficult feedback you've ever received from a teammate? How did you act on that? How did you react to the feedback?
- tell me about a time you had to say no to an engineer asking for a raise or promotion. How did they react? Did you setup a long term plan? Did they leave or stick around? What did you ask them to do?
- tell me about a time you had to let someone go. How did you deliver the news? How did the other person react? How did you communicate it to the engineering team and broader organization? Was there any fallout, and if so, how did you help people through the transition?
- tell me about a time you had to deal with layoffs. How did you communicate it to your team?
- tell me about a time you helped level an engineer up or multiplied their productivity. How did you give them feedback? What was the most difficult conversation you had with them? How did you help them reach the next level?
- tell me about your own progression from an IC to a manager. What was the most difficult feedback you've ever received from a teammate? How did you act on that? How did you react to the feedback?
- tell me about a time you had to say no to an engineer asking for a raise or promotion. How did they react? Did you setup a long term plan? Did they leave or stick around? What did you ask them to do?
These are all good for an experienced engineering manager, but keep in mind the OP was asking about having no management experience. I still think someone could take the questions and relate to their technical career in some form or another. If you can't you may want to question if you are ready for the new role!
Two things that I always advise new managers when I promote them or hire them.
First, (for new managers) managing people is a completely different skill set from engineering, expect to suck at it when you start and let go of your hard won pride that you developed becoming an awesome software engineer.
One of the "failure" modes of new managers is that they are so uncomfortable doing these new things, and so comfortable in the software engineering role that they find excuses to write code and do development which makes the team wonder why the 'boss' is trying to do their job, and it takes your eye off actual things you should be looking out for and fixing (like team mates getting conflicted, people who are having trouble but not asking for help, etc.)
Second, your success is entirely in your team's hands. It is their ability to do the work and make the deliverable and their production that shows you that you are doing a good job. This is so challenging for people who are used to being on the development team and measuring their success by comparing their "production" to that of the team. Now "they" haven't accomplished anything, but the folks writing code, they built all sorts of cool things to brag about.
So understanding that your success is tied to keeping your team understanding where they need to be, and knocking down any roadblocks in their way, is critical. It's also a different way of thinking for a lot of developers.
First, (for new managers) managing people is a completely different skill set from engineering, expect to suck at it when you start and let go of your hard won pride that you developed becoming an awesome software engineer.
One of the "failure" modes of new managers is that they are so uncomfortable doing these new things, and so comfortable in the software engineering role that they find excuses to write code and do development which makes the team wonder why the 'boss' is trying to do their job, and it takes your eye off actual things you should be looking out for and fixing (like team mates getting conflicted, people who are having trouble but not asking for help, etc.)
Second, your success is entirely in your team's hands. It is their ability to do the work and make the deliverable and their production that shows you that you are doing a good job. This is so challenging for people who are used to being on the development team and measuring their success by comparing their "production" to that of the team. Now "they" haven't accomplished anything, but the folks writing code, they built all sorts of cool things to brag about.
So understanding that your success is tied to keeping your team understanding where they need to be, and knocking down any roadblocks in their way, is critical. It's also a different way of thinking for a lot of developers.
This is all really good advice, and any manager candidates or new managers reading the thread should take this with them.
Remember also that while your job isn't to write code and that success is in your team's hands, it is your role to help that team be capable in order to achieve that success. I'm going to give you a lesson I learned in my first management role that I hope you'll take with you -
Deal with underperformance head-on, and do not avoid the tough conversations. I made the mistake of "seeing how things go" and giving wishy-washy performance feedback because I really wanted my team to like and enjoy working for me. In hindsight, you are doing no one any favors by not giving direct feedback on performance early and often. Don't just leave it on the negative, though, give them something to work toward and steps to take to improve, and then be hands-on in helping them with that development (without doing their work for them). Do not avoid this.
Remember also that while your job isn't to write code and that success is in your team's hands, it is your role to help that team be capable in order to achieve that success. I'm going to give you a lesson I learned in my first management role that I hope you'll take with you -
Deal with underperformance head-on, and do not avoid the tough conversations. I made the mistake of "seeing how things go" and giving wishy-washy performance feedback because I really wanted my team to like and enjoy working for me. In hindsight, you are doing no one any favors by not giving direct feedback on performance early and often. Don't just leave it on the negative, though, give them something to work toward and steps to take to improve, and then be hands-on in helping them with that development (without doing their work for them). Do not avoid this.
> Your success is entirely in your team's hands.
This isn't true. A lot of a manager's job is doing the little things that are necessary to get done. This may involve scrum master, project management, and even product management. Find the gaps and fill them!
This isn't true. A lot of a manager's job is doing the little things that are necessary to get done. This may involve scrum master, project management, and even product management. Find the gaps and fill them!
You are correct, but I think the original comment is more geared to the idea that you probably shouldn't revert back to what you are comfortable with and jump in and start coding when there are bugs, or tight deadlin s, etc.
I do think you should do some coding, even if you can only do it 10% of the time. It'll give you credibility with the team and you'll get to better understand what everyone deals with on a daily basis.
I do think you should do some coding, even if you can only do it 10% of the time. It'll give you credibility with the team and you'll get to better understand what everyone deals with on a daily basis.
You should be writing code, experimenting, attending technical reviews, but never put yourself in the critical path. Your job is no longer to deliver code, it is to lead the team or product.
Agreed
He just means "on balance, your success lies in your team's hands".
Yes, there's a lot of things a manager can do to screw the project up. But ultimately, it's the team that's actually doing the work. And ultimately, your job is not to "do the heavy lifting", or make all the key decisions, or figure everything out. They already know what to do. Your job is to enable them to succeed.
Yes, there's a lot of things a manager can do to screw the project up. But ultimately, it's the team that's actually doing the work. And ultimately, your job is not to "do the heavy lifting", or make all the key decisions, or figure everything out. They already know what to do. Your job is to enable them to succeed.
I agree that a lot of a manager's job may be tasks that are necessary to get things done, but I still don't see how your success isn't tied to your direct's/team's success? I understand that as a manager you may be given a stacked deck team wise, but even then I would imagine that you were put into that situation to be a change agent. If you weren't, well, that's someone sandbagging you and a different problem!
It was the entirely part that I disagreed with. Management isn't set it and forget it.
Agree that your success is tied to your team's success.
Agree that your success is tied to your team's success.
You're 100% correct. I had to learn these things the hard way.
I've been a technical manager for about a decade. Chuck's comments would have been incredibly helpful 10 years ago...
Everyone that is a new engineering manager or looking to take this role in the future should read through this comment. On point!
So what you need to know is that you are going to be joining a club - i.e the managers at the company.
You have to focus on fit more than anything else.
The first time you do it - its weird - very weird. All your previous ideas of work and work culture will be obfuscated. You'll realize that managers are a class onto their own.
To figure out fit, you mostly need to be able to read someone in about the first minute of meeting them. What do they value? What do they distrust? What will make them feel comfortable with you?
Older managers - probably want to know that you'll do what you're told, keep engineers in line and accept their management philosophy without question.
Newer age managers - you're very flexible and you'll take on a lot of work and you'll be part of the culture and that you worship at their altar - scrum, team velocities, standups and the rest of it.
Most important point: Do not criticize or point out large flaws in their system or process or thinking. (I've done this and have always lost out on the offer.) Focus on fit more that pointing out their errors.
At a low level like yours its probably best focus on showing that you've done a lot of thikning about the regular manager duties and to be as authentic as possible. This leaves to chance of whether they work in the same way but since its your fist time you probably don't have time to prepare anything else.
Welcome to the club!
You have to focus on fit more than anything else.
The first time you do it - its weird - very weird. All your previous ideas of work and work culture will be obfuscated. You'll realize that managers are a class onto their own.
To figure out fit, you mostly need to be able to read someone in about the first minute of meeting them. What do they value? What do they distrust? What will make them feel comfortable with you?
Older managers - probably want to know that you'll do what you're told, keep engineers in line and accept their management philosophy without question.
Newer age managers - you're very flexible and you'll take on a lot of work and you'll be part of the culture and that you worship at their altar - scrum, team velocities, standups and the rest of it.
Most important point: Do not criticize or point out large flaws in their system or process or thinking. (I've done this and have always lost out on the offer.) Focus on fit more that pointing out their errors.
At a low level like yours its probably best focus on showing that you've done a lot of thikning about the regular manager duties and to be as authentic as possible. This leaves to chance of whether they work in the same way but since its your fist time you probably don't have time to prepare anything else.
Welcome to the club!
In addition to what's already been discussed, you should also think about how to answer questions related to the hiring process. In today's competitive world hiring a great team consumes a huge amount of a manager's time and energy. Some questions to think about, how would you attract top talent? What's the interview process look like? How do you know an engineer will be a good hire? Things along those lines.
In the other comments people have spoken quite a bit about managing down in to the team, I'd also think about the project management and scope negotiation portion. As a partner to product management you're often called on to help shape what's possible long before ideas enter sprint planning or get turned into stories. Think about how you'd help negotiate scope when often the actual requirement has not been clarified.
In the other comments people have spoken quite a bit about managing down in to the team, I'd also think about the project management and scope negotiation portion. As a partner to product management you're often called on to help shape what's possible long before ideas enter sprint planning or get turned into stories. Think about how you'd help negotiate scope when often the actual requirement has not been clarified.
I did the same journey as you are about to embark on a year ago. It did not end well.
The job itself was titled "scrum master", but the description read more like a team lead/product manager role. I've done a little bit of both and was interested in exploring this career path and I jumped on.
The recruiting was not what I was used to. All in all I had 8 interviews over a course of 6 weeks. They focused heavily of my personality and I did a lot of self-assessments. No coding or case studies. When I reached the end of this I was so fatigued that I forgot to do the due diligence of my part, this turned out to be a BIG mistake.
- first and foremost, i inherited a team. If this is the case with you, MAKE SURE YOU CLICK. While I get along with most of my team on a person-to-person-basis in a team setting they've been working as six one-man teams for several years and Weren't interested in changing that.
- make sure you can tolerate the product you're building. If I had joined as a developer i would have quit within a week. This has an impact when you need to defend it/the team to the outside world. How much belief in the product can you fake?
- you will be alone. Your team won't be your friends anymore and neither will the managers above you.
Long story short, after almost burning out a second time in my life I resigned and am now looking for new work.
The job itself was titled "scrum master", but the description read more like a team lead/product manager role. I've done a little bit of both and was interested in exploring this career path and I jumped on.
The recruiting was not what I was used to. All in all I had 8 interviews over a course of 6 weeks. They focused heavily of my personality and I did a lot of self-assessments. No coding or case studies. When I reached the end of this I was so fatigued that I forgot to do the due diligence of my part, this turned out to be a BIG mistake.
- first and foremost, i inherited a team. If this is the case with you, MAKE SURE YOU CLICK. While I get along with most of my team on a person-to-person-basis in a team setting they've been working as six one-man teams for several years and Weren't interested in changing that.
- make sure you can tolerate the product you're building. If I had joined as a developer i would have quit within a week. This has an impact when you need to defend it/the team to the outside world. How much belief in the product can you fake?
- you will be alone. Your team won't be your friends anymore and neither will the managers above you.
Long story short, after almost burning out a second time in my life I resigned and am now looking for new work.
What was wrong with the product / team?
You didn't know what the product was when you started?
You didn't know what the product was when you started?
Without going into details, the product was started 10 years ago by one of the programmers whom I suspect wanted to be a game developer, so the product is filled with gamedev patterns and due to a tech choice it's not possible to migrate to a modern architecture without rewriting the whole thing.
Would be funny to see, say, an enterprise software filled with gamedev patterns. Would you care to elaborate on any of it? What kind of patterns were specifically glaring/out of place?
you're right, that does sound pretty funny. "the database backend was actually on the GPU - it was all in openGL, just in case. We were Mobile first, too - got 1 GFLops on iOS. Unfortunately we sold irrigation controllers for large farms."
You don't know how close you are...
I can imagine someone using component entity systems where they don't exactly make sense. I worked with a manager who considered using it, under a different name and not tied to game dev, in a very LOB application because he thought the requirements were changing too rapidly to manage in a traditional way.
Another possible artifact would be a custom memory allocator or patterns around memory or object management that make no sense in an application that isn't memory constrained or allocating large amounts of objects in such a way that is causing a bottleneck.
Maybe the programmer was unrolling loops in the name of maximizing performance where it wasn't actually required.
I am sure there are plenty of other signs a game dev hopeful would leave in a code base if left unchecked.
Another possible artifact would be a custom memory allocator or patterns around memory or object management that make no sense in an application that isn't memory constrained or allocating large amounts of objects in such a way that is causing a bottleneck.
Maybe the programmer was unrolling loops in the name of maximizing performance where it wasn't actually required.
I am sure there are plenty of other signs a game dev hopeful would leave in a code base if left unchecked.
One pattern is a high tolerance for "good enough" results or even wrong results, as such errors don't particularly matter in a game.
[deleted]
I applaud your willingness to take on engineering management. Having made the move myself about 4 years ago, it's an often unappreciated form of contributing but I find it highly rewarding. It seems that most new engineering managers seem to get promoted from within since it allows them to leverage the respect they've earned inside the organization as an engineer. In no particular order, here's a few recommendations.
- Think back to the managers you've had and think about what they did well and what didn't work as well. The more you can talk about and have an opinion about what makes a good manager, the more you can show your desire and ability to become a good manager. Before becoming a manager, I spent a year going through my career and really looking in depth at my previous managers so that when I started I could try to use that to be better myself. What I found is that this made me very good at managing down and I was very popular with my team, but managing up was somewhat of a problem. So when you look back at your history and your previous managers, be sure to look at not only how your managers interacted with you and your teammates but also how your managers interacted with their managers and the rest of the org. This can be harder to see, since you're not a part of those interactions, but if you think back, you might remember at least some part of that.
- The most important part of being a manager, from my experience, is being able to deliver feedback. The more effortless and clear you are, the more easily you can provide frequent and minor course corrections as well as provide natural encouragement of desired behavior. It also makes firing/disciplining employees easy. For one, if you're giving constant feedback, those instances are much less frequent since employees can make those course corrections. But when it does become necessary, it's not a surprise. Either there was some major incident or there's been a long build-up where suggestions/warnings have been repeatedly ignored. When I've interviewed other managers, I've looked for their ability to deliver feedback and, crucially, their abilities to notice the things they should be giving feedback about. Many managers, especially new managers, just don't have the awareness to constantly be looking for small course corrections or the feel for when an employee needs a bit of emotional buoying that can come with positive feedback. Hopefully in your mentorship and lead dev experience, you've developed some of that awareness, so the more you can talk about that, the more you'll show you're ready. As far as delivering feedback, there's a lot of theory on the right way to do that, but it also requires practice. Read up on that and then find a friend who's willing to help and role play a few different feedback scenarios. You'll quickly get better with practice.
- I'm going to expand your question beyond the interview because I think it will help you with your interview. Because if you get hired, that's not the end of it. It's not a case of showing that you can do the work, getting hired and then just organically becoming good at it. Once you get hired, that's when you need to start diving into the theory behind the discipline of engineering management. If you can internalize that, then you'll be able to convey to your potential employer at the interview your willingness to work to become better. Try to show your interviewer that you have a plan for learning how to be a great manager and the concrete steps you'll take to achieve that goal. Because if you have zero experience and they know that going into the interview, that's the most they can expect from you.
- Not every engineer actually enjoys management. Many engineers really like knowing all the little details and have a hard time stepping away from that level of knowledge and only knowing the larger building blocks. If you can talk about your excitement to work at that higher level and willingness to give up that lower level, you'll at least convince them that you really want the job. Make sure that this is actually true, because it's hard to fake. But if you can show that enthusiasm, you'll subtly make a better impression.
- Lastly, try to stress areas of being a manager that you're already good at. For instance, as a lead developer, you've probably interviewed a lot of engineers. If you're great at hiring/recruiting, it makes being a manager a lot easier. If you can show that you're able to bring great engineers into their organization, that alone makes you a great hire. Another thing you've probably done is write 360 reviews for other engineers. If you can find one that you're particularly proud of, remove all identifying information from it, print it out and bring it to your interview as an example of the kind of thinking you'll bring to their organization.
Best of luck in the interview!
- Think back to the managers you've had and think about what they did well and what didn't work as well. The more you can talk about and have an opinion about what makes a good manager, the more you can show your desire and ability to become a good manager. Before becoming a manager, I spent a year going through my career and really looking in depth at my previous managers so that when I started I could try to use that to be better myself. What I found is that this made me very good at managing down and I was very popular with my team, but managing up was somewhat of a problem. So when you look back at your history and your previous managers, be sure to look at not only how your managers interacted with you and your teammates but also how your managers interacted with their managers and the rest of the org. This can be harder to see, since you're not a part of those interactions, but if you think back, you might remember at least some part of that.
- The most important part of being a manager, from my experience, is being able to deliver feedback. The more effortless and clear you are, the more easily you can provide frequent and minor course corrections as well as provide natural encouragement of desired behavior. It also makes firing/disciplining employees easy. For one, if you're giving constant feedback, those instances are much less frequent since employees can make those course corrections. But when it does become necessary, it's not a surprise. Either there was some major incident or there's been a long build-up where suggestions/warnings have been repeatedly ignored. When I've interviewed other managers, I've looked for their ability to deliver feedback and, crucially, their abilities to notice the things they should be giving feedback about. Many managers, especially new managers, just don't have the awareness to constantly be looking for small course corrections or the feel for when an employee needs a bit of emotional buoying that can come with positive feedback. Hopefully in your mentorship and lead dev experience, you've developed some of that awareness, so the more you can talk about that, the more you'll show you're ready. As far as delivering feedback, there's a lot of theory on the right way to do that, but it also requires practice. Read up on that and then find a friend who's willing to help and role play a few different feedback scenarios. You'll quickly get better with practice.
- I'm going to expand your question beyond the interview because I think it will help you with your interview. Because if you get hired, that's not the end of it. It's not a case of showing that you can do the work, getting hired and then just organically becoming good at it. Once you get hired, that's when you need to start diving into the theory behind the discipline of engineering management. If you can internalize that, then you'll be able to convey to your potential employer at the interview your willingness to work to become better. Try to show your interviewer that you have a plan for learning how to be a great manager and the concrete steps you'll take to achieve that goal. Because if you have zero experience and they know that going into the interview, that's the most they can expect from you.
- Not every engineer actually enjoys management. Many engineers really like knowing all the little details and have a hard time stepping away from that level of knowledge and only knowing the larger building blocks. If you can talk about your excitement to work at that higher level and willingness to give up that lower level, you'll at least convince them that you really want the job. Make sure that this is actually true, because it's hard to fake. But if you can show that enthusiasm, you'll subtly make a better impression.
- Lastly, try to stress areas of being a manager that you're already good at. For instance, as a lead developer, you've probably interviewed a lot of engineers. If you're great at hiring/recruiting, it makes being a manager a lot easier. If you can show that you're able to bring great engineers into their organization, that alone makes you a great hire. Another thing you've probably done is write 360 reviews for other engineers. If you can find one that you're particularly proud of, remove all identifying information from it, print it out and bring it to your interview as an example of the kind of thinking you'll bring to their organization.
Best of luck in the interview!
There are some great suggestions already, however, it sounds like many comments are focusing on their experiences as a tech manager and not the interview preparation, which was your question.
I interview a lot of technical managers, and beyond technical chops, I focus mostly on communication skills, charisma, and personality.
I tend to ask a lot of behavioral/situational questions to understand how the candidate would handle different situations and how his personality lines up with the team. We are usually hoping for a thoughtful and genuine answer.
Additionally, I often schedule lunch with the candidate and the key players on the team, without the participation of the recruiting team, so they can speak freely.
You can prepare for some of the situational questions but keep in mind that it is totally ok to say "I don't know" or "I have not thought of that".
Best of luck!
I interview a lot of technical managers, and beyond technical chops, I focus mostly on communication skills, charisma, and personality.
I tend to ask a lot of behavioral/situational questions to understand how the candidate would handle different situations and how his personality lines up with the team. We are usually hoping for a thoughtful and genuine answer.
Additionally, I often schedule lunch with the candidate and the key players on the team, without the participation of the recruiting team, so they can speak freely.
You can prepare for some of the situational questions but keep in mind that it is totally ok to say "I don't know" or "I have not thought of that".
Best of luck!
What kinds of questions?
I don't know exactly what this company is looking for and how big a team you would be managing so it's hard to speak for them, however, an Engineering Manager is usually a pretty high level position and you should be expected to have a lot of experience under your belt in management, leadership and software engineering. The fact that you're never been in a management role even as a lead engineer (how is that possible?) means you're potentially unqualified for this position. I know that's hard to hear but I want you to come into this with the right expectations.
Having said that (and if you're still going to go for it), I'll try to give you some pointers.
1. Being a good engineering manager means having a good framework for getting things done. You probably have something like this already but as a manager, you have to be disciplined about keeping your team happy and productive, as well as knowing what everyone is working on at all times.
2. Be able to demonstrate how you think strategically and not just tactically (e.g. tactical: we're going to use MySQL because we have a hard schema, strategic: we're training engineers on the AWS tech stack because we have (or want) to move our organization in that direction for financial reasons).
3. Value "output over activity". Andy Grove's High Output Management is a godsend that explains this concept very well, but for the interview, demonstrate that you know the difference between people flapping their wings vs moving the needle forward.
4. Be able to speak about the difference between leadership vs management. Leadership is getting people to follow you while management is having people work for you. Management also means understanding the schedule, building a roadmap, and working with other groups to influence or lead important initiatives.
5. Helping ICs manage performance, motivate and incentivize good work, providing mentoring and guidance including career advice, rooting out low performers and managing them out. This is the hard, potentially unpleasant part of the job, and you'll need to demonstrate an understanding and willingness to do this (no one else will do this for you, this is the manager's job). Critical; since you don't seem to have experience here, you better brush up on this stuff most.
6. You job is also to understand current technology trends and be up to speed on the code, the process on the team, and the ways that things could be improved. Understand iterative process improvement and talk about how you've done this in the past.
There's lots more but this should hopefully cover the big important stuff.
All the best to you!
Having said that (and if you're still going to go for it), I'll try to give you some pointers.
1. Being a good engineering manager means having a good framework for getting things done. You probably have something like this already but as a manager, you have to be disciplined about keeping your team happy and productive, as well as knowing what everyone is working on at all times.
2. Be able to demonstrate how you think strategically and not just tactically (e.g. tactical: we're going to use MySQL because we have a hard schema, strategic: we're training engineers on the AWS tech stack because we have (or want) to move our organization in that direction for financial reasons).
3. Value "output over activity". Andy Grove's High Output Management is a godsend that explains this concept very well, but for the interview, demonstrate that you know the difference between people flapping their wings vs moving the needle forward.
4. Be able to speak about the difference between leadership vs management. Leadership is getting people to follow you while management is having people work for you. Management also means understanding the schedule, building a roadmap, and working with other groups to influence or lead important initiatives.
5. Helping ICs manage performance, motivate and incentivize good work, providing mentoring and guidance including career advice, rooting out low performers and managing them out. This is the hard, potentially unpleasant part of the job, and you'll need to demonstrate an understanding and willingness to do this (no one else will do this for you, this is the manager's job). Critical; since you don't seem to have experience here, you better brush up on this stuff most.
6. You job is also to understand current technology trends and be up to speed on the code, the process on the team, and the ways that things could be improved. Understand iterative process improvement and talk about how you've done this in the past.
There's lots more but this should hopefully cover the big important stuff.
All the best to you!
Three things I try to find out in a manager / director level interview :
1. What is the process for reviewing, committing, merging and deploying code ? How are technical designs vetted before starting development on large projects ?
2. What is the process for hiring engineers and reviewing performance ?
3. What is the process for describing, prioritizing, and ultimately building and releasing new features ?
Understanding those 3 things as they exist at the company (and your approach to each) will tell you a lot about the organization, how to proceed, and will tell the company a lot about what you are bringing to the table.
1. What is the process for reviewing, committing, merging and deploying code ? How are technical designs vetted before starting development on large projects ?
2. What is the process for hiring engineers and reviewing performance ?
3. What is the process for describing, prioritizing, and ultimately building and releasing new features ?
Understanding those 3 things as they exist at the company (and your approach to each) will tell you a lot about the organization, how to proceed, and will tell the company a lot about what you are bringing to the table.
Do know what a critical path means.
One thing that I've found difficult to do at times is to give your team space. Space to explore, try new things, do some things differently than you would do, make mistakes, etc.
You should always feel like you can overrule or supplement a decision, but you don't have to be the one to come up with every solution.
You should always feel like you can overrule or supplement a decision, but you don't have to be the one to come up with every solution.
Read this article. It'll show you the gaps between a Lead Engineer and a Manager. Focus on these gaps for your interview. Some people here seem to mix the difference between the two roles, you don't "manage" anyone as a tech lead, you do manage technical decisions though:
https://carouth.com/blog/2015/02/15/i-am-a-technical-lead/
https://carouth.com/blog/2015/02/15/i-am-a-technical-lead/
If you have to ask this question, maybe you shouldn't have applied for the position.
I recently interviewed a whole string of experienced engineering managers. My interview style tends to be pretty open ended. Most of the folks I interviewed were eager to talk about specific technical achievements they and their team accomplished.
This is understandable. Conquering and deploying a specific technology is hard and feels like a real achievement. That said, I found myself being more interested in each person's specific approach for determining what work to do, quantifying that work, and tracking it to completion. I had a surprisingly difficult time leading the conversation in that direction.
Specifically, I want to know how one interacts with product managers, prioritizes features, determines architecture, distills architecture to actual tasks, and guarantees that those tasks get completed in a timely fashion.
This is understandable. Conquering and deploying a specific technology is hard and feels like a real achievement. That said, I found myself being more interested in each person's specific approach for determining what work to do, quantifying that work, and tracking it to completion. I had a surprisingly difficult time leading the conversation in that direction.
Specifically, I want to know how one interacts with product managers, prioritizes features, determines architecture, distills architecture to actual tasks, and guarantees that those tasks get completed in a timely fashion.
For me a major disconnect here - and this is always the case with management - is that what management means differs greatly from one organization to the next. For instance, I would consider all of those: "how one interacts with product managers, prioritizes features, determines architecture, distills architecture to actual tasks, and guarantees that those tasks get completed in a timely fashion." senior engineering tasks, not engineering management tasks. Of course, line managers often are going to be also senior engineers who do senior engineer things part of the time, so these aren't inappropriate per se, but engineering management, to me, is more about people and organization management. Employee evaluation, hiring, empowering, professional growth, organizational growth, that kind of stuff as opposed to making product/project/engineering decisions, which should primarily be steered towards product management, project management, and/or senior engineers. With that said, at a lot of places - and I think this is what every organization drifts towards if you don't try hard to fight it - engineering managers are expected to manage projects and provide technical leadership, with people management responsibilities merely being used to give engineering managers the stick to perform their primary duties.
I have hired few dozen people during last decade just for my own projects so speaking from my own experience. I am listing some of the responsibilities that an engineering manager should have -
1. Facilitating your team to succeed.
2. Shielding your team from company politics and making sure they are getting the resources they need.
3. Know your team's strengths and weaknesses
4. Understand your project\product
5. Be a leader and not a manager. Leadership is just like any other skill which can be learned and developed
6. Share your vision with your team.
7. Understand that your team members are also humans and they have emotions too so do not try to come across as a cold person.
Good luck.
Reading list - https://sites.google.com/a/khanacademy.org/forge/for-develop...
1. Facilitating your team to succeed.
2. Shielding your team from company politics and making sure they are getting the resources they need.
3. Know your team's strengths and weaknesses
4. Understand your project\product
5. Be a leader and not a manager. Leadership is just like any other skill which can be learned and developed
6. Share your vision with your team.
7. Understand that your team members are also humans and they have emotions too so do not try to come across as a cold person.
Good luck.
Reading list - https://sites.google.com/a/khanacademy.org/forge/for-develop...
Just remember you are there to support your team always have their back and you'll do just fine...
More from a startup perspective, Graphistry started hiring here, so we've been thinking about it. We broke it down across several dimensions. Each is effectively a team multiplier. Hitting all of them makes you a unicorn who can do all forms of management... which is unrealistic. Instead, we've started looking to see if a candidate will help us cover the dimensions across multiple hires.
Roughly, we'd be looking for:
-- Technical: Will engineers trust you to help improve what they build and how? For example, can you architect across the stack and advocate best practices for code quality? Do you like leading from behind? As a startup, can you pitch in as needed?
-- Project management: Will you make development more predictable and productive? For example, as a feature moves from product design to implementation to production, will you help engineers technically spec, scope, decompose, tackle, & maintain features? Can you help with roadblocks, such as identifying risky parts, and making sure collaborations happen?
-- Product management bridge: Will you improve how product designers, sales engineers, and even early customers work with engineers, and vice-versa? Will you make sure infrastructure & operations are represented in engineering discussions?
-- Domain understanding: For engineers who lack experience with aspects of enterprise software and our customers' needs (security teams), will you help fill the gap? Will your visibility be a boon to the company?
-- Engineering management: Will you facilitate hiring? In what ways will you help engineers thrive & grow? Can you help with the ups & downs of rollercoaster startup life? Will you grow the company culture -- improve diversity, the daily environment, ...?
-- Junior developers: Will you help them integrate & grow?
-- Outside face: As a leader in a small company, can you assist with random customer-facing tasks like sales engineering and customer success? Recruit? Give tech talks?
-- Growth: As we go through the next doublings, how will you grow with us?
We look for awareness on most dimensions, and strong experience & interest on several. However, the form those take can be pretty varied.
... And if any of these sounds like you, please ping build@graphistry w/ a CV :)
Roughly, we'd be looking for:
-- Technical: Will engineers trust you to help improve what they build and how? For example, can you architect across the stack and advocate best practices for code quality? Do you like leading from behind? As a startup, can you pitch in as needed?
-- Project management: Will you make development more predictable and productive? For example, as a feature moves from product design to implementation to production, will you help engineers technically spec, scope, decompose, tackle, & maintain features? Can you help with roadblocks, such as identifying risky parts, and making sure collaborations happen?
-- Product management bridge: Will you improve how product designers, sales engineers, and even early customers work with engineers, and vice-versa? Will you make sure infrastructure & operations are represented in engineering discussions?
-- Domain understanding: For engineers who lack experience with aspects of enterprise software and our customers' needs (security teams), will you help fill the gap? Will your visibility be a boon to the company?
-- Engineering management: Will you facilitate hiring? In what ways will you help engineers thrive & grow? Can you help with the ups & downs of rollercoaster startup life? Will you grow the company culture -- improve diversity, the daily environment, ...?
-- Junior developers: Will you help them integrate & grow?
-- Outside face: As a leader in a small company, can you assist with random customer-facing tasks like sales engineering and customer success? Recruit? Give tech talks?
-- Growth: As we go through the next doublings, how will you grow with us?
We look for awareness on most dimensions, and strong experience & interest on several. However, the form those take can be pretty varied.
... And if any of these sounds like you, please ping build@graphistry w/ a CV :)
Never use the word "manager" again. Instead, prefer "leader". If you are somewhere where the team needs to be managed then there are better jobs out there.
Buy and read Jim Whitehurst book The Open Organization before your interview and actualize the information in that book. Recall times you put into practice the things that are mentioned in the book (good and bad).
Buy and read Jim Whitehurst book The Open Organization before your interview and actualize the information in that book. Recall times you put into practice the things that are mentioned in the book (good and bad).
I'd add slightly to this. Managers are one path in the leadership ladder. Management is organizational leadership the other is technical leadership. Technical leadership is the principal engineer, architect, or technical fellow at most companies. In most companies the lower parts of the ladder is shared as in technical or IC roles.
Surprisingly there is a large amount of leadership that is shared between both ladders. Group communication, group mentorship and coaching, group leadership is more or less the same. Teams are particularly weak if they don't have both technical and organizational leadership.
The technical leaders typically are focused on mentoring and growing engineers with architecture and technical guidance. Organizational leaders are focused on mentoring and growing engineers on their career path and a lot of the softer skills.
I agree 100% on the if a team needs to be managed, it needs to be changed. Teams will always need leaders to provide focus. And ideally they need both organizational and technical leadership. Rarely does that come in one package.
Surprisingly there is a large amount of leadership that is shared between both ladders. Group communication, group mentorship and coaching, group leadership is more or less the same. Teams are particularly weak if they don't have both technical and organizational leadership.
The technical leaders typically are focused on mentoring and growing engineers with architecture and technical guidance. Organizational leaders are focused on mentoring and growing engineers on their career path and a lot of the softer skills.
I agree 100% on the if a team needs to be managed, it needs to be changed. Teams will always need leaders to provide focus. And ideally they need both organizational and technical leadership. Rarely does that come in one package.
You can't self-proclaim yourself a leader, it's up to the team if they treat you as their leader or just a manager. I always chuckle when, in some companies, the higher-up managers call themselves "the leadership team". Yeah, they wish.
I'd like to thanks everyone who participated in this thread. Very good stuff. It looks like I'm gonna have to highlight my personality to make sure it's inline with an engineering manager role. Since it's the only thing I have on top of a strong tech background and mentorship. Interestingly, I also have a little bit of product management experience. But really it looks like it will be about my ability to make all my interviewers feel like home.
cheers!
cheers!
This role does not involve intense coding but requires a good high level understanding of technologies. It is focusing a lot on career growth, decision making, resource allocation and mentoring.
How could I make a good impression despite the lack of management experience? I did mentor engineers, etc. in the past. Happy to hear about things I should be expecting.