This is all contingent on said leetcode riddles actually helping with candidate selection. If they aren't, you've just limited your pool of potential candidates for no reason whatsoever.

> If I am running the company, I would MUCH rather operate short-handed than "fix" my recruiting problems by lowering the bar.

Nobody is talking about lowering the bar, but of putting the bar in the right zipcode.

An extremely high bar of leetcode testing is irrelevant to the actual job, so that's an irrelevant bar.

This may seem coldly logical but in the absence of my own researched opinions, I am evaluating the merit of the opinion about these interviews based on their origin:

You have - companies that settled on this process, who have been able to attract top tallent that has cleared this bar.

You have - employees of these companies that were able to clear the interview bar.

And then you have - people who don't work for these companies, proclaim to have no interest/ability to clear the bar, but claim to have a valid view into where the bar should be.

In the absence of other data it doesn't seem like the last group is likely to be objectively right

Personally I suck at leetcode questions, but nevertheless have snuck in to some of these so-called "top-tier" companies. And let me tell you!

These questions have fuck-all to do with the actual work the happens there. Sure, you can usually find someone to tell you how much rainwater accumulates into a random bar chart, but I see as much brain-dead code at the top as anywhere else. As much great code, too, FWIW. Everywhere, the key skills that make for a successful IC are the same, and they definitely don't require implementing splay trees or skip lists from scratch and without references. 99% of the time it's shuffling bits around and using hash maps.

Honestly the people I work with who advocate the hardest for leetcode are the ones who had to grind hard and, evidently, want others to suffer too. As if a sane process would mean their own suffering was in vain.

I am not sure that's the whole picture. I don't care about leetcode type problems but if I was applying for a job where they were a barrier to entry, I'd go figure out what it takes to master them.

The bar may simply be "sober enough to understand what it takes to succeed at this task", "committed enough to prepare" and "smart enough to solve them"

These attributes correlate strongly with success, I'd imagine.

I disagree with this point because most interviewers and interviewees are novices, and giving them a task that gives straight pass/fail feedback optimizes for the wrong solution for people that can solve puzzles but not think about systems well. I've had many candidates be able to zip through puzzles but when asked relevant questions about building an understanding systems they wash out immediately. Most systems are more than one code file and I don't need to waste my hiring expenses teaching them how to think about systems from near scratch and having to heavy hand review them to write good code. I have generally found the only leetcode grind types to be less self sufficient and not really a signifier to success. In my experience the leetcode grind type can't even expand on their own answers to answer any useful questions like 'where and why would you use what you just made' and 'what technologies have you used that might utilize this technique' ends up with crickets. Right now my interview has a wash out coding exercise that is beginner oriented to get the resume liars but other than that it's all systems.

> I disagree with this point because most interviewers ... are novices

Having sat on hiring committees, that's a fair summary. Most people are not very good at interviewing, because it's a weird skill, and nobody actually teaches you how to do it well. There's interview training, but it's incredibly short, and seems like half of it is about legal policy. There's ostensibly shadow interviews, but that tends to be luck of the draw on who your shadower is; most won't put in the requisite time to help coach you in conducting better interviews.

I think big companies like to pretend that leetcode interviewing scales well, without actually doing the time necessary to make it scale well.

> Right now my interview has a wash out coding exercise that is beginner oriented to get the resume liars but other than that it's all systems.

This is 100% what I've gravitated to. The longer I've interviewed people, the easier and easier the actual coding parts of my questions have become.

That may be so, but part of my gripe with leetcode is that people tend to grind for many months to "get in shape" for job interviews. That's just not reasonable to expect of anyone, let alone those with families or other responsibilities.

It's not like there aren't benefits to this process. Once you've buffed up, you're prepared for most major tech interviews. Common formats have their advantages.

That said, this format is just too expensive, and has poor predictive power.

// "get in shape" for job interviews. That's just not reasonable to expect of anyone, let alone those with families or other responsibilities.

and

// Once you've buffed up, you're prepared for most major tech interviews.

and

// has poor predictive power.

