First time we talk about why I don't want "the what" comments, only "the why" comments. If they still do it in the next handin it's a fail unless they've explicitly provided me with a reasonable reason to do it.
Your comment merits a failing mark, downvotes, because you made the same subjectively wrong statement twice.
Any interviewee is going to make assumptions about what the interviewer wants. Some of these assumptions will be wrong and some will not be worth the time to ask about (like commenting style). If the interviewee solved the problem and/or displayed a desirable level of competence that's good enough. Interviewers do the coding exercise merely to screen out people that have grossly misrepresented their skills.
On the internet folks like to imagine they're in a position to "immediately reject" a job applicant because of a single "red-flag" that indicates some profound shortcoming. This is rarely the case.
i++ //increment variable because used clicked
It's harmful for readability and takes a lot longer to read. If they hand me a second handin with such comments, after our first session, I'm not going to tell them again.Working is the lowest bar of quality.
I find it absolutely destroys readability. It is incredibly hard to follow code written twice.
That seems incredibly heavy handed and not helpful in the learning process. I was a professor's aid for several programming courses and many students simply made comments like that constantly because it helped them drill it into their head what it did. It's a little annoying but it doesn't hurt the readability.
Automatically failing them on a second turn-in seems very anti-student and anti-learning to me. Teaching through negative reinforcement is the worst way to teach.