Here's the thing, large tech companies aren't looking to hire engineers, especially juniors, who are great at being an engineer because that's incredibly hard to test for in an interview and almost impossible to scale fairly. They're looking for people who will devote their life to the company and can quickly learn new skills. That's exactly what leetcode tests for, so it really isn't surprising at all that every tech company does leetcode interviews. Really the answer is either commit to the grind or go for a job at a non-tech company.

> They're looking for people who will devote their life to the company and can quickly learn new skills

This doesn't reflect my lived experience in SV. People I know who learned leetcode skills and got into big companies usually work less than people who passed more practical tests and get into smaller companies.

I'd say big companies are trying to hire employees who are a "good" mix of:

1. Smart

2. Conscientious / willing to work hard on the right things

3. Existing CS knowledge you know well enough to explain and apply.

For some vague handwavy definition of "good"

(2) is probably worth expanding a bit. Many people are willing to work very hard on the wrong thing, this extends to engineering. As an example, a common failure pattern you might see is someone constantly struggling with how React works and what they really need to do is sit down and read the ~15 pages of documentation. But they never do, and just keep putting in 10 hour days with subpar output.

I've met some legit geniuses (think Putnam winner) for whom basically no studying was required to pass these interviews. Companies paying top dollar are happy to have them. For people like who are less smart and need to dedicate ~100-200 hours of focused studying and practice, companies paying top dollar are happy to take our mix of smarts and willingness to do that work. But once in the company I haven't noticed any expectation to "devote my life" to it.

Right, I think you've explained it better than me. I was just going for the idea that the point of leetcode isn't to figure out if someone is currently a great engineer, but if they have what it takes to become one. Everyone complaining that leetcode isn't related to their day to day job is missing the point.

> an quickly learn new skills. That's exactly what leetcode tests for

I don’t know where people get this idea. Leetcode used to test programming proficiency

I feel the only reason companies continue to take leetcode to absurd levels is because (a) they think harder questions would get them better engineers and (b) other companies are doing it

> Leetcode used to test programming proficiency

The discussion is exactly this, that leetcode is used to test programming proficiency, but it's an inadequate bar.

The parent is postulating that it's a lie; that actually leetcode tests for malleability, and we're getting bent out of shape because we think it's a poor test of coding ability.

However it might be a good test of malleability, and that might actually be it's intended purpose, but that's not communicated.

I don't know about malleability, but I know Big Tech uses it to filter down the number of applicants. They get 200 applications in an hour so HR needs a way to pick a few that won't get them sued.

Understandable when big tech does this.

200 person tech companies are doing the same.

Not quite but almost: Leetcode doesn't evaluate programming proficiency but ability to solve complex and abstract problems using programming. Doing so doesn't require being good at programming but being good at solving problems, and doing so using a programming language. It doesn't require knowing a language well, but only well enough to solve the problem.

This is fine, except when the candidate knows substantially more than the interviewer about how to solve the problem. I was once asked to implement a spsc circular buffer, and I used C++11 atomics rather than a mutex. I wrote up a working solution, but most of the interviewer's followup questions fundamentally didn't map to my wait-free solution. I spent most of the time explaining to the interviewer how atomics and non-blocking algorithms work. The FAANG rejection email came a few days later.

So I don't think these interviews evaluate the candidate's ability to solve complex and abstract problems. They seem to evaluate the candidate's ability to grind contrived sophomore-level computer science homework. Experience solving the real-life version of the problem rather than the academic one is unwanted.

this illustrates the problem very well. your lock free solution is superior yet the interviewer had no clue and you only know about this solution due to experience which is not what leetcode optimizes for.

I've had zero or near zero gotcha string problems in my professional career, which are many of the leetcode problems.

Find the (gotcha) in this string and emit len(gotcha) ... Now do it computationally efficiently (or be able to explain tradeoffs to other resources).

String problems are rare, though may come up more in search engine companies.

But manipulating sequences comes up a lot in many contexts. Usually it's sequences of more complex things: instructions, packets, files, polygons. It's hard to assign tests directly on those, because you have to explain the objects themselves first. So it's a reasonable shortcut to test ability to manipulate sequences of characters.

Don't forget: in 45 min, without bugs

oh and do it in Go* ... Good F'ing Luck .

Go makes normal string operations tricky due to rune being an alias for int32, ranging a string gives []byte indexes ...

https://go.dev/play/p/33jCwNG6Eu6

