Ask HN: How to prepare for an Engineering Manager interview?

Read The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

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.

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.

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.

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.

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.

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.

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

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.

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.

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...

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?

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.

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!

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.

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.

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 hi...

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!

Think about how to express when and how you would prioritize the needs of the business over the needs of the engineers.

Demonstrate your grasp of cost optimization.

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!

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.

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.

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/