Avoid These 3 Bad Habits in Software Engineering Interviews
Key Behaviors to Watch Out for During Your Next Interview
Hey everyone, this is Eric. I write about frontend engineering and its career growth. Many people feel lost in frontend world and how to advance, and I hope this newsletter will be helpful for you.
I have my fair share of conducting technical interviews as a Senior Software Engineer. During these interviews, it’s my duty to assess if the candidate is technically capable and whether I can work with them based on our interaction. I prefer to treat these interviews not as exams but as pair programming sessions where the candidate drives the conversation.
I have seen many great candidates but also many with bad habits. Here, I would like to list the top 3 bad habits I see candidates display during interviews. By avoiding these, you can increase your chances of getting a “strong hire” recommendation.
I can’t do it
I don't think I can do this
I'm not good with math
Do you have another question you can ask me
These were actual questions candidates had asked me within the first 5 minutes of the interview. As an engineer, you should try to understand the question, use available tools to solve the problem, and approach it iteratively by breaking down the problem. It is unlikely that in real world scenario, you will see the same problem over and over again so one must learn how to solve problems when new challenges come to you. By not trying, you are essentially guaranteeing a “no hire.”
Most companies don’t require you to have the perfect, most optimized, extensible solutions on the first try. Start with a brute force or less optimized solution first then point out or refactor it at the end when you have time. If interviewers can follow your thinking process and understand what you are trying to achieve, you already have better odds than people that don’t try at all.
On a related note, don’t let your inner voice convince you that you can’t solve this question. Psychologically, you will end up believing you can’t. That’s not the mindset you want during an interview. Before the call, try to stay calm, be confident, and tell yourself that you can do this. When you feel more relaxed and positive, you perform better in both coding and interacting with the interviewer.
Not asking questions
Before solving any problem, whether during an interview or at work, it’s a bad sign if you start solving it without verifying details or asking any questions. System design rounds and sometimes coding questions are intentionally vague. For example, if asked to develop a social network feed, you might start defining components, choosing libraries, and laying out the UI. Then, 30 minutes later, the interviewer tells you that’s not what they wanted. While the interviewer should have guided you earlier, it’s your job as an engineer to think holistically about how the component would be used, any restrictions, CSR vs. SSR, infinite scroll vs. pagination, etc. All of these should be considered when building any app. By asking questions, you can often get a sense of what the interviewer wants to focus on, such as performance or accessibility.
Don’t have stories
On resumes, when I see detailed projects done in React, I often ask candidates what they think about React or their proudest project. I frequently get responses like:
In this Project A, I’ve used React and these libraries to build out this feature. It was great.
What was the context for the project? What was interesting? What was your role in this project? What was the outcome? What did you learn?
As an interviewer, such responses are not helpful. They don’t provide any useful information that signals you might be a good fit. While I could ask follow-up questions, not every interviewer will. If your initial response isn’t interesting, they might not continue digging.
For every project, try to have a one-minute and a three-minute version that covers what the project was for, your role, what you needed to do, and the outcome. Technical skills are important, but we also want to learn how you used those skills to solve problems.