Top Ten Mistakes Candidates Make in Technical Interview

Are you applying for a developer or software engineer, if yes, than you should read these most important mistakes you should avoid in your technical interviews. Here are top ten things you don't do to make an impact.

#1 | Practicing on a Computer

If you were training for a serious bike race in the mountains, would you practice only by biking on the streets? I hope not. The air is different. The terrain is different. Yeah, I bet you’d practice in the mountains.

Using a compiler to practice interview questions is like this - and you’ve basically been biking on the streets your entire life. Put away the compiler and get out the old pen and paper. Use a compiler only to verify your solutions.

#2 | Not Rehearsing Behavioral Questions

Many candidates spend all their time prepping for technical questions and overlook the behavioral questions. Guess what? Your interviewer is judging those too! And, not only that - your performance on behavioral questions might bias your interviewer’s perception of your technical performance. Behavioral prep is relatively easy and well-worth your time. Looking over your projects and positions and think of the key stories. Rehearse the stories. See pg 29 for more details.

#3 | Not Doing a Mock Interview

Imagine you’re preparing for a big speech. Your whole school, or company, or whatever will be there. Your future depends on this. And all you do to prepare is read the speech to yourself. Silently. In your head. Crazy, right?

Not doing a mock interview to prepare for your real interview is just like this. If you’re an engineer, you must know other engineers. Grab a buddy and ask him/her to do a mock interview for you. You can even return the favor!

#4 | Trying to Memorize Solutions

Quality beats quantity. Try to struggle through and solve questions yourself; don’t flip directly to the solutions when you get stuck. Memorizing how to solve specific problem isn’t going to help you much in an interview. Real preparation is about learning how to approach new problems.

#5 | Talking Too Much

I can’t tell you how many times I’ve asked candidates a simple question like “what was the hardest bug on Project Pod?”, only to have them ramble on and on about things I don’t understand. Five minutes later, when they finally come up for air, I’ve learned nothing - except that they’re a poor communicator. When asked a question, break your answer into three parts (Situation / Action / Response, Issue 1 / Issue 2 / Issue 3, etc) and speak for just a couple sentences about each. If I want more details, I’ll ask!

#6 | Talking Too Little

Psst - let me tell you a secret: I don’t know what’s going on in your head. So if you aren’t talking, I don’t know what you’re thinking. If you don’t talk for a long time, I’ll assume that you aren’t making any progress. Speak up often, and try to talk your way through a solution. This shows your interviewer that you’re tackling the problem and aren’t stuck. And it lets them guide you when you get off-track, helping you get to the answer faster. And it shows your awesome communication skills. What’s not to love?

#7 | Rushing

Coding is not a race, and neither is interviewing. Take your time in a coding problem - don’t rush! Rushing leads to mistakes, and reveals you to be careless. Go slowly and methodically, testing often and thinking through the problem thoroughly. You’ll finish the problem in less time in the end, and with fewer mistakes.

#8 | Not Debugging

Would you ever write code and not run it or test it? I would hope not! So why do that in an interview? When you finish writing code in an interview, “run” (or walk through) the code to test it. Or, on more complicated problems, test the code while writing it.

#9 | Sloppy Coding

Did you know that you can write bug-free code while still doing horribly on a coding question? It’s true! Duplicated code, messy data structures (i.e., lack of object oriented design), etc. Bad, bad, bad! When you write code, imagine you’re writing for real-world maintainability. Break code into sub-routines, and design data structures to link appropriate data.

#10 | Giving Up

Have you ever taken a computer adaptive test? These are tests that give you harder questions the better you do. Take it from me - they’re not fun. Regardless of how well you’re actually doing, you suddenly find yourself stumbling through problems. Yikes!
Interviewing is sort of like this. If you whiz through the easy problems, you’re going to get more and harder problems. Or, the questions might have just started out hard to begin with! Either way, struggling on a question does not mean that you’re doing badly. So don’t give up or get discouraged. You’re doing great!