It's a bit sucky but you can use the standard library function "utf8.DecodeRuneInString(a)".

> It doesn't require knowing a language well, but only well enough to solve the problem.

I guess that really depends on the language. IMHO, if you can solve a reasonably complex problem using a language, you know that language.

I am on the interview team for the company I work for and I wrote what some consider to be our canonical python solution (fastest and simplest) for one of the problems we use. I had to look up the syntax for a "for loop" because I hadn't written python since my first year at university. To me, being able to stitch together simple concepts present in almost all mainstream programming languages doesn't mean I know python, it means I know how dynamic programming works. I don't know the python ecosystem (history, present, or future), know the standard library, know what idiomatic code looks like, deeply understand what makes the language unique, have the mindset of a python programmer, etc. Maybe I just have a high threshold for feeling like I "know" a language.

i did a leetcode interview in c++ and didn’t remember some syntactic details of lambdas and that was the end of it. please stop with this nonsense that interviewers are understanding and that you can look things up or that you will be able to take your time to produce the optimal solution to a problem.

Well I can't speak for other interviewers especially at other organizations, but I try very hard to make it a positive experience. In fact I'll give as much help as necessary to get to a working solution, within reason. I would much rather fix the lambda syntax myself or help the candidate find an example on stackoverflow so we can go back to the interesting part. If the interview ends with a working solution but needed a ton of help, the candidate probably did not pass but maybe they learned something. And maybe they'll tell their peers that it seemed like a place where they could fail without embarrassment, collaborate, and learn.

This doesn't seem right at all. I can kludge together a solution to an arbitrarily complex problem in any language, but that doesn't mean I'm writing it in a way that can be extended and developed upon by other people. The latter is also what takes up the majority of development time.

A one-day interview can't test you on things that take up the majority of your career time.

You mean simple abstract problems, right?

LeetCode problems are solved with under 50 lines of code, using textbook models.

As I understand it, programming is only part of it, a big part is just seeing if you will study hard to learn meaningless stuff

If they’re so interested I have a massive catalog of things that can fulfill such a requirement.

> Really the answer is either commit to the grind or go for a job at a non-tech company.

There is quite a world outside these mammoths Google/Facebook/Amazon/(MS, depending on how their IBMization is going these days) and their minions/wannabes. Personally I would not work for any of these even if they paid me in gold bars.

Off topic: what’s this IBMization at Microsoft?

Yup exactly, that’s the whole thing. They want people who will devote their lives to meaningless tasks

> devote their life

Sounds like they are trying to breed a cult...

More like, sounds like the parent comment you replied to has no idea what they are talking about.

I worked across a couple big tech companies mentioned in the thread, and I've met maybe a couple coworkers at most who "devoted their life to the company". And that's across almost a 3-digit number of people i worked with in some capacity over the years. People take vacations often, they work 40 hours a week or less on average (over the year).

