Hacker News Reader

Comment by solipsism | Hacker News Reader

Can only imagine what this is doing to code quality...

I don't get why no one seems to consider the possibility that these sorts of interviews actually do get high quality engineers in the door.

I get downvoted for raising the question every time. But isn't it possible this interview style actually works, even though it doesn't resemble real coding and even though many of us hate it?

I have yet to see any compelling argument for why I should believe these interview practices don't work. And yet the fact that so many companies, with so many resources to change things up if they felt it was in their best interest, keep interviewing this way must at least suggest the possibility that maybe it works?

View on HN

> I don't get why no one seems to consider the possibility that these sorts of interviews actually do get high quality engineers in the door.

That's is debatable to say the least. I'm both a hiring manager and on the market for a new job (so I am still solving leetcode problems in my spare time). After 3 years of hiring based on leetcode for technical competency, I can say that the quality of engineers is a hit-or-miss. I've had people writing brilliant solutions to hard leetcode problems crash and burn when writing production code. Currently on my team, the most technical debt was written by someone who completely aced the leetcode stage and was pip-ed out a couple of months back. We even have an inside joke to look both ways before changing X's code. He easily landed a job at a unicorn and I'm really glad he's their problem now.

I really don't believe there is a strong correlation between competitive programming chops and being a competent engineer in a team environment.

We are currently changing our interview practices to ask questions which touch on more practical issues (like multi-threading, review a piece of code, change a piece of code, make a unit test pass, instrument this with metrics, etc..) because what I personally identified as a better signal was competency in specific types of leetcode problems such as LRU caches, O(1) data structures, iterators for common data structures, etc..

I guess the reason is that if it would work we would already know about it and there would be a bullet-proof way to prove it

Can you help me follow, because that seems like a leap of logic. Why would that imply there's a bullet-proof way to prove it?

Because if you can't prove it works, you cannot know it works. You can only assume then.

The companies using it has statistics that it works. They have no reason to publish such statistics since it would help their competitors.

That's an interesting theory. But this problem is actually not confined to the industry, it impacts academia too. Even just as a purely theoretical statistical problem since there is enough data and easy access to that data we should already have some research in this field which sheds some light on the hiring issue.

You have everyone's interview scores, performance feedback and promotion histories in a database at a company with tens of thousands of employees. You also have the interview scores for everyone who failed the interview process. Put a statistician on that for a day and you will get a lot of significant data about your hiring pipeline.

It is not hard to do, the data just isn't public and such data will never become public. Therefore public researchers will always lag behind private ones, since the private ones have access to the interesting data.

Edit: Also it is not a theory, I have seen internal studies on this myself.

I didn't want to call it bullshit but you are not the first who wants to walk me down the bullshit lane.

Here is the thing: this discussion is not about scores or about candidate performance. It's about the question whether the same candidate would be better assessed with a technical interview over a non-technical interview. Since you are not even addressing the question at hand I call it bullshit.

Also, something which has no written proof of and there is no consensus about among at least a group of respectable people and/or institutions is just a theory.

And the third one, you somehow assume that public sector is somehow an inferior player to the market who might not even have relevant data. That's again a theory though and not necessarily correct, here are a few examples of publicly funded software engineer employers: CERN, NASA and the US Army.

> It's about the question whether the same candidate would be better assessed with a technical interview over a non-technical interview.

I don't understand the problem here, all technical interviews are also non-technical interviews since they are still communicating with a human and not just doing problems on a computer. If we didn't care about the human interaction part we'd just put them in a room alone with a set of problems.

Also I think you don't understand how much recruiters hate this process, they'd do anything to remove it since they have no way to game technical interviews. So they work hard to change the interview process at Google to something more soft like we have in other areas, but the evidence points to soft interviews being worse.

And you might not believe me, but I definitely believe me and the people deciding how to hire people at these companies certainly believe in the studies they do, so there is no way they will change the process. These interviews are here to stay, and until we have some new methods nobody has tried yet it won't change. You can complain all you want, but the best companies will be using this process as they scale up since nothing else works at the moment. Some other things might work for small companies, but as soon as the founder can't interview everyone himself it breaks.

"Absence of evidence is not evidence of absence"

OP is just saying we can't prove it doesn't work.

Yes, and I am saying that we can't prove it works. So we cannot know that it works.

Reply on news.ycombinator.com