News for hackers. Stuff that matters.
Re:How to win the coding interview by BinaryIdiot on Tuesday May 31, 2016 @04:28AM (#11805403)
> It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail

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.

Re:How to win the coding interview by kagamine on Tuesday May 31, 2016 @06:43AM (#11805775)
I felt when I was a student that some teachers just wanted everyone to know how clever they were and sometimes that could be achieved by putting someone else down. Someone who wasn't in a position to talk back. The good teachers gave criticism, pointed to the code standards for the course and were fair in their marking. The best teachers asked questions that made the students produce better work and took time to explain and discuss. They all knew which category they were in.
Re:How to win the coding interview by hvidgaard on Tuesday May 31, 2016 @08:17AM (#11806083)
You can see my reply to the parent comment. I always sit down and talk with the students, but for us to talk about the code, we need to be able to read the code. Unneeded comments make it significantly harder to read code.

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.

Re:How to win the coding interview by tamana on Tuesday May 31, 2016 @11:00AM (#11806885)
In science, there is no such thing as why, there are only deeper levels of what. And those levels are subjective and relative to personal experience.

Your comment merits a failing mark, downvotes, because you made the same subjectively wrong statement twice.

Re:How to win the coding interview by hvidgaard on Wednesday June 01, 2016 @02:32AM (#11812438)
Programming is not a science. "Pad to multiple of 256 otherwise libX will fail" is exactly what a comment is for, and it is the "why", no the "what" - the what is already readable in the code.
Re:How to win the coding interview by crispyambulance on Tuesday May 31, 2016 @09:48AM (#11806462)
I think folks are getting hung up on nitpicking the comments. I never heard of anyone getting rejected strictly because of a stray unnecessary comment in a code test for hiring.

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.

Re:How to win the coding interview by hvidgaard on Tuesday May 31, 2016 @08:10AM (#11806063)
I sit down with them individually and talk about the handin. For any meaningful feedback to happen, we need to see the code. This is not programming 101, but courses that require you to have passed advanced programming, so I expect them to hand in without comments like this:

   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.
Re:How to win the coding interview by vkjv on Tuesday May 31, 2016 @09:42AM (#11806433)
While I might not agree with the GP that this should be an automatic failure, I do think it is very important to emphasize to students that when the code is working, they are not done. They still need to go back, re-format, clean things up, and possibly add tests.

Working is the lowest bar of quality.

Re:How to win the coding interview by MustardTiger on Tuesday May 31, 2016 @10:36AM (#11806737)
> It's a little annoying but it doesn't hurt the readability.

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