One big thing about most teams at big tech companies (probably sans Amazon, from what i hear, haven't worked there myself) is the work/life balance being an important priority. We had a manager giving stern talks to the few teammates who would reply to work emails on their days off ("you left for a week of vacation in Hawaii, why are you replying to work emails or even brought your work laptop with you? Please stop doing that and enjoy your vacation, everything will be totally fine when you come back.").

I don't even care to defend any company, that's their problem. But seeing the whole "cultism" and "expected to dedicate your life to the employer" accusations just make me feel like I am reading some alternate timeline fiction story.

I didn't mean it in a "cultism" way at all. I was more saying that the point of leetcode isn't to discover if someone is a great engineer but to discover if they are capable of becoming one. Big tech figures if you're capable of becoming a great engineer you either already are due to experience or soon will be because they'll make you into one.

They've decided things like ability to devote time to a meaningless skill that is required to get the job, attention to detail, and problem solving skills are what is required to become a great engineer and see that letcode is a good way to test for those things at massive scale.

They are exaggerating but not all wrong. As hiring manager my job is not to train you for your next job. I'm hiring for productivity and that takes time. If you are going to jump ship before you "pay" back the company then I'd rather skip on you. There is no test but I want 2-3 years if you take 9 months or more to get going and I'd be foolish if I didn't want more.

Lots of programmers think they are 10x but few are. Even my best senior engineers took 2-3 months to settle in and contribute more than they take and juniors are bigger gamble.

The best proxy now is will you spend 1 hour on a simple set of tests, if not you are not serious or are shopping for counteroffers.

I appreciate the cynicism but isn't it more likely that they use it just because everybody uses it?

Yeah, it's clear these people have never hired for a company. I've sat in on a thousand hiring committees, helped design these processes, all that boring shit, and the idea that someone would say "let's do Leetcode challenges so that we select for people who are willing to subordinate their lives to our company" – presumably followed by a "mwahahaha!" – is fantasy, it's something out of a movie.

I mean, look, it sucks when you can't get a job. I've been there (when I briefly tried to escape programming for a different metier) and it's awful. But pretending that the entire outside world is a dark mass of malevolent forces arrayed against you.. well, it may be psychically necessary in some Freudian, Jungian sentence, to prevent ego death or whatever, but in the long run it's neither (a) true (obviously), and (b) nor is it going to do your mind and mindset any good.

> But pretending that the entire outside world is a dark mass of malevolent forces arrayed against you.. well, it may be psychically necessary in some Freudian, Jungian sentence, to prevent ego death or whatever, but in the long run it's neither (a) true (obviously), and (b) nor is it going to do your mind and mindset any good.

Maybe you can post this in the endless Russia threads posted here, which seem to have crowded out the endless China threads.

I guess what you're saying is that apprehension about the motives of of corporate executives is so irrational, it's akin to a psychological problem.

It is low of you to conflate the two. While both companies and russia pursue goals in somewhat pragmatic manner, the former aims to maximize profit while the latter aims to execute an entire nation and take their resources with calculated brutality (most war crimes committed were under direct orders).

> I guess what you're saying is that apprehension about the motives of of corporate executives is so irrational, it's akin to a psychological problem.

No, that wasn't what I was saying there, but coincidentally, yes, I would agree with that statement. For one, 'corporate' is a phenomenally lazy word used to invoke some mental image of besuited sociopathy, from a million children's movies and internet debates. In the real world, 'corporate executives' - human beings, mothers and fathers, working in management careers at (large) companies - are humans doing jobs, like any other humans doing jobs.

I've been involved (as an engineer) in C-level meetings with people like that, as well as worked alongside them in the same teams, and my experience - thoroughly unsurprisingly given what I said above - is that they are pretty ordinary human beings on the whole. I'm sure there are differences between companies in terms of their cultures or values, but that's company-specific and not discipline-specific or seniority-specific.

I get that your experience is that these are people who mete out decisions from on high, which affect you in sometimes-negative and always-unforeseen ways, and that makes you feel like a mediaeval peasant might have felt towards his feudal liege. And maybe it's helpful, from a cathartic standpoint, like I said above, to picture them as evil baddies from kids' movies. But no, the reality is more banal.

(Incidentally, I think those who worship company CEOs - and suchlike - are equally stupid, from the Elon bros to the HackerNews types who recite stories about startup founders as though they were superheroes. These people underestimate the role of chance and – in a way, very similarly to you – overattribute the differences between execs/founders vs regular workers to a proportionate difference in their inner essence [in their case, they think intelligence & industry; in your case, you think amorality]. Both are fantasies.)

At some point the metric becomes the goal itself.

Ie. Leetcode style programing is/was used to filter out engineers that couldn't program. And the problems themselves were relatively easy, reverse a tree, build and LRU (which is not trivial at all).

But then there is an army of prep information, and people are just optimizing for Leetcode style programing. Then companies have to raise the bar again, and keep asking even harder questions. ie. build LRU from scratch was considered hard, now it is just a 'medium' level.

It has taken to stupid levels, where it is not anymore a metric of 'is this person a good engineer', but more of a 'how much this person did prep'. i.e. it becomes a measure of effort and desperation, and not just sheer ability.

That's why you see so many stories, of engineers preping for leetcode only, getting in, and not being able to do their job and getting piped....

Also, personally, the best thing that I did to make me a better engineer was creating an app, a backend, and full service, with paying customers. That taught me much much more than spending months on leetcode ever did. Brushing up some CS concepts and Data Structures, and some coding, does help you to become a better engineer. But doing just that, it doesn't make you a truly useful engineer at all.

Exactly! 10 years ago, I was a strong proponent of leetcode style questions instead of using college GPAs to hire engineers.

It’s the ‘Cracking’ idea that has thrown this whole process off. People have started over optimising for the metric

And it may be worth observing that, as far as I know, this sort of thing is totally unique to programming. No other branch of engineering does it. I've certainly never had to do any unusual prep for an interview--though, admittedly, my handful of jobs since just out of grad school have all been through people I know.

> Take it to the other extreme and you get folks who can’t even solve fizzbuzz. So some coding bar is good.

Sounds like the epitome of a slippery slope, to be honest.

Some people are going to say FizzBuzz (or similar) are a good enough bar.

More people are going to say 2Sum is a good enough bar.

Even more people are going to say Longest Common Substring is a good enough bar.

{...}

And the cycle will continue, because people who will have been asked such things will (most of the time) feel like 1) they've been asked it before, so now they must ask it, 2) they can solve it and feel anyone can solve it (in theory this is fine but in practice, not everyone can solve a problem in 45 minutes that they've never seen or never fully solved before).

