Hacker News Reader

Comment by kyberias | Hacker News Reader

Personally, I think that asking people to write code in interviews brings very _limited_ data. However, from my experience, it usually is also a very _strong_ signal. Narrow but strong.

For example, if a candidate cannot implement a simple algorithm (like the factorial here), he very likely has poor skills.

If he can implement it without too much trouble, that's a good sign, but he only proved that he probably has some good skills.

Again, the signal is narrow but strong.

View on HN

I don't mean to be offensive but reading your statement alone shows me your bias. 1) You constantly referred to the developer as he. You may not realize it but the language you use is an indication of the prototypical picture of a developer you have in your head 2) You are making a strong assumption based on one point of data, your "experience". I am not trying to belittle it but here's a counter. Based on my experience, I have hired developers who did great at algorithmic interviews, design and coding. Guess what, they SUCKED as developers. They didn't understand architecture. They weren't willing to learn a new language or framework. They couldn't properly evaluate why a framework would perform poorly. They had terrible communication skills which matter because their team didn't understand them and they couldn't make a strong case for why their point was right.

Point is, although there might be place for algorithm coding in developer interviews, I am willing to wager a large chunk of my salary that performing well in algorithm interviews doesn't necessarily correlate strongly to performing well on the job.

Why? Performing well on the job needs to be properly defined in it's context first.

> I don't mean to be offensive but reading your statement alone shows me your bias. 1) You constantly referred to the developer as he. You may not realize it but the language you use is an indication of the prototypical picture of a developer you have in your head

Why on earth do you bring this bullshit sexism to this discussion? Of course I have a prototypical picture of a developer in my head. Like everyone. So what? I have interviewed developers and 99% of them have been male. I'm not arguing anything about that percentage here. Let's just assume _male_ developers here then if that makes you feel better.

> Point is, although there might be place for algorithm coding in developer interviews, I am willing to wager a large chunk of my salary that performing well in algorithm interviews doesn't necessarily correlate strongly to performing well on the job.

You don't have a point. It doesn't matter how well they communicate, or anything, IF THEY CANNOT CODE. It also doesn't matter if they can code it they cannot communicate. I'm _not_ saying that coding skill is THE ONLY skill they must have. Get that to your head already. It's ONE of the many skills that they absolutely must have. Another skill is the ability to express their ideas clearly. There are others of course but we are discussing "programming tests in interviews" here.

In addition, I don't believe interviews or any tests during interviews can accurately predict job performance. I think there are a lot of studies that support this. Even though all the tests show green light, the person can fail in the actual job. Nothing guarantees that 100%. We get false positives. But that doesn't mean interview tests are useless!

And is the signal still strong if candidate has a bad day or for some other reason cannot get the right focus in that specific moment?

Moreover, I think it's highly unprofessional to reinvent the wheel by writing most algorithms for production. I always first look for a bullet proof library for that.

Won't you use a calculator for 345 x 27?

345 x 27 = 2415 + 6900 = 9315

You don't need a calculator. Use your brain and show your work.

Nothing but "try applying again in 6-12 months" can fix the "candidate is having a bad day" cause for a false negative, don't know why you're bringing that up. Similarly this thread is about code in the context of interviewing, not production code, so the whole side-argument about when libraries are/aren't appropriate doesn't seem relevant... As a candidate I've been asked things like "write code to reverse this string" and I've given "this_str[::-1] is probably what I'd use on the job. Do you really want me to write a str_reverse() function? Does it need to be in-place?" Each time is yes at least for the first question, so I do it, but I wouldn't expect it to go to production. When I'm on the interviewer side and made to ask questions like string reverse or whatever I say "no, you don't have to do the lower level implementation", all I'm trying to verify is that someone can program, not that they can program arbitrary foo the way I want it done, but typically people start with the low level function, even when I say "use whatever language you want" they still go for Java or similar.

Yes, I think it is fairly _realiable_. It reveals whether the candidate can't really write code.

Again, the idea of the coding test in interviews is not to produce production quality code. It is testing that the candidate's brain can write some code. Try to understand that.

Is it a perfect measurement? Of course not.

Also, the idea is to select an algorithm that doesn't require encyclopedic knowledge of different algorithms. Even (any) sorting algorithms may be too complex for this purpose.

Reply on news.ycombinator.com