The Mechanical Engineering Behavioral Interview
A recruiter at your dream company reaches out for a quick chat! How do you prepare? What can you expect?
We find the hardest behavioral interview questions are:
What motivates you?
What are your blind spots?
How do you resolve conflict?
This guide helps you answer these questions and develop a strategy
The Basics
On the surface, behavioral interviews are used to determine if you would function well within the company mission and values. As such, you should always peruse the “mission” and/or “values” page of a company before interviewing. Almost every interview, technical or not, will have at least one question pertaining to “why us?” If you can’t compellingly answer that question, it’s not in the company’s best interest to hire you, and honestly it’s not in your best interest to work there. At Hardware is Hard, we want you to go somewhere that you’re excited about, somewhere you get butterflies thinking about the interview. It’s a bit of a hot take, but nerves are a good thing! If you’re not nervous, you probably don’t care, and you deserve better than that.
Regardless, from the perspective of “getting the job,” though company values and mission are important, equally important, is who is interviewing you. Not everyone cares about the company mission and values, and to be honest, to be a good engineer, far more relevant, is how do you interact with others?
The Bottom Line
The key question that you need to answer for your interviewer by the end of the interview, is really: “Do I want to work with this person?” They may ask you a lot of other things, but it’s all to answer that singular question.
Here’s the part where the social engineer thrives. Believe it or not, going to that Wine Wednesday, or playing some Catan instead of studying an extra couple hours pays off here. Note that social skills don’t help your interviewer decide whether they want to work with you because they anticipate hanging out with you on the weekend or because they simply like you (though that may help, it tends not to have enough of an impact to overcome technical deficiency. Engineers are better about this than most other disciplines from what I’ve seen). It comes down to communication abilities.
People don’t want to work with someone who can’t communicate effectively. One thing most students realize when they get to college, is that being a good teacher has NOTHING to do with technical competence. Indeed, some would argue that it is in fact an inverse relationship. Having professors operating on the cutting edge of worldwide research who are incapable of succinctly answering a simple question seems to be a regular phenomenon. That can fly in academia somewhat, as options for finding someone specializing in cryogenic transmission electron microscopy using laser phase plate amplification for biological imaging is probably a somewhat limited pool. But as someone with less than 10 years of work experience/specialization, you are replaceable, and as such, being able to communicate effectively is important.
Preparation
If you’re concerned about being appropriately affable in such a stressful and dynamic environment, a healthy amount of reconnaissance can help you prepare for this. It’s not something I freely admit, but I usually spend a nontrivial amount of energy before an interview finding out what I can about the person interviewing me. You aren’t always given the information for who is conducting the interview, but a first name and a team at the company is usually all it takes. Where did they work previously? How long? What school? This can help you ask particularly poignant questions and show you where you should focus your technical preparations.
Lastly, if you receive a “Tell me about a time…” category of question, know that your goal is to answer with a true & compelling story. Even if you were a complete badass and completed the most epic project in existence, if you aren’t able to tell your story effectively, then no one else will care. Sculpting a story properly can be quite difficult, but the general interview advice out there is “C.A.R.” (context, action, result) or “S.T.A.R” (situation, task, action, result) or any other number of acronyms. What it boils down to is, tell what was the project/why did it exist, what did you do, and what result did it drive? The ability to engage an audience while telling a story will also pay dividends every time you meet someone new, so practice!
Now that we have general advice for behavioral interviews done, here are a few of the more difficult-to-answer questions we’ve received/seen over the years and some strategies for how to answer.
For more practice, check out our Interview Question Database with over 150 questions!
What motivates you?
I refuse to tell you the best answer because there isn’t one. My motivations are particular to me just as yours are hopefully particular to you. That said, there are answers that your interviewer may find more appealing than others. My love of skiing or backpacking, while perhaps gaining the possibility of a slight bonding moment, probably has nothing to do with the job. But, if this is a clean energy or conservation company, something broader like passion for preserving the natural world so my progeny can participate in the activities I like to would make more sense.
My biggest tip, is to always put yourself in your interviewer’s shoes. Think as though you are the company looking at a candidate (yourself) from the outside. Why ask this specific question?
I have found that this question gets asked to make sure that the company and role can supplement whatever motivates you. If your passion is getting lost in the sauce and digging deep into research, a system engineering role wouldn’t serve anyone. If hands-on-hardware motivates you, then a multi-year architecture-level research project probably wouldn’t be a good fit. How does what motivates YOU match with what the company is offering? Thinking about it, you may also come to the conclusion that this isn’t the type of role you want! Then again, personally, I think internships are so much fun because there are few negative consequences in trying something completely new for a few months, even if it’s not what you thought you wanted.
Be prepared for follow-ups based on your past experience. If your past roles are all more architectural product development, and you’re interviewing for a detailed module-level design role, hopefully, there’s a reason why. Be honest, and don’t be afraid to take a few seconds to think before answering!
What are your blind spots?
This is a really tough one, and akin to the dreaded (but also uncommon, at least in engineering interviews) “what’s your biggest weakness?” It is exceptionally easy to get caught off guard and phrase something in a way you’ll regret.
Think through it, what are your weaknesses? What are the concrete action items you can use to improve them? The key here is not to just list weaknesses, but what you can/are doing about them.
What the interviewer is looking for: Do they know how to navigate resources? Do they have the ability to fix things quickly?
There are two categories here, you can either go the technical or the personal route. Feel free to ask the interviewer to clarify whether they mean technically or personally to avoid any misinterpretations (if you do so, prepare for the answer to probably be “both”).
Technical blind spots are actually the easier of the two. Think of an area where you don’t have a lot of experience that you would like to get better at. If you haven’t done very many simulations, say that’s a bit of a blind spot for you and that you’re taking on a simulation project in your engineering competition team to learn more about the area. Ideally, provide details such as some things you’ve struggled with in your quest to get better. Note: do not say simulations is your technical blind spot if you are interviewing for a simulation-intensive role.
Personal blind spots can be difficult for us to identify as they are, as the name would suggest, in our blind spot. Let’s put ourselves in the interviewer’s position. Why ask this sort of question? Not only does it test your ability to be vulnerable/honest, but it establishes a certain level of self-awareness. Everyone has things they would like to get better at, and that’s okay!
One of my blind spots is that if I get fixated on finishing something, I tend to get tunnel vision. I lose sight of how important it is to the overall project, whether there might be a better way to do it, and whether the ROI on my time is worth it (work smarter not harder). That is NOT how I would phrase it in an interview though. I would say that when I feel passionate about what I’m doing, I’ll do whatever it takes to get there, and sometimes forget to reevaluate if that’s the target I should be heading for. To combat this, I’ve been trying to put an item on the schedule every few weeks with key stakeholders to review the project as it relates directly to the requirements/needs and make sure those requirements are sufficient/necessary in the first place.
How do you resolve conflict?
Let’s say you are presenting a path forward and a senior engineer disagrees with your conclusion. What do you do?
There are 5 things that the optimal answer to this question touches upon:
Give context to my hypothetical design
Understand why the senior engineer objects
Constraints are clear and communicated
Data/analysis to drive decisions
Escalate if short timeline