The rise of never-ending job interviews

That's a fair concern. We really try and avoid advancing anyone when we suspect might be rejected in the middle or end of our process. It has only happened once since I've been here. Again though, I have to lean back on that everyone should be aware that job hunting isn't an ideal process. Occasionally someone can really ace one part of an interview and really not be a fit in a different part. It's unfortunate when it happens, and that's when I lean on my principles of offering constructive feedback.

This is definitely true. But, let's be honest here: anyone who's done at least 10 or so standard, ~1-hour technical interviews has probably run into a candidate who looks great on paper, but just can't demonstrate enough basic skill to do the job.

One such candidate I interviewed seemed like they'd be really great for the role: PhD in graph theory, publications, projects listed on the résumé, couple of different programming languages (including ones we used). To me, this person's résumé screamed "solid mid-level developer." I would have probably been willing to pass them at a junior level, had they been able to perform at that level, though.

The interview itself was a pretty familiar story. For the technical portion, I introduced the problem (not a LeetCode-type problem, a more practically-oriented problem), we talked about requirements, drew some stuff on the board, and then got to coding.

I had a feeling when we were going through the requirements discussion that this might not go as smoothly as I'd hoped, but I pushed that feeling aside and did my best to let them shine.

We let people code in any reasonable programming language, but they must write actual code. They can fill in stuff like dummy helper functions, if necessary, but we want to see some kind of running, syntactically correct, and, preferably, at least lightly tested code.

They chose to code in Java, which, while not a terrible choice, seemed to me kind of like they were just handicapping themselves when stuff like (IIRC) Javascript and Ruby were listed on their résumé.

To make the long-ish story a bit shorter, we muddled through trying to implement the requirements we'd talked about earlier in Java, meanwhile the candidate was showing me a distinct lack of familiarity with basic facilities of the language, such as "what sort of methods do lists have that might be helpful here?"

Needless to say, this person did not pass my interview, and we did not end up hiring them. But, I really, really wanted them to succeed. Like I said, on paper, they look great. And, I'm sure they could have gotten through a culture fit interview just fine. I'm just not sure how well they would have done on our team, working on our rather large, pre-existing, and somewhat crufty code bases.

If you can figure out a good way to automate the task of "filter these developers down to the ones who can write some semblance of code," in a way that goes deeper than just "Write some code and run it against our automated test cases," I'd like to hear about that. And, I'm not doubting that it could be done, in theory. For instance, maybe something like the engine behind GitHub's CoPilot could provide a way to analyze and grade the candidate's code on things like style, testability, test coverage, modularity, &c.

But, AFAIK, there's nothing like that out there now, so, a structured process consisting of ~1-hour technical interview sessions, one-on-one with the candidate, attempting as best as possible to simulate the real work environment, is about the best I can think of.

During my maths phd time in France I really enjoyed so-called "colles". It was a 1h long 1 on 1 conversation with the student where (s)he was given a complex problem (way too difficult to simply solve in an hour) and a sequence of hints and smaller, easier tasks, leading to the solution. I would often help the interviewee when stuck/correct computations, let them follow the wrong path to make them realize why it was wrong and generally allow for unsupervised exploration of the task. Even though quite often students were not able to get to the end, or even close, I could get a decent idea about their knowledge and understanding of the matter. When I first did it, I instantly thought that's a good way to do a job interview -- being prepared and interactive, have a conversation instead of one way question-answer traffic.

The caveat: I needed to really think through the problems beforehand, understand other possible solutions, traps and potential dead ends (ie. spend time on it).

When a few years later I was asked to do some recruiting at my company (DS/R&D positions, not SE), first thing I did was to prepare a few sets of interconnected problems, to gauge the person's knowledge and how does (s)he think when encountering a new problem with all necessary tools at hand. The problems were difficult but I never expected anyone to actually solve them.

I did dome technical interviews as a candidate, being asked about random math puzzles/algos one can google in 30 sec and which are already implemented in standard libraries -- even though I usually could solve most of them I sincerely wish such interviewers would ef off and stop wasting my time. We are grown-ups, I already spent my fair share of time solving elementary riddles during high school math competitions and I'd like to be treated like a serious professional. During my years as a ML Engineer/dev I never EVER needed to implement a single tree/graph/whatever algorithm from scratch. Also, many adults have a life, family, other full-time job and grinding leetcode is not something anyone should be expected to do.

To be honest, quite a few times I doubted that the interviewer would know how to solve a similar problem without having the solution checked in company's interview problems database. Also, time pressure and stress are a buzzkiller.

As for multiple interview rounds -- a non-starter. Recently, while exploring the market, a top-tier betting company asked me to do a take home, 4h technical interview and then another long take-home (unpaid, of course). I told them that they are ridiculous and asked to never contact me again. I'm at liberty to do so as I have a job I'm happy with and zero need to actually change it, but if someone has been laid off I can see people get grinded to death -- both mentally and physically -- by such interview processes.

There is no consistent process anywhere in any of the interviewing loops, it is all random and made up as everyone goes along. There isn't any deep insight or thoughtful discussion and lots of work being put into the process, it is an afterthought and squeezed in during the day between other fires which are burning, none of which are good for the interviewee. This has been my observation at about every company I've worked for since I've been in IT.

A lot of IT positions at Universities. To the point where it can be a problem as in a Junior Position, it can be really hard to be promoted internally unless someone decides to leave, which they rarely do because people in Senior level Uni positions get good pay and they tend to be very chill environments.