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

[throwmeplease]

I have 10 years of experience as a software engineer with various roles as a lead engineer. I have never managed anyone directly - nor hired/fired anyone. I recently applied for a manager role at a great company (not a big-5). To my surprise, they're interested in my profile and would like to start the interview process. My goal is to grow in those areas and gain a new set of skills.

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.

[ChuckMcM]

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.

[sokoloff]

I've been a technical manager for about a decade. Chuck's comments would have been incredibly helpful 10 years ago...

[SmellTheGlove]

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.

[johnbellone]

Everyone that is a new engineering manager or looking to take this role in the future should read through this comment. On point!

[ec109685]

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

[lsadam0]

You're 100% correct. I had to learn these things the hard way.

[rootforce]

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.

[johnbellone]

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.

[fastbeef]

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.

[Danihan]

What was wrong with the product / team?

You didn't know what the product was when you started?

[Osmose]

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.

[sadadar]

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

[throwitzawayz]

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!

[jmtame]

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?

[johnbellone]

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!

[lmeyerov]

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 :)

[thrw0039]

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!

[xangold]

What kinds of questions?

[pdevine]

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.

[halbritt]

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.

[candybar]

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.

[lmcnish14]

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

[romanhn]

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.

[thinbeige]

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.

[ryandrake]

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.

[efm]

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.

[Negative1]

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!

[johnbro]

Being non-native english speaker, could you explain to me what does the IC abbreviation mean? (I've seen it mentioned in your post as well in several others; and google didn't help). Thanks

[charlax]

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!

[awinder]

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

[ugh123]

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.

[nogbit]

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

[mtippett]

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.

[taway_1212]

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.

[mandeepj]

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