From the Other Side of the Table: Why Software Engineers Succeed or Stumble in Interviews
During my journey as a technology leader, I’ve conducted over 200 interviews for various roles, such as software engineers at different levels, engineering managers, project managers, and other roles. Most of those interviews were in giant tech companies Expedia Group and Amazon, specifically, and the rest were in startups and mid-sized companies. In this article, I will talk about hiring software engineers, and why you as a software engineer might pass (or fail) the interviews. This article will not teach you how to pass an interview. Instead, it highlights what interviewers usually focus on and the common reasons, based on my experience, candidates fail.
What does a hiring manager look for?
Although answers from hiring managers might differ, most of them require common qualities, such as: someone who has very good technical skills, delivers on time (or ahead of time), cultural fit, takes initiatives, can communicate effectively, accepts feedback, and helps their team members when needed. In addition to these qualities, one hiring manager told me that they look to hire someone who could lift the team up from a tech perspective. Others mentioned simplicity and positivity, and the list goes on.
The Interview Cycle
In a small company, the hiring manager might have 1–3 interviews that cover all of their requirements, which might not cover all of them in depth except for your technical skills due to the short interview cycle. Unlike tech giants, who might have their own leadership principles, you might have a phone screening, a tech assessment, and 4–6 interviews based on the level you’re interviewing for. This lengthy process allows each interviewer to test your understanding and thought process in 2–3 topics in depth.
The Quick Rejection
Quick rejection could happen during the first interview if the candidate fails to demonstrate an understanding of the job core competencies, such as computer science fundamentals or basic questions around the programming language you specialize in, most likely the interviewer will cut the interview, or, if they’re polite, they will just try to fill the interview time while they have already made their decision to not proceed further. For instance, I asked a mid-level software engineer candidate to explain SQL joins, write a simple query, describe how a Map and Set work, followed by writing a loop in reverse direction. When they failed to answer these basic questions, it won’t matter if they do wonderful in the subsequent interviews, it is obvious they don’t have the core foundation skills for this role.
The Poor Communicator
Many great software engineers get rejected because they struggle to articulate their ideas effectively. Although communication skills are key to software engineers, some companies and hiring managers might not find it a blocker for junior and mid-level engineers. Interviewers who show patience interviewing a poor communicator could be able to help the interviewee convey their ideas by showing empathy and rephrasing their questions. However, this is not always the case — the interviewer might not go the extra mile trying to understand your strengths. Of course, improving your communication skills requires a lot of practice, I recommend you practice and apply the STAR (Situation, Task, Action, Result) method, which should help you structure your responses.
Major Warning Signs
Red flags or strong no hire usually arise for behavioral issues, negative vibes and tending to complicate things, such as a candidate blaming their leadership or peers, provide excuses for not meeting deadlines and not believing in other’s skills. Beware of questions that probe you to talk about a project you didn’t deliver and what was the reason, feedback you received, what will you change in your current company if you could, do you prefer others to do code reviews for you or not. Always try to maintain a positive attitude, own your mistakes, and emphasize learning and growth, which should help you pass such interviews organically.
Overengineering
Building a solution for one problem is good, but simplifying it, shipping it to production earlier, and making it easy to understand by others is much better. Usually, hiring managers look to hire someone who’s pragmatic and gets things done. One of the good questions an interviewer once asked me is what will you use to build an application that runs daily on your laptop to get a specific stock price? Of course, you could use any technology to solve this problem, but a simple bash script with curl and echo commands could do the job effectively. Later on, I used this question in my interviews, and I got relatively complex solutions, such as writing a Java application with a Postgres DB. Try to keep your solutions simple by asking yourself about every task you’re planning to do: what happens if I don’t do it? Is it really needed, or it does it just make my solution look fancy? Is there any other simpler way I could follow?
It is Much More Beyond Technical Skills
If you excel in technical interviews, it doesn’t necessarily mean you are the ideal candidate in the hiring manager’s eyes. Hiring managers seek individuals who can and will get the job done, which entails having skills beyond tech, such as understanding the value and priority of what you are implementing, coming up with alternatives if the requirements are too complex, and balancing between engineering excellence with delivering results. Treating deadlines seriously is crucial; interviewers might ask you to provide an example when you had a project with a tight deadline. One of the worst answers you might provide is that you worked for 14 hours a day to meet the timelines, which isn’t a scalable approach, doesn’t show that you discuss the priorities with your business partners and come with alternatives.
Some candidates struggle to explain why they refactored or reduced technical debt in a specific project. I’ve heard answers such as “because it is the right thing to do”, “keep the code clean” and “follow best practices”. These answers neither justify the effort nor explain the attained value, therefore implies that the candidate doesn’t really understand why they are doing it. A good answer that shows understanding might be something like minimizing the tech debt reduced the effort to build a new feature from x to y days, reduced the number of ticket we receive by x or made the application extensible to expand the product to new marketplaces which wasn’t possible.
Common System Design Interviews Pitfalls
Probably, you have already created and implemented various system designs, and shipped them to production successfully. However, system design interviewers usually don’t focus on the perfect solution, they focus more on your approach to understand and discuss the requirements, consider edge cases, demonstrate a deep understanding of the used technologies, and understand the trade-offs for one solution over another.
In design interviews, sometimes I ask candidates to “design a single-page newsletter subscription form where users can enter their email address to subscribe to a newsletter”. The requirement is deliberately abstract, so I expect the candidate to clarify the requirements before rushing into a solution. For example, a candidate might ask questions such as how many subscribers do we expect, how often would users receive a newsletter and is newsletter triggered manually or scheduled. Some candidates fail as they just provide a solution without entirely understanding the ask.
If you manage to clarify both functional and non-functional requirements, the interviewer will look to ensure that you evaluate different solutions rather than coming up and sticking with a single one. For example, in terms of data storage, you could evaluate RDBMS vs NoSQL against the use cases you’re solving for, decide on which technology you’ll use, the trade-offs you’re taking. Some candidates might choose a technology because they’re familiar with it, even though it is not the best-fit for the problem they’re trying to solve. This mindset might raise a flag, that they aren’t willing to learn new technologies and their decisions are biased towards what they are comfortable with.
After presenting design alternatives, your design decision and highlighting trade-offs across different solutions, keep in mind that hiring managers might look to build a solution that adds minimal operational burden. Complicating the design by making it unnecessarily granular might raise concerns about overengineering and adding operational burden, which could be avoided.
