Comment by ownagefool | Hacker News Reader

Comment by ownagefool | Hacker News Reader

Parent Full thread

The false negative is the obvious downside of the coding interview, but I wouldn't say that it means there's no merit to the excercise.

Take for example the "can't define an array" crowd. Are there people virtually sitting in front of me who just forget the basic syntax? Absolutly, but given we a) tell them that correct syntax isn't dreafully important, and b) let them pick the language, a [] would probably suffice, I don't think it's a completely unreasonble ask.

Moreso, when we added a prestep of basic questions that one can google, the "can't define an array" crowd mostly disappeared. Sure, there may be some other causation there, but it's hard to hire a coder that you know, can't demonstrate coding.

Finally, anecdata, since we started coding interviews, the quality of developer is simply better. We have had internal debates about this, but the truth is, everyone is overall happier with what we're doing, and I'm a lot happier that false positives are way down.

I'm sure there's other ways of course. :)

The style you propose probably has a high correlation with intelligence and adaptability without requiring too much upfront knowledge / experience. It's open enough to allow for mistakes or answers which show intelligence without requiring perfection. Comparatively, LC-style interviews and "do you know the compiler of this language"-style questions are looking more for knowledge than figuring things out on the spot.

Knowledge generally isn't a great indicator of future job performance, intelligence is. There might be some correlation between the two (you probably need a level of intelligence to acquire the knowledge for LC-style questions), but most jobs are layering proxy upon proxy to test something that has little to do with job performance. Being able to fuddle syntax or search basic solutions and mutate, is leagues different from what LC in an isolated environment is.

Then you add onto that the alternatives tend to be even worse. Personality testing works when done right, but the vast majority of interviewers play pretend-psychiatrist and make the entire thing way too subjective to be effective beyond filtering obvious red flags. Take-homes work, but most companies won't compensate for time and there's no framework to show which take-homes individuals have succeeded (kind of like a certification process), making them an incredible time sink.

And then there are always the cases who have little experience yet manage to pick everything up in 2-3 months and become anywhere from average to top performers.

> The false negative is the obvious downside of the coding interview, but I wouldn't say that it means there's no merit to the excercise.

Tell that to the people who are always the false negative.

I notice there seems to be a "No true Scottman" issue here where the critics is stating one problem and the proponent is like "yeah but what if we change it to this". I'm guessing the process at your place is much more tolerable than what people have been complaining.

I wonder at what point does it stop being "whiteboard interview" and just a "few sprinkle of algorithmic questions to test logical skill".

Also when the talents pool is large enough, obviously you can do as many brutal questions as you can and still fill the headcounts with good developers. So I think saying "but it still works" is not very productive.

It seems to me that a false negative is worse than a false positive if the goal is to hire talent. Have never understood the mentality that it is better to mistakenly turn away a high skill individual than to mistakenly hire a low skill one, you're effectively guaranteeing the former to avoid the latter. Would you write a search algorithm that behaved this way?

Reply on news.ycombinator.com