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

151–160 of 305 posts

Re: How to win the coding interview

#151

Post by dudul »

The whole justification for whiteboard coding is total BS. Never have I ever written actual code on a whiteboard, not even "when we are banging our heads against a problem and there is a deadline looming and blablabla".

Yes we do go to the whiteboard. To design stuff. To organize components of the platform and figure out how the fuck to coordinate some f-ing distributed transaction, or how to send messages from A to B and not create a bottleneck. We don't try to write the pseudo-code for a palindrome detector.

I have nothing against coding interview, in front of a computer. Whiteboard coding? I just leave the room. If you give me a whiteboard coding exercise, you failed my interview.

Re: How to win the coding interview

#152

Post by logicallee »

the most amazing thing is that apparently javascript developers do not ever, ever think about any algorithms like the way a C++ programmer would. I was shocked that when the write-up explicitly calls for "the most efficient code possible" nobody cares that the example program starts off making two extraneous copies of data that might never need to be read. (why lowercase the characters inside when you can fail early working outside in.)

Can you imagine if the task were "write the most efficient code possible to check if an array of strings of integers such as "3423", "34356", etc, is sorted (treating the strings as base-ten numbers, "3423" representing 3423 and so on), ignoring any strings that include non-numerical characters" started out by making two copies of the whole damn array. That's what's happening here, it's kind of shocking that this is what javascript developers accept as the "most efficient possible" without anyone having the slightest issue.)

I'm shocked. Even the definition of efficient offered for "Write the most efficient function you can" is

> If you’re experienced, you should know that “efficient” in production code means three things:

> Runs fast.

> Doesn’t take up more memory than it needs to.

> Is stable and easy to maintain.

This is an absolutely shocking definition, given the example code offered. It really does show that javascript programmers do not in any sense consider algorithms the way Go or C++ programmers would. (I conclude this after reading the comments here and also the article.) Especially given the above definitions.

I mean, on a two megabyte input file the "most efficient function that you can" would start by copying the whole two megabytes...twice. Rather than working from the outside in, so it can reject the input and ignore the inside characters as fast as possible. Shocking!

What I'm really shocked about isn't that that's what the solution was - fine, no problem. But rather, that nobody comes close to thinking about most-efficient the way other types of programmers would think about it - and this includes the comment in the story which takes exception to the offered solution. It doesn't do it either. This post and this thread was a real eye-opener for me.

Re: How to win the coding interview

#153

Post by kagamine »

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

#154

Post by revetkn »

swang wrote: post #26
revetkn wrote: post #19

1. "On this particular challenge, I am expecting many will use RegEx as a part of the solution" Really? 2. "replace(/[^a-z0–9]/ig, '');" If I were interviewing and a candidate did this I would ask if he/she knows what i18n is

one of his questions is, "does this need to support utf-8" and i'm assuming in his hypothetical interview it is, "no it does not" also are you seriously going to quiz someone about i18n for a interview? does that really tell whether they are a hire/no hire?

IMO in 2016 it is important to know the basics well enough to know if what you're doing is bad from an i18n perspective (at least for non-junior positions). Even a comment like "// TODO: localize" is OK

It is often a positive signal that a candidate has worked on software large enough to be used internationally or is thorough enough to worry about it. For most of us, day-to-day software work is about being thorough and careful with design and implementation, not heavy algorithmic lifting

Re: How to win the coding interview

#155

Post by dagw »

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.

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?

Re: How to win the coding interview

#156

Post by fao_ »

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.

For my course it is part of the criteria. They want every single line commented.

It's a nightmare of irritation.

Re: How to win the coding interview

#157

Post by cosmolev »

gregmac wrote: post #96
kayman wrote: post #36

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Wor…

> I'm tired of companies asking me to code at their interviews. I have 10 years experience I just saw some code a candidate wrote (offline) who also had nearly this much experience in C#, and who apparently explicitly called out using C#6 and being a C#/.NET expert etc, etc. Their code was written like it was 10 years old. Used array allocation (rather than collections). Time calculations like Convert.ToDouble(Conver…

Disclaimer: I've never written any C# code, I write Java code.

"Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr)" - while nobody writes code in this way in production this is exactly the way of coding endorsed by Codility-like programming challenges when you have 30 minutes to come up with a solution.

Re: How to win the coding interview

#158

Post by xentronium »

efaref wrote: post #146
enraged_camel wrote: post #119

Earlier quoted context omitted.

It's well documented that whiteboard exercises are terrible for evaluating candidates. A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). Not only that, but you will also alienate a great many experienced candidates. If you are OK with all that, fine I guess. But I thought it was widely agreed upon that the software industry needs better hiring practices.

If by "well documented" you mean "lots of people have whinged about it at great length", then I guess you're right. It's also a "tried and tested" method, too, so it's got that going for it. I think if you approach them correctly (like the author suggests), then actually they're fine for their intended use. (Not perfect, but this is the real world, nothing's perfect). If you can't cope with scrawling some pseudocode…

> If by "well documented" you mean "lots of people have whinged about it at great length", then I guess you're right. It's also a "tried and tested" method, too, so it's got that going for it.

You are wrong. Just because it's most used currently doesn't mean it's better. And it is actually well documented.

@tokenadult posted this numerous times: https://news.ycombinator.com/item?id=4879803

Re: How to win the coding interview

#159

Post by Merad »

fao_ wrote: post #156
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.

For my course it is part of the criteria. They want every single line commented. It's a nightmare of irritation.

Having been a TA for CS1 classes, I can understand the rationale behind it to some degree. It's ridiculous how many students go online and ask for someone to do their homework or even copy chunks of code off of stack overflow. Forcing them to explain every line is one way of judging how well they actually understand what they're writing (if they do at all). Of course it's going to be annoying to anyone who already has the slightest experience... but what can you do?
Post reply on HN