What are the most common algorithm interview mistakes and how can you avoid them?

Read the instructions clearly, and take everything they write/say into consideration because it's usual for this kind of interview to give all the information necessary to finish the job. Try asking open questions (how, when, what) as they will give you more information than closed ones, and take notes as comments on the code. If necessary recheck from simple examples, where the relation between input and output is pretty straightforward, and make it progressively more complex. For each example, start by writing some pseudo-code.

In my experience, the most common mistake we do in the interview of the algorithm is problem understanding. There are various constraints being applied for the simplification of the problem but we go for the general solution which causes a lot of time wastage and sometimes wrong output. For quick answers, I recommend solving real-world algorithmic problems available at various sources for competitions and mathematical concepts including sequences, series, and vector theory.

As per the interviews, which I taken, interviewee jump on writing solutions rather than clarifying the question properly, there are lots of things which a single line statement don't convey... 1. There are constraints, which interviewee need to clarify 2. There is input/output which need to be clarified 3. There are various edge cases which need to be clarified before even jumping to the solution

People often mistake that what would be best ds to be used, but if they clarify problem statement beforehand and build logic. Then it becomes easy to choose ds on the basis of logic being build. So, it should be always kept in mind, that it's not important to first choose the ds, but it's imp to first build the logic and as per usecases, choose the ds

The interviewer has no crystal ball, they won't know what's going on in your head. Part of the interview is understanding how you think, so you have to verbally communicate this to them. If you had a dumb idea, say "It might sound dumb but I want to try X as a way to test my hypothesis about X2". If you need some time to think, "let me think for a sec". On top of this, interviews are one of the situation where everyone benefits from commenting code, especially todo notes, where you can "dump" thoughts to free up mental space, and then come back later: "i think X will cause problems because of J, i'lll write it down and come back to it later"

In interviews, debugger is not available, but the question which is being asked could be tested by dry run of code. So, it's always better to dry run the code rather than directly going to interviewer and conveying that I'm done with the code

To add to this: I would advise to actively look for ways to optimizing your code. When coding, do not rush to write down the first implementation that comes to mind, if you find something that can be quickly optimized and saves a meaningful enough amount of time/memory do it!

First priniciple is to have confidence on yourself for whatever you have studied till now and if something new comes, then you would be able invent something new today. With this mindset, a person can remain calm and composed and focus on problem statement