Top 5 technical interview pitfalls
Why do smart candidates fail interviews? The reasons may surprise you.
You’ve studied your share of computer science algorithms/statistics/machine learning/system design for the on-site interview at your favorite tech company. You thought you answered the questions as best as you could. So why didn’t you get the job offer?
At Insight, we interview thousands of applicants to our programs each year, where we look for a sound technical base and good communication skills. Once Fellows are admitted to our program, we help them ace their technical interviews with companies to land dream jobs in tech fields such as Data Science, Data Engineering, and DevOps. From both sides of the process, here are the most common errors we see otherwise brilliant candidates commit:
1. Diving in to solve the problem immediately.
This is an extremely common failure mode. Whether it’s a case study, a DevOps systems debugging scenario, or whiteboard coding problem, your first action should not be solving the problem!
Here’s why: the interviewer is looking for your ability to communicate and work with others, in addition to your technical skills. They don’t want someone who rushes into action without fully understanding what they have to do first. Often, interviewers withhold complete information on the problem for this exact reason: to see whether you’ll start writing code then get stuck, or ask for the full picture at the start.
It’s good practice to echo the question back at the interviewer in your own words to make sure you’re on the same page. For coding algorithms problems, you should ask for examples and edge cases to cement your understanding of what they want. For case studies, you should ask for more details about the parameters of the problem; it should be a full conversation between you and the interviewer. For systems debugging, you should ask about the team structure, how to assess the severity of the problem, and which team the problem would potentially be escalated to — DevOps teams want engineers who will act according to proper procedure in a thoughtful manner.
2. Working silently.
Most people don’t talk out loud when they’re coding, but you must for your interview!
Interviews are a way for a prospective employer to evaluate you as a complete candidate in a very short amount of time, both technically and behaviorally. They don’t know what and how you’re thinking if you just stand in front of the whiteboard. Actively communicating with the interviewer also buys you time to think and can give you hints you need to solve the problem, so it’s a win-win all around. Here’s an example workflow that works well for coding interviews that you can modify for other types of interviews:
“So, if I understand you correctly, you want me to solve [repeat the problem]. Is this correct?
“To start, I will write pseudocode to lay out my basic logic, and then I will add in language-specific syntax and consider edge cases and unit testing when I’m done. Is that acceptable?
“I’ve coded the brute force approach, with time complexity O(N²), but I can see that this is quite slow and likely not optimal. Do you agree? I will now try a different algorithm here to see if I can improve the efficiency…”
Of course, you won’t be using these exact words because your real interview will be an organic conversation, not scripted — this is just an example for you to get an idea of how much interaction is appropriate.
The best way to improve is to do many mock interviews with your peers and mentors, get specific feedback on how to improve, and then practice, practice, and practice more. Talk out loud as you solve LeetCode problems and design machine learning models by yourself — it may feel strange, but it really helps.
3. Not validating your answers.
Some interviewees arrive at an answer and say they’re done. Nothing more to do. That’s another big no-no. Just as important as the answer itself is validation of the answer: how do you know you’re right?
For coding questions, this means writing test cases, which can range from actual unit tests in a live coding scenario or testing edge cases on the whiteboard. For data challenges, it’s important to do some statistical tests to validate your answer — if you find there are negative salaries in your employee data sample, there’s a problem! At the very least, you should be checking with the interviewer if you’ve answered the question satisfactorily — remember that it should be a conversation, not a silent exam. Interviewers want you to succeed, or they wouldn’t have invited you in the first place.
4. “I don’t know.”
I don’t know is never a good answer, because the conversation ends right then and there. So what do you do when you’re genuinely stumped? Instead of I don’t know, try the following approaches, ordered by how much of a clue you have:
- “I’m not 100% sure, but this reminds me of [something you do know]. Am I on the right track?”
- “I can see that my code is not optimal. Could it be because I’m using the wrong data structure?”
- “I don’t know that algorithm, sorry. Can you describe what it does?”
- “Honestly, I’m drawing a complete blank. Are there any hints or pointers you can give me?”
Notice that even the last one is better than I don’t know, because it’s still interacting with the interviewer. It shows that if you were to work on a team, you would ask people for help when you need it, not just sit in front of your computer and inefficiently look for solutions that other people already have.
5. Failing behavioral elements.
Technical interviews are not just a test of how well you know some formula or algorithm. Many interviewers will ask so-called “soft” questions: How long have you worked in this language? What are previous projects you’ve done in this language? How did you debug in this language? It’s a way to see if you’re able to handle different situations and go with the flow, rather than freezing on the spot.
In addition, many interviewers will try to push you a little. This isn’t optimal. Something is wrong here, do you know what it is? Again, they’re not necessarily looking for someone who can solve the problem, though that is of course good. More importantly, they’re looking for what happens when you’re pressed in a stressful situation. Do you act defensively or melt down? These are red flags that can end your chances. Remember to stay respectful and assertive, and use strategies in point 4 if you’re not sure — never insinuate or accuse the interviewer of being wrong. If you think you’re right and can’t see anything wrong with your answer, say so politely and ask for feedback.
Behavioral elements are not only evaluated during the interview. Here are some factors companies consider before and after the interview:
- Did you schedule the interview in a responsive and respectful manner?
- Did you treat each person of the company well, including non-technical, non-management staff?
- Did you arrive to the interview on time, with appropriate attire?
- Did you seem enthusiastic about the company, and not just treat it as one of a very long list?
- Did you send a thank-you note after?
None of these things are necessarily deal-breakers on their own if you don’t do them well. But if multiple areas are deficient, this can take an otherwise technically brilliant candidate out of the running. On the flip side, even if you don’t solve all the problems at your interview, you can still get the job if you communicate well with your interviewer and exhibit enthusiasm and respect. In short, be someone that anyone would want on their team, including yourself — if you won’t hire yourself, then who will?
Want more help?
A lot of the above pitfalls are not easy to evaluate in a vacuum by yourself. If you’re trying to transitioning into careers such as Data Science, Data Engineering, Artificial Intelligence, and DevOps Engineering, but don’t have a good way of getting feedback for your interview skills, consider Insight! We’re a seven-week, full-time, tuition-free program based in the U.S. and Canada that will empower you all the skills you need, with high-impact projects and tons of mock interviews by experienced alumni mentors in industry until you land that dream job.
Sign up to learn more about the Insight Fellows programs and start your application today.
Need more information before signing up? Here are 5 things to know about Insight (Spoiler: it’s not a bootcamp!).