If "acquiring skill X" is broadly valuable (as you're saying in this case) then your ability to work on acquiring it is predictive of your success.

Sure, it shows that you can apply yourself to a task and finish it. That's also what a college degree shows, but at least there you learn something useful. Come to think of it, that's what any stint over a year or two at a company can show, too.

It's not predictive of the traits that mark a successful IC in my experience. I'm talking about areas like project planning, professionalism, large-scale system design, personal ownership, meticulousness, etc. Curiosity. Some of those might tangentially be covered by leetcode but I guarantee you important stuff isn't.

Everyone I've seen to fail, either via PIP or otherwise, has cracked these interviews. I've seen many fail over the years. Even worse, I've seen many whom I know would be strong performers, wash out because they got the wrong DP problem that day. Where's the benefit in a regime like this? The company loses and good candidates lose, too.

Your argument is a tautology, it doesnt examine any merits of the system, and is no different from: "You have - companies that settled on using skin colour, who have been able to attract top tallent that has cleared this bar."

Or: "World's best banks and world's best traders have invested in subprime mortgages, they couldn't all be wrong?"

// is no different from

Using skin color for hiring is illegal and immoral and the government does not allow it.

Issuing sub primes is bad for business and blew up pretty quickly.

If asking programmers programming questions is "no different" from the above, which is it: illegal or bad for business?

Subprime mortgages were a thing for longer than leetcode was.

If they were bad for business, why was it a common practice for so long? Does a business have no clue what's bad for business? Or is it just self destructive?

If "it's an established practice" argument also enconoasses things that are bad for business, and things that are immoral and illegal, maybe it's not a strong argument?

And yet, those companies seem to be more successful than others with "more relevant" bars.

Or you could look at it as those companies have so much money and fame that they have tens of thousands of candidates pounding at their door so they can afford to arbitrarily reject approximately everyone.

But if you're running a startup (target audience of ycombinator), you'd do well to play a smarter game since you can't outspend or out-fame the FAANGs. A big part of that is to have better interviewing practices than they do.

Leet code interviews only showed up late in these companies trajectories. Internally it’s no longer about what the company wants so much as what people inside the company want which presents huge conflicts of interest. Google for example has done significant research and found such practices wasteful, but internal culture is what it is.

In practical terms the FAANG companies internal processes are horrible and they can’t seem to innovate at all, but as long as they continue to print money there is zero reason to risk change.

Google actually admitted their 'elite' leet code interview process didn't actually help the outcomes... This is the first link I dug up about it:

https://www.theatlantic.com/business/archive/2013/06/google-...

That isn't about the leetcode interviewing.

That's about the microsoft-era actual riddles, like "if you were reduced to the size of an ant and put in a blender, how would you get out?"

eh - I wouldn't be surprised to see the same article about the leetcode stuff.

Maybe using methods that have nothing to do with the job, just don't lead to good results ?

So let me get this straight, you cited a random "first link you dug up", unrelated to your point, and claim it as evidence because you "wouldn't be surprised" if some other article (that doesn't exist) supported your view?

I didn't cite it, and I didn't say some other article existed..

What I said was basically "google admitted their old method didn't work, here's a link if your interested. I wouldn't be surprised if the new method doesn't work either, and we see articles about that in a few years"

The I "wouldn't be surprised" part comes from both methods actually having very little to do with the job at hand, and therefore I think they would BOTH be bad predictors of performance at that job..

// What I said was basically "google admitted their old method didn't work, here's a link

No. Your previous post said they admitted their "leet code" interviews didn't work. leetcode means something specific.

Also I'd draw the opposite conclusion. Sounds like Google is "on it" in terms of evaluating what works and what doesn't. They threw out brainteasers because they didn't work. That suggests whatever they kept does work.

Fair enough.

Can't say I agree with your 'on it' conclusion, but I guess time will tell. It took them about 15 years to get rid of the brain teasers (1998 to 2013ish from what I can tell), so if they're consistent we should hear one way or the other in 2028ish :-)

"It took [Google] about 15 years to get rid of the brain teasers (1998 to 2013ish from what I can tell),..."

During which time the company grew from what to what?

(Actually, when I interviewed in ~2003, I didn't get any brain teasers. All of the questions where either fundamental computer science knowledge or related to the (SRE) position---although they would all be considered "leetcode" by someone without the background. I was pretty impressed.)

They grew phenomenally...

what does that have to do with trying to guess when the next paper might come out? I was just guessing what the publishing timeline might be :-P

Google's opinions on anything are overrated

This always strikes me as the answer that a computer science reclusive would take. You would rather throw cryptic riddles and math puzzles at your lesser man, than pick up the phone and call their previous employer and ask how they performed, what projects they worked on, etc.

I would bet money that the latter is far more predictive of quality candidates than any leetcode problem you randomly pluck from the ether and expect them to solve under pressure.

But again, I expect nothing less from an industry that isn't exactly known for being good at human interaction.

The company that the candidate previously worked for is typically not permitted to say anything about the candidate without prior authorization. Your proposed solution is not workable.

I've previously hired contractors with minimal interviewing because they came from a trusted partner to my organization, so I asked the partner about their productivity and skills and they were given good reviews relative to what we were trying to accomplish.

Each of them were a net negative with respect to the project. The time it took me to review their pull requests and help them write code which was passable was longer than it would have taken me to write the code myself. Additionally, the code that was passable has been a constant source of bugs.

A more thorough technical interview may have avoided hiring them. In retrospect, the correct course of action would have been to not hire anyone until someone qualified was available. This anecdote does support the grand-parent posters theory that operating with fewer incompetent people is better.

Additionally, their proposal is generally workable (which again, yours is not).

Competence is a spectrum and so at some level of competence there will be people who are competent but unable to pass overly complex interview questions. The fact that this overlap exists seems to be what you are complaining about. Even still, not hiring people in this overlap is probably safer than hiring people which make the system worse in my experience.

> Competence is a spectrum and so at some level of competence there will be people who are competent but unable to pass overly complex interview questions

Competence is most absolutely not one spectrum. Competence is measured in dozens (hundreds, really) different axis. Everyone will have different scores (if we could realiably narrow it to a score, which we can't) on different axis of skills. Which of the skill axis are most relevant for any given role will vary, obviously. A generalist will have decent scores in many, a specialist may have mediocre scores in many but 99+percentile in their chosen areas.

Leetcode interviewing measures along one single uninteresting axis, the one corresponding to memorization of algorithm puzzles. That axis happens to be entirely irrelevant to any job I've ever hired for. So I don't test for that because I care as much for your skill doing leetcode as I care for your skill juggling frogs. Neither is relevant to the job.

> memorization of algorithm puzzles

Have you considered that with a strong understanding of elementary algorithms and data structures it is possible "solve" rather than "memorize" these algorithm puzzles?

In the interview format it is most certainly not possible. It is a dance where both sides pretend that the interviewee is going to invent, in ~30 minutes, under intense interview stress, on a whiteboard, some algorithm that took usually years of research to originally develop.

If that were even remotely possible, why isn't that person cranking out multiple novel algorithm research papers per day? They should be outpublishing Knuth, for sure.

So, no. The only road is to memorize extensively and practice acting skills on the delivery.

Most leetcode problems I have seen are not research problem statements and usually require applying one or two algorithms taught in any CS program. So I have to disagree.

EDIT: Obviously even some of the most elementary Algo 101 problems were research questions at some point, and led to published papers, but that's the reason people write textbooks and use them in college, so newcomers don't have to redo the foundational work.

> The company that the candidate previously worked for is typically not permitted to say anything about the candidate without prior authorization. Your proposed solution is not workable.

You're right in that HR of their previous (likely current) employes won't say or allow saying anything.

But of course they're likely not giving as references their current boss, for obvious reasons.

Their previous bosses though, who have also left that company, will speak to you freely.

The case where you are able to speak to the candidate's boss because they have also left is incredibly niche.

> The case where you are able to speak to the candidate's boss because they have also left is incredibly niche.

What could be niche about this? It's the most overwhelmingly common case.

Most people change jobs every couple years and your interviewees ex-bosses are also in the industry doing the same job hopping. It is a near certainty that nearly all (if not all) their ex-bosses have moved to different companies already.

If I'm interviewing a candidate, they likely still work with their soon-to-be-former boss, who likely still works at the same company the candidate is leaving.

This is the most common case, by far.

Are you suggesting going further back, to the candidate's previous previous employer, and hoping that their direct manager from years ago is able to provide reliable and accurate testimony on the current state of the candidate ?

I said ex-boss, not current boss.

I'm surprised this is not a universal experience based on these responses. Every candidate I've interviewed has given at least one ex-boss as a reference. Every reference I've ever given has been ex-bosses.

Do you believe someone who hasn't worked with the candidate in years is a useful reference for the candidate today ?

Yes, of course. Their personality hasn't radically changed from a couple years back.

What you see in the CV is the name of the company they worked for, not the name of their direct manager.

I think back-in-the-day, the cryptic riddles were a (terrible) way of trying to filter "smart" candidates. The people who could come up with a solution to a problem never before seen. But almost no problems are truly original or new. They are just old problems with new packaging or with new/different requirements. So, usually what you end up testing for is nothing more than "has this person come across something like this before?"

Sometimes you'd get interviewers who were at least smart enough to realize that maybe the most you'd get out of it is "can this person break down a seemingly impossible problem into manageable pieces?" That's fine, but then state that or at least give them something real they'll actually run into if hired instead of trying to estimate how many gas stations there are in LA county in their head.

And while those suck[ed], companies having been doing similarly ridiculous things for a very long time to try and save themselves from hiring the wrong people. IBM's infamous "lunch interview" (false on Snopes, but the concept is true and I've seen played out) or asking candidates to take a personality type test to determine if they'd be a good fit before hiring (yes, I did this once early in my career and would just walk out if asked to do one today).

The most difficult I've found is getting fellow programmers to realize that they _don't_ want to hire another "you." Yes, you're an expert in networking and security. Don't interview for that so you can show off your own skills or "teach" in an interview. Interview _for the position_.

You want a diverse set of knowledge, skills, experiences, communication styles, etc. at your company. And - while it can be scary - you always want to hire people who are better than you (esp. if you're a manager!). But that is so hard to get people to do.

// This always strikes me as the answer that a computer science reclusive would take

Just to be clear, you made an assumption in your first sentence and then ran with it for 3 paragraphs.

// I would bet money

If I had to bet who can better assess what proper recruiting for a company looks like, I'd bet MY money on the company, not on random complaints on the internet that basically amount to "it must be the interview structure that prevents me from working at a FAANG"