One of the mistakes that unseasoned engineering managers make during their interviews is that they over-index on their technical abilities. Therefore, they tend to not think too much when answering leadership, team management and project management questions and gave high-level and generalised answers.<\/p>\n
When you only have 60 to 90 minutes to showcase your skills and experience as an engineering manager, you need to be very strategic in how you want to present yourself and your capabilities to a prospective employer. Often, this is about what you don\u2019t do or don\u2019t say, instead of what you do say.<\/p>\n
I have interviewed more than 100 candidates in the past year alone, and I have seen my fair share of bad interviews. Bad interviews are the ones where the candidate knows immediately that they didn\u2019t do well and the interviewer also knows it. In fact, there\u2019s nothing special about it. What\u2019s interesting is when the interview itself wasn\u2019t too bad, but the interviewer was reluctant to put the candidate forward due to one or two things that the interviewee said. Interviewers usually refer to them as yellow or red flags. When a candidate had such flags, even if they passed other questions with flying colours, interviewers had reservations about putting the interviewees forward and hiring them.<\/p>\n
Without any further ado, I\u2019ll share with you 10 worst answers that you should not give when interviewing for an engineering manager role.<\/p>\n
\u201cSome people are just incompetent and they cannot be helped.\u201d<\/p>\n
The reality of working on a team is that you are working with those who are better than others and those who are not as good as others. What the interviewer would like to understand here is how you tried to help a low performer on your team. As an engineering manager, it\u2019s your responsibility to ensure you enable each and every one of your team member to do their best. It\u2019s not the time to make an ignorant comment. The statement makes it seem like you\u2019ve just dismissed somebody without giving them a second chance.<\/p>\n
\u201cI only ever give positive feedback. I don\u2019t like to make people feel uncomfortable. I\u2019m a good manager.\u201d
\nConstructive feedback does not just mean negative feedback. The University of Tasmania has a very good definition of what constructive feedback is:<\/p>\n
\u201cConstructive feedback is providing useful comments and suggestions that contribute to a positive outcome, a better process or improved behaviours. It provides encouragement, support, corrective measures and direction to the person receiving it. Knowing how to give constructive feedback is a valuable skill.
\nConstructive feedback can be positive (letting someone know they\u2019re doing well), negative (letting people know about ways in which things could be improved), or neutral (just an objective observation).\u201d
\nConstructive feedback is a gift because it\u2019s given with the intent to direct you towards a positive outcome. Those who provide constructive feedback are those who are real leaders because they have the best interest of others in mind and the willingness to elevate others for success \u2014 even if the process of giving such feedback can be uncomfortable.<\/p>\n
\u201cI don\u2019t really have time to learn new things. I am too busy attending meetings.\u201d
\nLearning new skills is a part of the job in today\u2019s business environment. Gone are the days when you didn\u2019t need to learn new skills because you had been working in the industry and performing a similar job for a few years. While having to attend too many meetings is not uncommon for an engineering manager, it\u2019s not an excuse for them to not be learning. Instead, as an interviewee, you could provide a more thoughtful answer on your learning style:<\/p>\n
\u201cFunnily enough, I can\u2019t remember the last time I did something wrong.\u201d<\/p>\n
As an interviewer, I\u2019d say \u201cOK\u201d and move on. However, in my interview notes, there would be something about a lack of self-reflection.<\/p>\n
\u201cI escalate it to my manager and let them handle it. I don\u2019t like to get involved in conflicts.\u201d<\/p>\n
The problem with this answer is not the fact that you\u2019re involving your manager. Getting a third person\u2019s opinion, whether it\u2019s your manager or not, can be a good thing to do in resolving conflict. The real problem with the answer is that there is a lack of ownership here and perhaps a lack of care for your own craft. We\u2019re in the 21st century, and employers do not want people who just do what they\u2019re told. They want employees who are passionate about what they do, and as a result, they\u2019re willing to resolve conflicts head-on.<\/p>\n
\u201cI don\u2019t think we should ever have deadlines. Good software development is a craft. Development work will take as long as they need and software will be ready whenever dev work is finished.\u201d<\/p>\n
Yes, it\u2019s true. I fell out of my chair when I heard this in person. When you\u2019re asked about deadlines, my advice is to broaden your perspective and understand how your work relates back to the company\u2019s goals.<\/p>\n
\u201cI am an extrovert, a people-person. I like working with people.\u201d<\/p>\n
What does that even mean? If every extrovert becomes a manager because they liked working with people, half of the world\u2019s population will be managers. The first official random sample by the Myers-Briggs organization showed introverts made up 50.7% and extroverts 49.3% of the United States general population.
\nInstead, try to think about the underlying reason why you became a manager, what lights you up in your role as an engineering manager and what keeps you going when things are not all rosy at work. Your answer will likely be different to another engineering manager\u2019s answer but that is what makes a good specific answer.<\/p>\n
\u201cI hate processes.\"<\/p>\n
In my article, Four Things I Wish I Knew as the New CTO of a Startup, I wrote that not all processes are evil. It\u2019s true. More than a decade ago, as a young and novice CTO, run an engineering department at a startup with no formal process for a year. Not having any kind of process meant it was hard for us to know if we were working efficiently. A lot of tasks couldn\u2019t be shared because there is no way for a different person to know how to even begin doing something. Documentation was non-existent. I was lucky that there was no staff turnover in the year that I was there. Otherwise, handover and onboarding new people would be quite expensive, not to mention chaotic. Another problem with not having any kind of process is that I felt like I was a gatekeeper for many things. I couldn\u2019t scale myself.<\/p>\n
So before you dismiss a process-related question, share an example or two about how a process has helped or hindered you in being an effective engineering manager.<\/p>\n
\u201cI am leaving my current company because they are not paying me enough.\u201d<\/p>\n
This may be true, but without any other supporting information, it makes you look like someone who just cares about the money.<\/p>\n