Which reminds me of when I was going to college and I frequently had professors or TA's say X problem from the problem set is an "easy" one. Well, yeah, you're the professor or TA (for a reason) and you're the one giving it, of course you'd know how to solve it and such.

> algorithms are useful and learnable, but some companies take it too far.

This is my take too. So I don’t see where the disagreement lies.

Except it’s not just some companies doing it. All companies paying over a certain threshold seem to be taking this to ridiculous levels.

And please do share your ideas for what people should do or what finally convinced you that you weren’t bad at this

> All companies paying over a certain threshold seem to be taking this to ridiculous levels.

They can afford it. And assuming they are a tech company, they need that in key roles. You cannot write things that scale without solid knowledge and intuition in designing and analyzing algorithms, something that can be learned and furthered through experience.

Now of course it's true that not every job in a larger tech company is like that, so there would be some room to adjust the interview based on the exact role. And there actually is. But overall, if you have a massive amount of people applying every week, why take chances, why not take someone from the pool who can demonstrate the skill and allow for some horizontal movement within the company, into a tech-heavier team?

> And please do share your ideas for what people should do or what finally convinced you that you weren’t bad at this

For me, back then, it was something that was fun for me. Part of why I got into computer science in the first place. I would be totally lying if I said I didn't study for the most relevant of my interviews, beyond what I would have done without them.

