Demystifying the behavioral interview: Part 2 - Under the hood
Welcome to the second part of our series on demystifying the behavioral interview. Previously, we examined the importance of cultural fit in tech companies and the necessary groundwork to prepare for the behavioral interview. In this post we are taking a deep dive into the most common questions I have encountered as an interviewee and asked as an interviewer; we will expose the intent of each question and see how to answer them.
Let’s jump right in!
How do you keep up to date with your field?
This is a pretty standard question and it’s typically used as a warm-up or ice-breaker to make you feel more comfortable. Enumerate prominent blogs, articles, newsletters, podcasts, books, and even conferences.
Your response illustrates your preparation and deliberation. Moreover, it's an opportunity to show your enthusiasm. If you are following up on a specific topic, mention where you got the inspiration from, why you are engaged, how it helps you improve, and what outcomes you strive for.
A word of caution: be honest and focus on the information you actually consume; your interviewer probably knows these sources and could inquire about specifics. I was asked in an interview to share my thoughts on a specific section from the Kotlin Weekly newsletter that my interviewer had strong opinions on.
If you want to know my recommendations on keeping up with Android and Kotlin, keep checking my blog; I plan on posting a little something in the future.
Why are you looking to change your position?
This question is crucial and calls for scrutiny. A recruiter probably asked you already, but the hiring manager or engineering manager might repeat it in order to assess your attitude, work ethic, and team fit. Overall, the interviewer is trying to get a sense of whether the new position is a good fit for you, both in terms of your skills and experience and in terms of your long-term career goals.
No matter the grievances against your current company, manager, team, or colleagues in your current/former job, you should not condemn any of them; blaming is a red flag. Instead, you can list what is missing and highlight what is important to you. For example:
- Career growth and development
- A challenging project
- Opportunities to coach and mentor others
- Recognition (promotion, salary, etc.)
In Part 1 I talked about showing genuine interest. If you did your homework, appeal to the new job’s potential. “I want to work here because you offer XYZ that my current role is lacking”.
My reasoning went something like this: I started interviewing because I felt that my career stalled and my contributions were ineffective. I applied to positions that offered the opportunity to improve users' lives and positively impact the growth and profitability of the business. In addition, I wanted to showcase my technical skills and grow into a leadership role.
What are your biggest strengths/weaknesses as an engineer?
Your interviewer can ask you about your biggest strengths or weaknesses. The answer to each question is different, but the strategy for approaching them is the same. You are expected to show self-awareness, feedback culture, and how you capitalize on your strengths or compensate for and improve your weaknesses. If you can mention, qualitative or quantitative data, or how you measure your improvement and impact; you will further impress your interviewer.
This is neither the time to brag nor to be humble; pragmatism is what we are looking for. Trying to turn a weakness into a strength won’t cut it either. Something like “I’m a perfectionist and always deliver the best quality code” is a poor answer. One could turn this around and allege that you fail to understand business-critical timelines and miss deliverables because you only focus on the quality of the code.
Talk about the things you have in your favor that your colleagues have praised. Give examples of how your "assets" help your team and company. Similarly, mention constructive feedback you received, how you handled it, and what you did to improve. Showing that you followed up on feedback and ensured that you covered your blind spots is a very attractive quality.
What would you say is your biggest achievement/mistake in your career so far? Why?
Your interviewer is interested in your analytical skills, your aspirations, and potentially how product/business minded you are as an engineer. Like the preceding question, you can use the same strategy when talking about an achievement or a blunder.
Your approach should be to describe:
- The situation, the context
- The hardships you have faced
- Which decisions you took and why
- How you measured your success/failure
- The impact, positive or negative, this had on you or the team/product/users/business
I urge you to minimize the emotional talk and the assignment of credit or blame. What happened happened, what we care about is how you think of it, what you are learning from it, and how it’s useful to your prospective team and manager.
Please describe a situation when you disagreed with your team.
This is one more frequently asked question and the intent is to assess if you are a good fit for the team. It’s not possible for everyone on the team to constantly agree on all the topics. Situations will arise when there will be disagreements, sometimes on irrelevant issues and sometimes on business-critical issues. What the interviewers want to know is if you will be a team player and if your attitude will hurt or benefit the team and the business as a whole.
My approach to answering this question is to explain the situation as objectively as possible, even if it means that I will portray myself poorly. If I was at fault, I will admit it. I will also talk about the context, why I was thinking/behaving the way I was, and how I managed to get out of that situation. Did I escalate or de-escalate the situation? Did I negotiate with my teammates or did we continue with a “disagree and commit” solution?
I implore you not to talk badly about your team; you were all in a difficult situation and probably under pressure, so assigning blame to others and trying to make yourself look like the hero is probably a red flag for your hiring manager.
Why should we…? (e.g. use Agile?)
I’d like to conclude with a “trick” question. Let’s assume your interviewer asks “why should cross-functional teams use agile”, or, “why is waterfall bad”. What would you reply?
Try to take a moment and reflect on the underlying assumptions. Maybe your interviewer is expecting you to challenge them instead of pleasing them with a gratifying answer. It’s quite common for situations like these to arise in our day-to-day work, so it’s a critical skill to pause and explore alternatives (given time constraints) and ensure that everyone is aligned. If, for example, you are presented with an impossible deadline to deliver a feature, you should challenge hypotheses and scrutinize the possibilities you are presented with. Can the deadline be pushed back? Can the scope of the feature be reduced? Can we agree to push something fast and dirty to production and take the time to properly fix and scale later?
Use your judgment and answer based on your experience and convictions. Make it a discussion if possible; you are allowed to ask questions to your interviewers.
For the younger and/or more junior engineers out there who don’t have much working experience under their belt and have yet to face the situations I mention above, your strategy should be honesty and preparedness. It's OK to lack knowledge and experience. Take control of the situation and direct the discussion to something similar and familiar to you; it's superior to replying "I don't know".
Let’s say you don’t have an example of critical feedback you received from your workspace; you can mention this to your interviewer and try to offer a situation that might be close enough, or answer a similar question. For example, “I’m not sure I can answer this question directly, since I just graduated and have yet to have feedback sessions in a professional environment. I did, however, play sports and used to have 1:1 sessions with my coach, would you like me to talk about that instead?”
And this wraps up Part 2 of the series! Thank you for your attention and see you in Part 3 where we investigate the cultural fit components in the coding interview.
For more details, you can watch my talk at DevFest Greece & Cyprus 2022.
Other posts in the series: