This article takes such an expert tone. But it's just opinion. For me, that comment would be a red flag.

He also says to write the most efficient code possible. Then doesn't. See the comments at the end of the post.

Overall, I think what this shows is that as an interviewee, the best thing you can do is try to get an idea of the interviewer's expectations as quickly as possible. People love saying here that it's not a test scenario. But it is. The interviewer has a preconceived notion of what you should and shouldn't do and you need to meet that notion.

As an interviewer, recognize it's easy to think you're smarter than the other person when you already know the answer. Don't be pompous. Don't assume you know better. Try to set expectations very clearly. Try to really listen to the interviewee and understand why they're making the choices they are.

Personally, I would be frustrated by this interview. I feel like this article is a thin justification of a lot of standard interview practices that don't actually work. It and his further comments take a condescending tone that makes me worry he wouldn't be open to approaches he hasn't seen.

Reminds me of a time an interviewer basically gave up on an interview because I told him there were O(N) algorithms for sorting strings with a fixed alphabet. He said "Best case sorting is O(nlogn)" and I could hear in his voice that for him the interview was over. I knew what radix sort was but in the moment I couldn't actually explain or implement it without looking it up and things just went downhill from there.

Radix sort is O(n) in log(dictionary size) which is only a useful bound when the data set is larger than the dictionary (this is a severe but not fatal requirement. Some datasets have many duplicate values, and anyway in practice log(n) factors in real world systems are practically constant factors: an 1log(n) algorithm will be slower than a 100(1) algorithm.)

You can misstate a theorem, or forget the proof, OK, but doing both is poor form.

Another good tip for interviewees: If you don't really understand something well enough to explain it, sometimes it's better not to bring it up than to introduce it and look silly. Sucks. But you're more likely to lose points than gain them for just kind of knowing something exists.

Also applies to hacker news comments ;)

    'use strict'; // avoid ambiguity and sloppy errors

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.

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

Working is the lowest bar of quality.

I find it absolutely destroys readability. It is incredibly hard to follow code written twice.

Another thing is, when I was learning to program, commenting was something I used to keep things light. Sometimes inside jokes or random bits of code that were terrible that would make me laugh once I had the final solution. In my opinion, unless the assignment was designed to teach proper comments, why not let students be creative with their comments, even if its redundant to you.

That said, in a test when hand writing code it should only be pseudo code. Expecting learners to write syntax correct code by hand is stupid.

    > why not let students be creative with their comments, even if its redundant to you.

I wasn't keeping that in mind. Thats makes a lot of difference. Pretty sure I studied under the same rules.

A better idea would be to get a standard code style for all course...

I told him he was wrong and argued with him on more than one occasion. In the end, I just did it his way because there wasn't a good alternative.

Ironically, that is quite a bit like the real world.

Might be fun to do some light ad hoc parsing.

Also, with that rule, I can't resist

    // this line left intentionally blank.

    // this line left intentionally non-blank.

Simplistic comments actually help a lot when learning (even if they are just a reinforcement). Quite often our students write the comments first and then fill in the code which is perfectly fine.

It's also more interesting to let them freeflow it and then explain later why it might not be a good idea. The learning effect is stronger if they can go back and read their own overcommented code.

It's a nightmare of irritation.

You could easily replace "students" with "coders" and that statement is still true. Just an observation.

I'm a Vic20 + Commodore 64 Basic -> Amiga Assembly -> ColdFusion -> C# dotNetCore person myself; mostly back end, but I'll check out JSDoc for when going down that path again next.

I forgot to mention some PHP thrown in there, but I'm glad to have been making the transition to C# in the past year. Working with a strongly typed language is quite a revelation, and some fantastic things are happening with the language and framework these days too (dotNetCore).

From a technical standpoint you should read uncommented code and more often than not be able to tell exactly what it does (barring a lot of poorly named methods or similar architectural issues). Any comments should simply explain the business rules or decisions that led to that code. Maybe you are knowingly violating a best practice for your framework or language because following it would break business logic down the pipeline or something. This is the perfect time for a comment explaining that so a well-meaning junior developer doesn't refactor it six months from now.