Cracking the Engineering Manager Interview — FAQs
I’m very grateful to see the overwhelmingly positive response for the Cracking the Engineering Manager Interview series. Many people have reached out saying how this series has helped them prepare for and succeed in their EM interviews, which is a humbling experience for me. I’m happy to continue sharing back with the community on my learnings!
In this addendum post, I’d like to cover some common questions that I’ve seen come up in my discussions with folks who are preparing for EM interviews. I’ll also cover some failure modes and traps that I’ve seen people fall into when I’ve interviewed them. I hope this continues to be relevant and useful.
FAQs
How important are the technical interviews in the EM interview loop?
They’re pretty important. I’ve seen EM candidates being rejected (and experienced those rejections myself) when they didn’t do well on the technical rounds. Architecture rounds tend to be weighed more heavily than coding rounds with the bar for architecture rounds being similar to that of a senior or staff level engineer. The reason that’s the case is because while EMs may or may not be expected to code depending on the company, most tech companies want their EMs to be technical. Without that skill, it’s going to be hard to lead a team of technical people.
The relative importance of technical rounds over leadership or experience based rounds is company-specific though. In some companies a lukewarm performance in a technical round can be okay as long as you hit it out of the park on the other interviews. Whereas in other companies, technical rounds are considered table stakes. Ask your recruiter about these nuances and more often than not, they’ll be able to tell you the answer.
Do I need to practice Leetcode to crack the coding rounds?
Expect Leetcode medium level problems in EM interviews. Unless it’s for a niche role or in a company where they expect the EM to be an IC or a Tech Lead (can happen in smaller startups), you are unlikely to ever get a complex algorithmic question.
More often than not, you’ll be asked to implement business logic using standard data structures (hashmaps, arrays) or solve simple algorithmic problems (eg. tree traversal, sorting etc). Interviewers are trying to determine fairly elementary things such as,
- Do you think logically?
- Can you translate a problem into clean code?
- Can you read, understand, and debug code?
Forgetting the name of a function or not remembering the exact syntax is often okay, as interviewers understand that you’d be rusty having not written a lot of code recently. But what is not okay is logical flaws in your thought process, not knowing what code best practices are, or writing a lot of buggy / haphazard code.
What if I don’t have relevant experiences to answer situational or experience based questions?
You’re not alone. This happens a lot of times. Especially if you’re early in your EM career, it’s totally understandable to not have multiple examples from your work experience to answer an experience-related question. In those, I’d recommend being honest and telling the interviewer that you haven’t had that experience yet. You can then follow it up with a related experience and then share your philosophy around how you’d approach the situation if you would face that in the future.
What if I’ve never had to let go of someone from my team?
Have you ever had to let go of someone from your team is a common question asked in many EM interviews. If you don’t have this experience, that’s okay. You can’t manufacture a story around this :-). Similar to the previous discussion, your best course of action would be to tell the truth and share a related story. For instance, you could say something along the lines of I have not had the experience of letting go of someone, but I do have an experience of managing an under-performer who’s performance I was able to turn around.
As you share this story, focus on what you may have done differently, had the performance of this person you were supporting didn’t turn around. That way, you also give the interviewer an insight into your philosophy and what your hypothetical actions would be. While that’s not a full substitute to actual hard-earned experience, it’s the next best thing. At the end of the day, your hiring decision is determined by your complete performance across all interview rounds. Nobody can ace everything across all interviews.
How much detail should I go into when talking about a situation?
This is hard to master. My rule of thumb here is to follow these steps that we covered in the previous blog post:
- Share your philosophy / approach in 1–2 sentences
- List some examples that lead you to craft that philosophy / approach in 1–2 sentences
- Take an example and dive into it in detail for about 2 minutes — sharing enough context to get the interviewer on the same page as you, explaining the challenge, sharing specific actions that you took and the impact of those actions.
In addition, what’s useful is to know how much context your interviewers are already likely to possess. That way you can tune your answers accordingly. You can determine your interviewer’s context level by “following” them on LinkedIn before your interview. For instance, if the interviewer has worked in a similar domain like yours, you can go light on the domain related background context.
Another tactic you can use here is to check in with your interviewer to see if you were able to answer their question. That way you not only demonstrate empathy but also course correct your context along the way.
When asked about my weaknesses as a manager, what should I say?
Ah, the classic interview question where you’re expected to portray a strength as a weakness — “My weakness is that I take on too much work and get it done by pushing myself”, “My weakness is that I delegate too much and therefore run out of things to do.” Just kidding. Please don’t say these answers :)
When interviewers ask this question they’re trying to determine your self-awareness, growth mindset, and your drive. Everyone has weaknesses. Even the greatest of leaders are working on improving on their weaknesses.
A good way to answer this question is to pick a specific piece of constructive feedback you’ve received from your direct reports / peers / boss, along with the steps you are taking to action on that feedback. For instance, one of my weaknesses that I had conveyed in a past interview was — I need to get better at holding people accountable. I then followed up with why that was the case (I had a few examples along with feedback that my team had given me) and then followed it up with steps I’m taking to get better in this area.
How do I answer the question — what is your management philosophy?
Another classic EM interview question. While this may seem like a contrived question, it’s important to answer this with authenticity that represents what you value as a leader. Everyone has a management philosophy, even if they’ve never articulated it. To discover yours, think about why you became a manager, why you enjoy being one, what values you care about, and what values you’d like your team to espouse. Once you write these down, summarize the outcome in a few sentences — that’s your management philosophy.
The reason why interviewers ask this question is to identify misalignment between their company’s Engineering Management culture and yours. This question usually serves as a conversation starter with the interviewer diving deeper into how you came up with that philosophy to tease out potential misalignment.
You can game this question by making your management philosophy sound like the interviewing company’s values. But that defeats the purpose. If your values don’t align with the company’s, you’ll end up being miserable there.
What are some failure modes or traps to watch out for?
- Scripted answers that lack authenticity: It might be tempting to embellish your achievements but it’s really easy for interviewers to catch when you’re BS’ing. Honesty and integrity are aspects that most companies value in leaders. Unauthentic answers can hurt your cause rather than help it.
- Rambling too much or unstructured thoughts: If interviewers can’t follow your train of thought, they won’t be able to assess you fairly. Communication clarity is another aspect that most companies value. Besides, you might also run out of time and not be able to represent all your valuable experiences in this short interview time.
- Not asking clarification questions when needed or asking too many when not needed: Many situational questions are open ended. In those cases, it can be helpful to offer a few options and ask your interviewer which one they’d like you to dive deeper into. On the flip side, once you start sharing an example or an experience, it’s best to cover all the details so that your interviewer can understand the context and ask you any relevant follow up questions. If you ask your interviewer too many clarification questions without giving them the necessary context, the interviewer wouldn’t know what to follow up on.
- Not talking about what you specifically did as a manager in situational questions: There’s a fine line you’d need to balance here — if you say “I did this” or “I did that” without acknowledging the efforts of people around you, you sound narcissistic. On the flip side, if you say “we did this” or “we did that”, it’s not clear who “we” is — it may be perceived as someone else did the heavy lifting and you just came along for the ride. The best way to answer these situational questions is to explain clearly what you did and what others did. For eg. Engineer X did a great job of independently leading the project. However, they missed keeping the project stakeholders informed. I noticed that, provided Engineer X that feedback, and gave resources and process suggestions that they could use going forward.
- Repeating the same examples across multiple questions / interviews: This gives the interviewers an impression that you don’t have a lot of experience for the role you’re interviewing for. If you genuinely don’t, that’s okay. You can’t change that. But try as much as you can to mine your past background to uncover challenging situations that you went through and what you learned from them.
- Not answering the question being asked: Interviewers can easily spot when you are diverting the question. Sometimes the interviewer may try to redirect you back, but you can’t rely on that all the time. It’s important to answer the specific question being asked because most companies have a rubric that they’re measuring against.
- Not representing your most valuable experiences: This is the most common pitfall that I’ve seen people succumb to. You have very limited time in the interview to essentially show the interviewer why you’d be a great fit for the company/role. Don’t waste that time in sharing examples that aren’t impactful. Pick situations from your experiences that were high stakes, that really pushed and challenged you, and those that demonstrate how further along you are in your career. For eg. to answer a question about career development, an example about growing someone from a senior to a staff role is better to share than an example about growing someone from a junior to a senior role.
Do you have any other questions about preparing for an Engineering Manager interview? Leave a comment or hit me up on LinkedIn!
Thank you for your continued support and my best wishes for your next EM interview!
Have you read the other blog posts in the series?