But I distinctly remember for example freshing up some graph algorithm skills not by doing leetcode examples (I don't think "leetcode" was already a thing back then), but by arbitrarily taking the Debian package database and do fun self-made exercises like: Let's find the largest strongly connected component in the debian package library, i.e. the largest set of packages where installing one will always install all of the others.

I work at a mid-large tech company ~5k engineers.

> You cannot write things that scale without solid knowledge and intuition in designing and analyzing algorithms, something that can be learned and furthered through experience.

The point is not whether people need to learn algorithms, they of course need to, but that Leetcode questions seem to test people’s ability to solve riddles more than their ability to design algorithms

Bingo – I've seen some of the interview requirements – like 20 mins to solve an LC medium, and you can only hit "Run" once so you have one shot...!?!?

Basically if you weren't already familiar with the question and knew the trick you're screwed.

Plus they're really blatant about it too – the recruiters will _actually tell_ you to practice LC, and to try again in 6mos/a year if you didn't make it this time!

> the recruiters will _actually tell_ you to practice LC,

Here they do this before you even take the interview for the first time

The recruiters actually email me all the leetcode prep material and tips

Exactly, even before the first interview, that’s what I’ve seen too

> The point is not whether people need to learn algorithms

No, I said design and analyze algorithms, which is a distinct skill from "learn algorithms" (although that certainly helps). And which is certainly very riddle-like.

To second this point, part of being a good programmer means picking up new skills quickly, and then applying them.

Leet code is very contrived. However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.

> Leet code is very contrived. However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.

I feel very strongly that this premise is flawed. It shows that you have aptitude for a very specific type of learning.

I lead an engineering org at a small startup. We teach our engineers to dive deeply into the customer value prop to find ways to deliver the simplest technical solution to their problem. You don't need leetcode skills when you can identify simpler, more accessible solutions to a customer's need.

The reality is outside of very specialized technical businesses (or business components), most engineers jobs are not to build technically advanced solutions.

I agree. We lost two of our worst performers to FAANG companies. They were both junior and came from top schools. Communication was a huge problem and both wrote very sloppy code. We would assign trivial tasks to them that would take an average developer 30 minutes or less and they would struggle even with heavy mentoring. I was the mentor for one of them and I really tried my best, but there was little improvement over several months and luckily they moved on.

Now I'm mentoring two devs who didn't study CS in college and only completed a coding bootcamp and they're working out amazing.

Yup this is a pattern I’ve seen as well and why I think Leetcode is on the way out. People will figure this out

Yes, exactly this. Leetcode isn't just an irrelevant skill in these situations, it's the wrong skill. Algorithmic optimisations are pointless if you can't assess how much value they generate.

MAANG seems to use Leetcode as a legal proxy for conscientiousness and IQ without testing for other relevant qualities such as strategic insight, creativity, and other skills that are essential for a successful business.

There's no problem with testing for basic coding ability, but if you're not selecting for broader skills - preferably with some diversity - you get the same old leet monoculture causing the same familiar delivery and stability issues.

I think this style of interviewing also serves as a proxy for age discrimination and/or to detect personal work/life balance values that don't favor the prospective employer.

If you aren't willing to dedicate a considerable part of your unpaid, personal time to an activity that they mandate, you aren't a good fit for them.

This argument can be used to justify forcing candidates to learn how to do double-entry bookkeeping (or insert other skill that you won't use on the job) just to see if they can learn. Yes, it checks if they can learn, yes, it is somewhat related to the area, but maybe there's a better way?

I've been 10 years in the industry. If recruiter tells me I need to prepare for an interview in ways other than looking back at the projects I've done, then the interview is not testing for what is important on the job.

> I've been 10 years in the industry. If recruiter tells me I need to prepare for an interview in ways other than looking back at the projects I've done, then the interview is not testing for what is important on the job.

Some people lie on their resumés.

If they're good at lying in person, it can be difficult to detect that.

If they're able to deliver working code of some kind under the pressure of a job interview, then they're almost certainly about to actually program at least a little, so you can trust me of what you see in their background and what they tell you about their achievements.

I'm personally skeptical that leetcode really tests what most companies need in a programmer, but it's probably better than nothing.

> Some people lie on their resumés.

My point isn't that I want to only chat about my resume - just that the problem you give me should be something I may encounter in the new job, ergo I do not need to prepare for that since my entire career prepared me for those (unless I want to reskill and the new job is different than the old one, then some preparation may be warranted).

> If they're able to deliver working code of some kind under the pressure of a job interview, then they're almost certainly about to actually program at least a little, so you can trust me of what you see in their background and what they tell you about their achievements.

Sure! But if the assignment is depending on stumbling upon a brilliant idea, instead of solving a problem that you may see in your day-to-day job, then I don't think it's useful. Think "trim a string" or "split a CSV" [1], not "find the longest increasing subsequence". And maybe also explicitly stick to ASCII encoding for string-based problems (but TBH, if a candidate asks about encoding, they probably know their stuff, or at least know where the gotchas are)...

> I'm personally skeptical that leetcode really tests what most companies need in a programmer, but it's probably better than nothing.

Agree that it's better than nothing. Disagree that we can't do better. :)

Edit: [1] ... maybe w/o relying too much on standard library if those are built into the language you chose.

Yep, that all makes sense.

FWIW, I agree we can do better than leetcode.

I'm personally a fan of an approach I saw someone else describe here, where you literally have the candidate do a few-hours freelance gig for you, paid at a decent rate. Triage some of the low-priority bugs so when you're interviewing you have a little stack of relatively self-contained, well-defined tasks for candidates to pick from. Probably good to have someone pair with them, if the candidate is willing.

You get to see them work in a real context, they get paid, you can learn about how they work, and it seems like a win-win to me.

I also think it's good to be open to other options - if a candidate has a different way to show they'll be good at the job, let them do that. If burntsushi wanted to work on a company's CLI tools, I'd hope a link to the rg repo would satisfy everyone that he knows how to write a good CLI.

> However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.

That’s not why they were introduced. Leetcode using tools like hackerrank were introduced because college GPAs were very bad indicators of programming proficiency and a lot of people also did not have a CS degree.

The questions weren’t this bad before.

And these competitive programmers aren’t necessarily fast at learning things either.

leetcode was introduced because the founder in india could not get a job because he didn’t have a degree. so he made a platform where people could prove how good they were.

the trouble is that this just trains code monkeys to memorize optimal solutions to a set of problems and to quickly reproduce them.

it does not optimize for real engineers who have the experience to build good software and to come up with creative solutions to hard problems.

It also shows you have the time to prepare. Not everyone has that luxury - think working parents with some other challenging happenings thrown in and you have an advantaged and disadvantaged class of people for these interviews

The cynic in me says that's intentional. They want young, enthusiastic people willing to work for less that they can throw away when they're done.

It's more than cynical: https://www.britannica.com/event/Griggs-v-Duke-Power-Co outlines that IQ tests are unconstitutional due to racial biases.

It was out of that judgement, that companies started to require degrees for office jobs of all sorts, as you could discriminate based on education but couldn't on an arbitrary IQ test. And naturally, tests on the topic of a job can also be administered.

And I do think you're right - Leetcode does select for recent graduates who likely were taught in a throwaway language for academic purposes. And selecting for young college graduates are highly likely what they're searching for, as they also do not know their worth.

I had a 3 and 2 year old when I prepared for interviews and I did alright enough to get a job at a FAANG (and it's not Amazon). I took about 2 months and blocked some time every single day. I still managed to cook meals for 4 and put two kids to bed, and wake up at 1am and 3am for night time milk feedings... yes that's not delegated to a housewife it's done by me.

Glad that worked out for you. After a day of watching my now 1.5 year old the brain fog sets in. I tried grinding Leetcode for a while but the pace of progress was glacial and nowhere near the recommended pace for BigCo interviews. I'm glad I went back to doing my own thing even though nothing has come of it yet. Doing Leetcode felt like memorizing party tricks that wouldn't even guarantee a job at the end.

Honestly, do you want a BigCo job? Would it make you happy? The experience of being a tiny cog in an unthinkingly vast machine is more alienating than you might think, even if you like the money.

I think lots of those who stay on long-term in that environment, say >3-4 years, effectively become institutionalised, condemned to spend the rest of their life philosophising about whether they can ever be L8 material. These are people who are, by and large, smart but not wise. Yes, the money is good, for an employee, but it barely equals what even a small business owner could make - and these are people whose smarts would allow them to thrive in the software niche, at least with a minimal amount of commercial nous.

The truth is that FAANG (or FAAG, considering what's going on at Netflix?) keeps these people there by creating a value system. If you've ever read the internet-classic 'Five Geek Social Fallacies' post (https://plausiblydeniable.com/five-geek-social-fallacies/), you'll know that people like us - frankly - are suckers for taxonomy. If you tell them that they are the best because they work for you, and the only thing that can make them any better as an engineer is creating maximum returns for the Borg, and surround them with others who mirror and validate that behaviour, they will fall for it for the rest of their lives.

Don't fall for it. There are a fuck ton of smart people at FAANG companies – that's one of the few marketing points which is unvitiated in its merit, they do scoop up very many of the smartest (again, smart-not-wise) people in the world – but that doesn't mean the only way to be smart is to join. It doesn't mean you - as a unique human being - will be happy there. Carve your own path, be suspicious of people selling you axiologies and hierarchies, find a middle road between excessive cynicism and excessive credulity.

It's something I consider every couple of years. But unfortunately I see a lot of similarities in the hiring process for much smaller interesting companies hiring remotely that seem to be cargo culting BigCo hiring practices. BigCo from my example were just the only ones to be open enough about what will occur during interviews. Is it something fulfilling? Probably not, but I have 5 years of practically unpaid work to get caught up on.

What exactly did you do during that block of time? As someone in a similar situation to you I'd like to begin getting some practice, but I'm not sure where to start. Are there any resources or websites that stood out as being particularly helpful?

Naturally, but how is that a flaw?

I recently went through a round of interviews at big tech companies, and I found that the coding questions were less stressful than I was initially worried about. Leetcode problems are fair, and it just isn't true that you need to know the trick to pass. It allowed me to get in the door at a company I would have had no chance with otherwise (no CS degree, no top school, small no-name companies, etc)

System design on the other hand... that can be hard to prep for!

The reason companies provide so much info upfront, and even send candidates to leetcode.com, is so that everyone knows what to expect. Not everyone is on HN or is even aware of these types of interviewing trends.

Woodworking is also a learnable skill that's completely unrelated to on-the-job activity.

Why not ask candidates to build a desk? As a take-home project! If you're truly kind, you'll let them keep the desk even if they don't get the job.

The algorithm test is standardized. If you make up your own weird test, candidates won’t play ball. Personally I’ve turned down companies that had a strange interview process that required extra preparation. It’s not worth it when I’m trying to churn through a dozen interviews (without my current employer noticing). The leetcode prep process is unpleasant, but since I have to do it anyway, adding one more company doesn’t take any extra studying.