Most often interview mistakes are discussed many times on many sites. But I want to express my opinion on article on careercup.com web site that I like. Here top 10 of mistakes by career cup: Practicing on a Computer, Not Rehearsing Behavioral Questions, Trying to Memorize Solutions, Talking Too Much, Talking Too Little, Rushing, Not Debugging, Sloppy Coding, Giving Up. I will express my opinion on each mistake and my solutions on it in green color. For software engineering jobs, most companies, especially startups, just can't find qualified candidates, but the problem is that this candidate mistakes are common for big companies too.
#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. Mountain bike rocks! Sometimes is better to see how candidate is thinking and how he is describing code behavior and find mistakes on paper than in the IDE. This practice shows deep debugging and practical skill.
#2 Not Rehearsing Behavioral Questions
Many candidates spend all their time prepparing 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. It is always good practice to spent some time on interview with Human Resources or Project manager. This guys knows how project soul works, how people in team communicating.
#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! Practice, practice, practice!!!
#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. That is true, but you will need analyze couple examples of solutions first. Only after update and patch for your brains it can be easy to understand 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! You need to think first and only than say main idea of your answer and your explanation need to be short.
#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? Some candidates are so shy, they can know answer but do not say it, that is big fault if you have an idea, you need always say loudly what your problems and how you are going solve them.
#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. Think 7 times and make it from first attempt.
#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. Debugging and testing are so good when you want to improve your answer, your algorithm or your decisions, do not forget to ask yourself first.
#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. This is so correct, no comments.
#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.Do not lose time of your interviewer for long, but do not give up fast, you need to ask about how much time you have.
References
Computer Architecture Questions on Technical Interview
Top 30 questions you should ask the interviewer
Interview Questions for Senior and Mid Software Engineers
Interview coach advices
Joel Spolsky - interviewing
Part 1
Part 2
So! You're a hotshot programmer with a long list of accomplishments. Time to forget about all that and focus on interview survival.
You should go in humble, open-minded, and focused. If you come across as arrogant, then people will question whether they want to work with you. The best way to appear arrogant is to question the validity of the interviewer's question – it really ticks them off, as I pointed out earlier on. Remember how I said you can't tell an interviewer how to interview? Well, that's especially true if you're a candidate. So don't ask: "gosh, are algorithms really all that important? do you ever need to do that kind of thing in real life? I've never had to do that kind of stuff." You'll just get rejected, so don't say that kind of thing. Treat every question as legitimate, even if you are frustrated that you don't know the answer.
Reference
https://www.careercup.com/
Summary
Remember all top 10 mistakes and avoid them: Practicing on a Computer, Not Rehearsing Behavioral Questions, Trying to Memorize Solutions, Talking Too Much, Talking Too Little, Rushing, Not Debugging, Sloppy Coding, Giving Up that is not full list of mistakes, but if you avoid them it will help you so much. What can you add to these advices?