Coaching engineering managers for interviews
Google recently concluded a program where senior engineering manager candidates could get coaching before interviews, in order to help experienced people be as effective as possible during their interviews. My understanding is that they had systemic problems of engineering managers performing poorly on technical interviews, so the program was created to provide pointed feedback early in the cycle.
We’ll ignore what that may say about the interview process (where we provide “training” for candidates ahead of the interview), but the program is changing a bit now, and my role as a coach is ending. So, I wanted to reflect a bit on the experience, and distill some of the most effective insights I had from talking to a wide range of engineering managers over the past year.
I learned quite a bit about how other engineering managers work. There’s people that seemed fantastic mentors and leaders, and others who seemed to have fallen into it. The people I met—in general—were a bit less prepared than normal interviews, because we didn’t submit any feedback, and also far more relaxed. Additionally, I had the ability to be entirely candid to candidates about holes and areas to work on, so it was nearly always a pleasant experience for both of us.
None of this is secret or proprietary.
Technical interviews
At FAANG companies, engineering managers are expected to be technical. Day to day coding expectations depend on your ladder (do you lean more towards “tech lead” or “manager”?). Either way, you should fully understand what your team does, and be able to provide technical oversight.
This makes both the interview and job experience difficult for people who shifted to people management a while ago and didn’t remain technical. As a data point, my last VP (~800 indirect reports, very wide product area impact) has been playing with ML concepts for years on Github for fun. This is awesome, and isn’t all that unusual.
So, come prepared. I disagree with whiteboard-interview culture, but that’s what you’ll likely find for technical interviews.
Practice coding on a whiteboard. It’s a learnable skill, and doesn’t come naturally. Quickly you’ll pick up techniques to reduce having to cram lines between other ones. My (not-so) secret trick is to bring your own fine-tipped whiteboard markers. You’ll be prepared for the room having crappy markers.
Know your data structures and algorithms. In general, your interviews will not be as difficult or nit-picky as for non-people managers. People fully realize that your value isn’t based on knowing red-black trees. However, that can become a crutch for interviewers who don’t know how to assess soft skills. Being able to gut-check approaches (should this be linear? can we cache? is there an optimization?) is a useful skill. Cracking the Coding Interview remains the best resource. If you can reasonably approach the Difficult problems, you’ll have no issues.
System design is important, and where you’ll actually provide value. You may not be designing large systems yourself, but should be involved and be able to give a high-level perspective that engineers may miss. This can be difficult to study for in a vacuum, and should provide an opportunity for people with real-world experience to shine. Distributed computing is important for large companies. Know about consensus, CAP theorem, and well-known architecture approaches.
Some questions will be genuinely difficult, where the interviewer is trying to see how you solve problems with no immediately clear solution. Lean on first-principles and break problems down.
Other problems will just be checking that you know the basics of programming. This can feel insulting, and it’s a shame it’s needed sometimes. I coached multiple candidates who could barely write syntactically valid code in any language, who had 15+ year careers leading teams. At times, immediately easy problems will be augmented to become more complex. Stay engaged. There’s typically a reason the interviewer is asking this problem, and nearly always they think it’s interesting.
People management
There often are no right answers—but plenty of wrong answers—for people management interviews. The interviewer wants to see that you care about your team, can think long term about your team’s future, and can roll with changes. For more senior positions, strategy and balancing conflicting priorities becomes important. Be able to lean on your experience, and think ahead of time for difficult situations you’ve handled and decisions you’ve made.
A candidate once asked me “How aggressive should I be if engineers on my team aren’t doing what they’re supposed to?”. Your role isn’t to crack the whip on engineers, it’s to pair the unique abilities and aspirations of each engineer with opportunity, and do everything you can do enable them to succeed. You certainly will deal with performance issues, but it should always be a constructive process with a defined outcome.
You’ll be interviewed by other managers. A good strategy is to be someone that they’d want to work with as peers. Be friendly, but don’t worry about agreeing with everything they say. Independent thought is valued. Use the interview as an opportunity to use interpersonal skills. The best interviews don’t even feel like interviews; they’re closer to involved discussions about hard technical or interpersonal topics.
Overall, I loved the experience. It’s far more enjoyable to be able to directly help people than judging them, and I was able to meet some brilliant leaders. If you’re going through the engineering manager interview process soon (or are interested), feel free to reach out — I’d be happy to give direct advice for your situation.