Whenever the topic about how broken tech interviews are has showed up on HN in the past, there were usually two crowds: the "they suck, but they're the best we've got" people, and the much less common "they suck, so we do something else" crowd. Almost everyone agreed they were broken.

What does it say about the tech industry that so many orgs continued to use a system that was known to be broken for so long? How much inefficiency and waste over the past couple of decades is attributable to bad hires? And conversely, how many efficiency improvements in the near future are going to get attributed to AI tech rather than the side effect of improved interviewing practices meant to combat AI candidates?

I agree. And it's not a good sign for the industry when engineers have to spend months working up to being good at answering these questions just to get the job.

You’re spot on with the uselessness of modern algorithmic questions. We live in a world of high level languages; in 20+ years, I’ve never implemented a single one of those coding problems in an actual codebase. I would prefer to hire an intelligent, sociable person with core skills and who has room to learn and grow, rather than someone who can ace silly algorithms but can’t work with a team or complex codebase.

Heck, the person you refer to having hired, and presumably fired, may not have even used these tools. The trend these days is to learn to the coding tests from sites we all know about, not the ideas or concepts needed to work in a real team on a real application. They spend all their time writing algorithms, but often never actually touch a database/write a real complex application. The bootcamp explosion was a self-escalating problem for algorithm-based test questions.

I've been on this gig for about 20 years, this process is by far the best one to participate in an interview both as an interviewee as an interviewer.

As an interviewer I have a lot more joy to tackle an actual task, or a problem very similar to how my team works, with someone applying for the position, it's easier for me to feel like a human instead of an assessment machine. I don't have to learn the N different potential case studies to run the interview, I don't need to feel like I'm ticking boxes when giving my feedback, it's all natural.

As a candidate it relaxes me a fucking lot, I don't have to brush off old books, go through a grind of studying and still feeling like I haven't studied enough because there's an endless amount of knowledge to learn if I need to cover all bases. I also feel a lot more like a human, I can talk through my train of thought, work as I normally would checking documentation, searching, etc.

This bizarre ritual feels almost like hazing by this point, at some point Big Tech decided this was "the way for hiring", then herd mentality took over to the point where tiny startups just cargo-culted processes without even questioning (I heard from a non-technical founder once "if Google does it then it's the best way to do it"). A few generations later of folks hired through this Byzantine process turned it into a hazing ritual, if they had to go through this pain then they might as well inflict the pain to make candidates prove themselves worthy.

It's a giant cycle of bullshit, and no matter how much I tried it's been always impossible to change the minds of HR that this is not the best way to assess candidates, the herd mentality is even stronger around there since there's always the dumb scapegoat: "we do benchmark peers in the industry and they all do this way, so we will do this way".

Sorry for the rant but it's one aspect of this job that really grinds my gears, I fucking hate running interviews with candidates because of it, I never feel I could properly measure someone's real abilities, and I really hate having to go through it myself...

For example I was always a great employee but early in my career I wasn’t big on unit testing.

Or I interviewed for an ML job and they dinged me for not knowing a bunch of statistics things off the top of my head.

System Design interviews can be crammed too.

I'd find it much better if people would ask you "tell me about some complicated systems you helped build and what high-level challenged you encountered". Instead you get "how would you design google docs?".

Does “100% of their loops” mean everything after the initial contact?

I suspect smaller companies could find this challenging.

I’m old enough to remember when independent recruiters acted almost like “talent agents,” with large payouts.

This encouraged them to curate a “personal brand,” and they would often do a lot of the vetting, themselves.

I believe that executive recruiters still operate that way, but engineering recruiters seem to have sharply declined, since those days.

The service on offer here is different. It's providing a means to use LLMs to fake your way through a technical interview.

Showing that you can use LLMs to quickly and correctly solve problems is a good skill to have. Offering up a solution from an LLM as your own work without acknowledging how you got there is just misrepresentation... or to put it another way is just lying. Maybe fake your degrees and experience while you're at it, right?

At least in the long run, many that need these tools to get in will be found out once they start having to solve real problems on the job. Just a shame about other, more qualified people being turned away. Of course if the LLM was sufficient enough on its own, perhaps a real software developer was never required to begin with.

Plus the code base will involve technologies they are not familiar with; rarely does everyone know every technology needed beforehand.

The important thing is that such judgement doesn't depend on the integrity of the other party: the act stands on its own, independent of the intentions of the other party.

If you want a job that someone is offering and they ask you for irrational, unreasonable, or just stupid demonstrations as a prerequisite for getting hired, you have one choice: decide for yourself the show isn't worth the price of admission and walk away... or you do the irrational, unreasonable, or just stupid thing asked to the best of your ability and keep your hat in the ring for the gig. Either way honesty and ethics dictate that you either play the game or walk away.

The moment you cheat and lie: that's entirely on you and perhaps your own dumbass decision to train and enter an industry that works this way. Of course, I mean "you" in the abstract, not necessarily you personally.

So when an employer sees many employees and candidates work the system like this, then they are also right to say, "pretty much every employee we've hired or candidate we've spoken with tries to dishonestly game the system and deals with us in bad faith, so we're justified in screwing with them any way we please. No moral fraud here: we're just doing onto those as those would do onto us."

Well, great... you've defined a level playing field that's working as optimally as it can and without any moral blame at all.

2. No, you're not allowed to lie until blue in the face when selling; https://en.wikipedia.org/wiki/False_advertising is illegal. (Is it underunforced? Probably. Do I wish those laws had much stronger restrictions and harsher penalties? Yep. But is it illegal to lie to sell things? Still yes.)

(IANAL and this isn't legal advice. Though it is moral advice.)

I agree that lying and fraud by businesses, employees, buyers, and sellers are all reprehensible. Nonetheless, I would contend there's no problem discussing the actual subject at hand without expanding it.

I'm not being hypocritical, I'm simply being topical.

As a software development manager, I find the most important quality I need in my direct reports is honesty. If you are not honest with me it makes it very difficult to do my job.

That some developers have been conditioned to dishonesty is a shame on our industry.

But then of course, since FAANG did it, everyone else jumped on the leetcode bandwagon and started asking ridiculous DSA-exam-type questions that had nothing to do with their actual work, even if they had the capacity to conduct proper interviews for their candidate volumes.

I am an employer and would much rather have in person interviews than leetcode.

It doesn't test for anything that AI can do already if not faster otherwise.

Its almost useless as a way to learn how to be a better coder, as most of the "fastest" answers are unreadable.

But if you are using it as a basis for interviews, you are more likely to bump into someone who has trained on that particular question.

I'm not sure what the answer is, as other said, pair programming is kinda the answer. Maybe debugging something in your code base.

No, also mine.

If you want to filter out these candidates, bounties are the way here and in person interviews.

Leetcode can't help you here.