Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to win the coding interview

blog.devmastery.com

Post reply on HN
Print view View original

161–170 of 305 posts

Re: How to win the coding interview

#161

Post by scrabble »

hvidgaard wrote: post #102
twblalock wrote: post #34

Earlier quoted context omitted.

n++; // increment n

I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.

I have had a teacher that said you needed to comment every single line because that's how code is written in the real world.

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.

Re: How to win the coding interview

#162

Post by bogomipz »

Kesty wrote: post #148

The problem with all this "advices" is that they boil down to "just study". I agree that been prepared for an interview is a good thing, if you are ready and have studied you show that you are willing and that you put in the effort. But what about people that are currently working ? You are trying to get the best programmer, and chances are is that the best programmers out there are currently working (minus a small p…

Advice is plural not "advices."

Re: How to win the coding interview

#164

Post by NhanH »

iSnow wrote: post #143
NhanH wrote: post #32

> I'm not actually testing how well you write code on a whiteboard. I’m looking for something else Even if you believe so, it's more likely than not you're not actually doing that. You WILL judge how well someone write code on a whiteboard. I've done that too, and it's surprisingly easy not to notice. You can't stop yourself from judging, maybe you can realize that your snap judgement mean jackshit and don't make dec…

>As someone who can't figure out if (9+1 === 10) is true or not under interview As someone who has probably the same problem, any ideas how to land a better job? Those typically involve a lot of coding while someone breathes down your neck.

I told my friends that they better get to VP or equivalent decision maker quick so I don't have to deal with stupid interview anymore.

Joke asides, unfortunately I don't have a solution here, I gave up on interview in general. Personally, if I was looking for a corporate job, I'd write "interview is stupid" in front of my workspace and play the number games until one day I might pass one. Otherwise I'd look for smaller orgs and tell the decision maker I have interview-phobia, can we do something else?

Re: How to win the coding interview

#165

Post by hvidgaard »

BinaryIdiot wrote: post #130
hvidgaard wrote: post #102

Earlier quoted context omitted.

I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.

> 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. Aut…

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

#166

Post by pc86 »

snarfy wrote: post #163

> Your code should avoid breaking at all costs. This type of practice hides bugs. Whatever happened to 'fail fast, fail often'?

"Fail fast, fail often" does not refer to the build status of your project, it refers to the business.

How does writing code that builds hide bugs?

Re: How to win the coding interview

#167

Post by hvidgaard »

dagw wrote: post #155
hvidgaard wrote: post #102

Earlier quoted context omitted.

I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.

Did you sit down with student and try to understand why they wrote comments like that, explain exactly why comments like that where bad and try to show them a better way, or did you just fail them and hope they'll work out all those things by themselves?

Always after the first such handin. The second, not so much.

Re: How to win the coding interview

#168

Post by pc86 »

sundvor wrote: post #4

Very interesting article, thanks for writing! I have but one, eh, comment: > Your code should be commented Sure.. but: > * @param {string} stringToTest - the string to test. > // make sure we have a string. > if (typeof stringToTest !== "string") { > > function isPalindrome(stringToTest) { > ... > // if we get here, it's a palindrome > return true; Do we really need to explain that stringToTest means string to test?…

Comments should explain the why of code, not the what or how.

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.

Re: How to win the coding interview

#169

Post by hvidgaard »

kagamine wrote: post #153
BinaryIdiot wrote: post #130

Earlier quoted context omitted.

> 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. Aut…

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 expl…

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.

Post reply on HN