This post is not about mistakes that you shouldn't do on interview, this post is about my own experience and mistakes that I already did. I'll concentrate only on technical ones, because these issues are the ones that you feel like something that could be easily solved or could be just fixed if you will explain them better to the interviewer. And this post will be updated, I hope I'll fail more, but not a lot to get frustrated :)
Oh, and I decided to do this post as a list of advices. I want it to be a list of DOs instead of DON'Ts
1. Don't allow yourself think that you are limited with time
Probably the interview will be booked in some calendar application, and you will know what is the time limit, also the interviewer could tell you that you (or he) have time limit. Don't allow yourself to think about time, just forget that it exists. You could loose a lot if you'll try to remember about it: you could propose worse solution, because you understand that it's faster to implement, or you can choose data structure for one of the questions, and for the second one you'll keep it (though it's not suitable), because you remember about time.
Remember interviewer doesn't know why you choose worse solutions, he only sees that they are really bad.
2. You have a right to change architecture if during implementing you understood that it has flaws
This is somewhat related to the previous problem, you could keep an old architecture, which was your first idea, or you could change it right now and just don't finish because of the lack of time. Try to consult with the interviewer what he prefers: bad but implemented with explaining a better way or the half-implemented better solution. Sometimes interviewers prefer the first one, sometimes the second. And you'll never know this without asking.
3. Know one language that is suitable for all kind of questions
Know this one, or at least practice in your language of choice to do general programming tasks like the ones that you can find on hackerrank.com.
In my situation there was a mistake that I used Erlang on daily basis and used Common Lisp for solving some of the programming tasks, and unfortunately I didn't solve them constantly - only from time to time. And when I was asked to do task related to graphs I was a bit confused, because I had to think not only about the task, but about the language syntax as well. And it makes a bad impression, interviewer doesn't know why you are so slow and confused.
4. Don't use Common Lisp during interview process (or other rare language)
This is my favorite mistake. If I'll be doing it in another interview, just show me this text again :)
Common Lisp is great language, it has so much abilities and it could be used in so many ways. You probably think that if you will show the interviewer CL, he will be at least ok with seeing it. But the truth is sad: the number of the people who doesn't understand what CL is, is about 100%. Most of them believe that it's a functional language, so when you'll be using classical CL programming patterns, don't be surprised when the interviewer will admit to himself "He clearly knows functional programming and is comfortable with it, yet I didn't like the way it was applied during the interview".
PS:
Remember, interviewing process is held not on your field and you can't apply here your rules. It's a game with the rules created by interviewer. And it's not a court, you don't have any chance to protest against the decision.
