[managerclass]

If the true purpose of algorithm tests was to be non-discriminatory, the interview and interviewee should not be able to see each other, their voices should be masked to hide nationality/accent, and resumes should not be viewed when solving the problems. I assure you I can still discriminate against a candidate both consciously and subconsciously during a live algorithm question now.

I guess one upside of these types of interviews is I've been able to disqualify candidates just because I don't like them and saying they didn't do well on the algorithm question as justification is a easy way to reject them without much explanation.

And what about every other field that doesn't use leetcode style interviews? Does a biotech company make their interviewees do lab work live? What makes software engineering so special that we need a different interview process?

[novok]

I don't think that much thought has been put into it IMO. It's cargo culting the google interview process, and no standout success since google has a very different interview process to cargo cult copy.

Google had this process because they are very academia inspired and want to hire the best academics, with a college campus but better work experience, because they had very high back end scale requirements, where algorithms do matter. They also had a shit ton of applicants and favored the false negative over the false positive, which they explicitly and publicly state. You might be able to argue that scale doesn't matter as much at google anymore, but google has no reason to change its process since it first established it, and back then they really had those hard scaling problems to scale up.

The reason why the software profession tends to have extensive interviews is because we don't trust credentialing or even prior experience. [0] We don't want to hire the unskilled bozo who can talk and have brand name credentials but when you actually put them to work find they are not that good at all. So we actually test their skill as directly as possible with various forms of work sample testing with as long as an interview process the market will tolerate, which has stabilized to 5 - 7 hours, or an entire working day.

The beauty of this is that you don't need to get into a med school equivalent with it's crazy requirements, spend 10 years-ish of training and go into 6 figures of debt, get a residency / hazing ritual in a few limit slots in the USA and can come from almost any poor background or country even and eventually make more than most surgeons. In that light, needing to spend 3 months to hard core leetcode doesn't seem so bad.

[0] https://blog.codinghorror.com/why-cant-programmers-program/

[biztos]

> favored the false negative over the false positive, which they explicitly and publicly state

And willing to take false positives -- good at grinding for interviews, bad at actual work -- and just carry that dead weight forever in order to get the true positives who keep the money machine whirring along.

I've come to realize this is hard for many to swallow, but as much as it feels unfair -- just like only hiring from Stanford and MIT -- it was an enlightened business decision for Google. The cost of the dead weight is a rounding error on some distant Sheet, and the opportunity cost of the false negatives can't be measured anyway.

[novok]

When they say they favor the false negative, that doesn't mean that false positive wont happen, is they would rather tradeoff a with a process that produces more false negatives if it produces less false positives because they have a firehose of applicants to chose from.

I think they realize their process isn't perfect, and worse of all, all processes are imperfect and this is the tradeoff set they've chosen. Google also tracks how successful people are after the interview process, so there is a feedback loop inside it. I think it's partly why they dropped the degree requirement from applicants, because their internal data showed no correlation with internal google success.

I think leetcode is bad, and I've tried to get interview processes to change to go full work sample at my big tech with relevant coding exercises, but it's hard to do! And in some sub-specialites where you are implementing graph algorithms and more, a subset of algorithms is in many ways a relevant interview question.

I think slowly the industry is moving away from no-leetcode, but it's going to take a generation or two of startups to really succeed at that, and most vital of all, it has to become a FB / Google level company that defines the industry for the next decade. The current millenial and gen z wave suffering under the leetcode regime and think it's bad need to become the next directors of companies and push for no leetcode in their interview processes. This is just starting to happen which why you see some companies like slack doing no-leetcode in their interview process.

Before leetcode we had microsoft defining the industry interview process with bullshit lateral thinking puzzle questions, and now nobody knows about their existence, nobody complains about them on HN and you never, ever run into them. I think in 10-15 years, leetcode will be the same and we will all complain about impossible work sample coding exercises and take homes.

[tester756]

>I think slowly the industry is moving away from no-leetcode, but it's going to take a generation or two of startups to really succeed at that, and most vital of all, it has to become a FB / Google level company that defines the industry for the next decade. The current millenial and gen z wave suffering under the leetcode regime and think it's bad need to become the next directors of companies and push for no leetcode in their interview processes. This is just starting to happen which why you see some companies like slack doing no-leetcode in their interview process.

in other countries LC is not that common

I've never been challenged with algo questions - just purely day2day stuff, but those were software houses interviews mostly.

[sjg007]

I have yet to meet someone who can talk the talk but can't walk the walk. But I am technical, so I think you need a technical person to evaluate that. The risk is when non-technical folks evaluate the technical and they can be fooled.

Leet code is the equivalent of math word problems. What they show is problem solving ability with algorithms and code. That's a different skill set. Almost like an IQ test.

[Aunche]

It's very rare that people intend to be racist. Rather, they have intuition of what a "good programmer" is in their head, which is subjective, and thus more likely to be discriminatory. If you give them an leetcode question and a rubric to grade their performance, it's hard to deviate from that rubric to much unless if you're intending to discriminate.

>Does a biotech company make their interviewees do lab work live?

Not biotech, but according to my cousin, pharmaceutical research interviews are even more arbitrary. He had chat with 5 employees who asked questions about their own rather esoteric specialties. Most of the questions were completely unrelated to the work that he ended up doing, and my cousin thought that the interviewers themselves were unlikely to be able to answer each other's questions. Unlike leetcode, this isn't something you can predictably study. It just so happened that the labs my cousin had worked in happened to specialize in those same niches. There are so many qualified postdocs that want to move to industry that interviewers can afford to be picky.

[biztos]

This is probably very dated, but when I worked in biotech the interview process was just about 100% trying to find a "culture fit" (to be fair, in an industry about a thousand times more diverse than software) and politics. If the hiring manager brought someone in then you assumed it was on them to have screened for competence, and you wanted to figure out which candidate you'd like to work with, and/or figure out which candidate was favored by which person in power so you could vote advantageously.

[analyte123]

It is common for up to mid-level jobs in finance and consulting to require doing on-the-fly modelling and analysis in Excel. I am pretty sure things like structural, mechanical, or chemical engineering also have substantial technical components to their interviews. While it is not done directly by the employer, board certification for doctors entails 8 hour long tests. Similarly, tradesmen like plumbers and electricians require in-depth written and practical tests for licensure. You can definitely dispute the practicality of these for the job vs. leetcode, but I really don't think that the rest of the world is getting jobs with a resume and a firm handshake.

[biztos]

> What makes software engineering so special that we need a different interview process?

The combination of absurd profitability (of which the tiny slice allocated to employees still seems like a lot) and a complete lack of any actual objective measure of quality.

Because there's no way to really test whether someone is good at programming other than hiring them and seeing how it goes, and because there is an effectively limitless amount of money to spend trying to organize a "solution" to this problem, and because learning enough about each candidate to make a properly educated guess doesn't "scale" enough for fast-growth companies, senior management has plenty of room and lots of incentive to look like they've got it figured out.

For some, this is following their creative whims; for most, it's "do what FAANG does because it must be working, look at all the money they make."

Anyway that's my opinion on it. If I ever have the power to change hiring at any large scale, I'll probably follow my own creative whims and make it even worse.

[Retric]

I have conducted a fair number of interviews and never been surprised at their on the job skills. I really don’t see much of a difference between interviewing people for coding positions and management etc.

Leetcode style tests meanwhile are simply a waste of time. I might as well ask someone if they have seen that problem before and know the trick.