> It's like many companies have given up trying to rank applicants based on actual job experience and skills.

Yes.

> "You've created and ran successful software for hundreds of thousands of paying customers?"

They probably are taking credit for someone else's or their teams work. It's depressing to say aloud, but it's the norm rather than the exception.

I ended up landing the London gig and having a fantastic interview experience with the Bermudian company. They all had VASTLY different interview processes but it really made me realise how stupid that whole algorithm/whiteboard process is.

I think this perception that the big 3 use it as a filter is even a bit lame and lazy. I've heard they do it because it's more costly to hire a dummy than to miss a star, but I would love to see the data around that.

Unless of course they aren't interested in hiring "stars" and just want leetcode monkeys to file in and churn out code with perfect asymptotic behaviour.

My C++ interview is pretty easy. No whiteboarding, just a conversation. I want to know for example if this candidate uses templates judiciously or if they are a maniac. Either is fine btw, I’d just like to know.

But more times than you’d perhaps think, the candidate has admitted that they don’t know C++ at all, and then the really awkward questions come, such as why did they write it down, then apply for this job, then show up for the interview...

Then it's a test, not an interview. I don't think interviews were ever supposed to be perfectly objective. If the interview is only based on CS textbook questions, they might as well replace the interviewer with an online test, which by the way increasingly happens for screening, but my point is that it filters out great engineers who worked and delivered solid products because the interviewers are just not interested in details of past work experience

Again, yes. It is hard to fire a bad candidate in case the interview was misleading. Companies would prefer false negatives over false positives. What you see in interviews is a product of laws about hiring and firing.

If this is the case (i.e. companies can afford this behavior), all the claims about skill shortage are a lie and should be called out.

   in-depth questions 

How is that any better than hiring a terrible dev that just spent 3 months memorizing Leetcode solutions? Aren't they essentially being dishonest about their skills?

>time-consuming Phone screens are already several hours over several days and on-sites are typically 8 hour affairs. Is this not already time consuming?

Genuinely confused by the Stockholm Syndrome-like mindset that devs have for Whiteboard interviews.

   memorizing Leetcode solutions

I have my doubts. Indeed from my own experience with Leetcode is I can only do well on the questions that I think quite hard about. Recently I tried to do a Leetcode question marked Medium, but my 3 line solution (while correct, and working on my own test cases) always resulted in "Time Limit Exceeded". I studied their test cases, and realised that my brute-force solution was of exponential time complexity. I then read of the discussion of the problem, was so delighted with, and surprised by one of the proposed solutions (linear time) that I felt compelled to write down the loop invariant in Hoare logic! Fun evening, and I'll never forget this neat algorithmic trick. I think that practising enough Leetcode so as to do well on the Medium/Hard questions requires developing an understanding of algorithms which is highly useful in practise, in particular, if you work with large data sets, clever algorithms are unavoidable for getting anything done. Have a look at the list of past ACM coding contest winners, e.g. the 1993 winners [1] include Craig Silverstein (first hire at Google) and Tony Hsieh (Zappos, LinkEchange).

Summary: I don't believe that doing 3 months coding challenges is meaningfully described as memorisation.

On top of that, doing coding challenges is perfectly compatible with asking other questions.

[1] https://icpc.baylor.edu/community/history-icpc-1993

Ask them how they identified a complex problem, what process they used to get to its root, what they thought was causing it but actually wasn't, which solutions they discarded and why, etc.

You don't need to have a better understanding of their project than they have. You just need to determine whether they have the ability to solve complex technicals problems in competent ways, and at what level.

For example a more junior person might talk more about solving the problem for today and less about solving the problem for tomorrow. Let them talk it out and see where their attention goes.

A more senior person might talk about similar problems they've seen on other projects and how they leaned on past experience to discard non-optimal solutions faster.

You don't need an algorithms test to determine if someone is likely to be able to "get stuff done" in their role. Talking through past problems and solutions might be a better predictor.

And it is surprisingly common.