Interviews are significantly easier as far as prep time goes for doctors & psychologists.
BUT, you don't have to go through the entire med school & residency rigamarole as a software engineer either, so as far as total effort goes FANG is probably easier. I posit that software engineering is probably the most egalitarian method of socioeconomic mobility, because the only real barrier is time, a laptop, the internet and motivation, while all the other methods require an upper-middle class background and expensive schooling (law, medicine, finance) or just plain luck (business, celebrity art & sports)
But being an interviewer in FANG, I've actually found it rare to find the self taught type in practice. But we do leave that door open unlike medicine.
As much as we all hate the tech interview process, it's a relatively level playing field as far as hiring goes. It's not perfect, of course, but we have to select on something.
As engineers we have a level of free access to study tools and material that my friends in other professions envy.
The alternative to skills testing is to rely more on credentials, references, and background. People who come from elite universities or lucked into prestigious jobs early in their career tend to prefer this type of interview process because it benefits them the most while excluding those who are trying to break into the industry.
The benefit of skills-based testing, however imperfect, is that it opens the door for people who have skills but not the right background or credentials to skip through the ranks and get a foot in the door.
I am not sure that is true at all. People with family or basically any commitments outside of work don't have anywhere near as much time to practice for this sort of thing and why should they need to practice for an interview? You do the job every day, if that isn't enough then the interview is clearly testing for the wrong thing.
I've done this rodeo in my thirties and forties, complete with a very busy existing job, family, long commute, etc. The bottom line is that the time investment wasn't terribly large as it was more refreshing than learning things from scratch.
Putting the 20 hours in over a couple weeks for a 2x raise felt like a worthwhile expenditure of my free time, and worth prioritizing over some of my every day commitments.
However as someone without a CS degree who is nonetheless able to get jobs as a software engineer because there isn't a process of credentialing, I am glad much of the industry works the way it does.
If Software Engineers want to get rid of algorithmic interviews, all they have to do is come up with a professional exam and a strict licensing body... just like most professions carrying a tittle (MD, Lawyers...).
But as long as "3 months js bootcamp grad" can advertise himself as a software engineer just as much as a guy from Stanford CS then we'll keep having these interviews.
The fact that a bootcamp grad can compete for the same software engineering jobs as a Stanford CS grad is one of the very best parts of the hiring process in our industry. Are you proposing that we start using credentials as gatekeeping?
Treating engineering as an undifferentiated commodity measured by leetcode performance is partly why this charade exists.
I'd estimate (from browsing graduate boards) it's probably among the top 5 most hated aspects of the industry. #1 for many - because it's so anxiety inducing.
But it has this side effect that you need to test every candidates.
> Are you proposing that we start using credentials as gatekeeping?
No. As a fast-track sure. So you don't have to start every interview with a FizzBuzz [0].
[0] https://blog.codinghorror.com/why-cant-programmers-program/
But we already do use credentials as gatekeeping. There's a lot of talk about bootcamps and whatnot, but how many of these people actually get passed the resume screen when compared to a Stanford CS grad? FAANGs famously recruit from same 20 universities, and then complain about "lowering the bar" if they branch out anywhere else.
We could stop gatekeeping, but it still happens.
I have these I have used "challenging" algorithmic stuff a handful of times in my careerer. Same with recursion, I have used it, but not too many times.
If I do hackerrank or leetcode or something similar these days, it's pretty much luck if I will get it. If I sat down long enough I could work it out, but with a 2 hour time limit, its usually 50/50 whether the answer appears in my head in that time frame.
And here's the thing. I write a lot better code than I used to. I know what is important, and it isn't clever algorithms, it's choosing the right abstraction, and keeping things maintainable. Making the code easy for the next developer to follow. For the vast majority of software roles out there this will be so much more valuable than algorithmic knowledge. Sure knowledge of computer science fundamentals is important, but I think we give it too much emphasis over what really counts.
Basically these are testing for a computer scientist when the job is for a software engineer.
It would be interesting to look at the correlations between the two, as I'm not sure if that's every been done.
At some point there's a signal to noise ratio issue here as well.
If companies are passing on specific pockets, it’s likely from a belief that the conversion from top of funnel to successful hire is low.
There’s plenty of excuses for gatekeeping, but the real reason is laziness. Of course, we don’t call it that, we call it a meritocracy and apply our biases as “common knowledge”, “proven”, or if we’re feeling particularly full of ourselves, a “sufficient statistic”, but never what it is: a bias, a blanket assumption, a gate.
As soon as you’re relying on assumptions, it’s not a meritocracy. It’s bias promotion, ie gatekeeping.
If small companies weren't able to use inexperienced developers to spin up half-assed MVPs, we'd be at the mercy of whatever large companies are interested in developing, and time has shown that as companies get bigger, they lose interest in niches in favor of products that will be massive successes.
You're not wrong, but I also don't think the world you are describing is a problem.
That's an interesting perspective. I would say there is some truth in it, but a lot of small companies get plenty of investment money.
There seems to be some kind of inherent or cultural distrust amongst tech interviewing, where nobody trusts that anyone has tech skills unless they personally verify it. I don't think a professional exam/certification would solve this distrust.
Or maybe that was just an urban legend...
The problem with the algorithm/leetcode style is that you can run it at a very high bar and you end up selecting people extremely skilled at that one thing, but which has very little to none correlation with shipping reliable & maintainable production code.
I've never needed to hire (and surely never will) people who can reverse binary trees with a hand tied behind their back, so that style of interview is not a meaningful signal.
Nope, not at all. Despite their rigorous hiring process, even the FAANGs have bad hires, burn outs, or people who simply can't keep up with the pace. Some FAANGs require an interview loop even for internal transfers to guard against a bad hire.
https://www.computer.org/education/bodies-of-knowledge/softw...
https://www.computer.org/product/education/professional-soft...
By the time the exam is designed - not complete, designed - it will be obsolete. By the time the exam is completed, there will be 3 new languages invented.
This would be like changing what animal you have to study as a doctor every six months for the test.
The library and framework of the week is not fundamental experience.
I always advocate computer science training really needs more history of the discipline. So many new languages and libraries turn out to be a rediscovery of ideas thoroughly explored in decades prior, just that the creator didn't know.
An orthopedic surgeon gets new types of tools and implants in their toolbox through their career, but the structure of the bones they operate on is the same forever. It's the same with software.
It would be nice to have something like this completely divorced from a recruiting engine though.
I can understand distaste about having a time imbalance (ie. a candidate is not investing the same # of ours as our staff), but like I said, this is a one and done thing and can be used w/ a way to cut down time working with any other companies using the platform.
For us it means going directly to the final rounds, whether they took it at our suggestion, for another company, or just did it for themselves. If they do it for us and they don't end up with an offer, they are not left empty-handed from the process.
In sum, it moves toward some sort of accreditation system, that’s the reason I mentioned it. It's a shame my comment is at the bottom of the pile as I too would love a future where the only time spent interviewing is just a couple hours getting to know my future teammates, and I truly feel platforms like this may eventually get us there.
All the same I'd appreciate feedback on why they're disliked. I've seen them mentioned in other HN threads without any vitriol.
The system encourages the default distrust of developers resumes. That most of them out there are lying, and we need a test to be sure that they can actually code. How many people have actually hired the mythical devloper that can talk well in an interview and not code?
If you're doing work that benefits the company that is another matter, but that's not what's happening here (or anywhere I've ever worked) and is ethically dubious regardless. That's not the point of an interview. I can't believe I'm having to explain this.
You don't pay a dev for their time during the interview process for the same reason no one pays anyone for their time to interview in any industry.
To hire straight off a resume is beyond wild. I'm in the process of hiring a dozen developers for my team, and have had 3 people who had great resumes fail a basic pairing session - they couldn't code. In the 24 years I've been in this industry, probably had at least a few dozen encounters like this. Sure, 90% of the time this isn't true, but it's true enough that it's insane to do it.
"How many people have actually hired the mythical devloper that can talk well in an interview and not code?" I actually have. Twice. Earlier in my career when I believed these sorts of things. And was on hook for cleaning up the mess. Never again. The harm to the team's morale is not worth it.
That said, it's much harder to get your foot in the door without a degree, even in the Bay Area. I had to go above-and-beyond to get my first job at a small startup (I created a program that used their API and was useful enough that I ended up continuing the work when they hired me). With my second job at Dropbox, the recruiter told me that they only reason they interviewed me was because I went to Recurse Center (which is a free programming retreat for programmers that also acts as a recruiting firm). Multiple companies have grilled me during interviews about why I dropped out, including Google.
I can understand the arguments for many of those, but... uh... somehow you're going to need to prove yourself. We can't just throw everyone who shows up into the position to see how they'd do... and the HN gestalt would presumably complain about how awful that is, too.
You could just, like, ask me! Talk to me like a human being. You'll quickly see I'm all the things I claim to be on my resume. /s
Eg: "Tell me what happens when you type an address into your browser bar"
Someone junior might say "You type in the address, it fetches HTML from their server, and your browser shows it" -- "go deeper" -- "Their server uses HTTP or something.." etc..
Someone senior might get to something like "Well when you press the first 'w' key it triggers a hardware interrupt ..." or more likely something about TCP/IP and the rest of the network stack...
you get a very interesting range of answers
A doctor can do a whole lot more damage than the vast majority of software engineers, and yet doctors don't have to start this proving process from the ground up every job change.
The mindset during consulting recruiting seems to be more of "we want to make sure you have a decent base level of knowledge and problem solving skills, but if you don't know how to code/make a PPT/whatever, that's fine, because we can teach you that stuff". Big tech recruiting seems to be the opposite: even when big tech companies claim "you don't need to know everything, because we'll teach you", they still require you to jump through these leetcode-style hoops to prove your skills.
And this is echoed beyond the hiring process too, in my experience. Consulting companies hire smart people and want to keep them for a long time, so they invest a lot of money into training those people and attempting to keep attrition down. FAANG on the other hand seems to care less about attrition (sometimes even embracing it, eg Amazon) and wants to hire people that require minimal training, and thus wants people that have immediately demonstrable knowledge so they can be immediately productive.
I suppose Big Tech could do something similar (skip leetcode stuff for people who have credentials such as prior experience at top tech firms and/or tangible research experience at top research institutions) but I suspect that would not go over well with most people that have issues with the current hiring processes.
Maybe the bar is higher in the US.
More high end opportunities than other career paths certainly, but it's much less top heavy. 7 figure income, a few CEOs make it but not common.
Kind of make sense though if local offices adopt some of the same rhetoric and marketing (elite selectivity etc) as the US head offices but with really different market conditions.
That’s why they are failing. Broken hiring processes. Big Tech is eating their fruits.
What type of consulting are you talking about, and are these jobs really paying >$250k? What would someone have to do to get a shot at one of these jobs?
The key difference between our professional experiences is that the legal profession is self-regulating, whereas software devs/qa/pms are totally socially atomized.
Lawyers have their own organizations, which give them some independence from their clients. Society accepts that this is desirable for the maintenance of the legal order.
Software occupations should move in this direction, for the good of practitioners (wages, working conditions, fairness in promotions and hiring) and the wider society (complement to government regulation around security, privacy, fairness in hiring and promotion).
The bar association defines the examination that lawyers must pass to practice. Employer/client interviews focus more on "culture fit" and familiarity with specific practice areas than on certifying basic competence. The bar also administers "continuing education" to ensure that a lawyer who passed the bar decades ago isn't totally out of the loop on recent developments.
I would love to see the software sector move toward this kind of self-regulation through unionization. We have the power, we just need to coordinate.
Instead of a high-stakes and all-too-often arbitrary interview every single time you want to change jobs, you could prove your basic competence to practice through an exam, and elect to fulfill your continuing education requirements however makes sense for you, within a framework decided upon by workers themselves.
Such a system would not be perfect. No set of examinations is ever going to perfectly capture ever-shifting real world requirements, for example. But we can hardly do worse that the sector is doing now.
We have to stop letting recruiters (i.e. middlemen) and employers (i.e. counter-parties in the employment relation) dictate terms to software workers arbitrarily. The wider society should support tech worker organization in unions because these organizations would provide a check on executive and investor power. Without such checks and balances, we can only expect more of the same short-term thinking and ethical corner cutting.
> Instead of a high-stakes and all-too-often arbitrary interview every single time you want to change jobs, you could prove your basic competence to practice through an exam, and elect to fulfill your continuing education requirements however makes sense for you, within a framework decided upon by workers themselves.
with how the barriers to medicine/law actually work. A single Amazon interview is not particularly high-stakes - if you bomb it you have a dozen+ companies that can offer similiar comp, and you can always re-interview after a year.
If you bomb the LSAT, or the MCAT, or STEP 1, you will effectively be branded for life. All your future applications to school/residency will include this information. How is emulating that going to get us closer to your stated goals?
I don't think this is true. I've heard anecdotally of people bombing the LSAT/MCAT, retaking, and entering elite universities.
But in any case, the analogy is not with exams to _enter_ post-secondary school training, but with exams to certify vocational skills _after_ such training and/or real world experience (e.g the bar exam, the F.E./P.E. in engineering, "masterpiece" evaluations in the skilled trades).
Private enterprises like TripleByte/codility try to perform a certification function of the kind I want to see workers handle through their unions. In fact, it might make sense for a union to simply contract with TripleByte/leetcode/codility to implement examinations. TripleByte has no real incentive to make its examinations a single-shot affair. Why would a worker controlled equivalent have such an incentive? There might even be a perverse incentive to encourage people to take the exam multiple times (as, for instance, the College Board does) that would have to be guarded against.
I think what needs to be considered with this is three things:
1. Tiered credentialing & scope of credentials
2. On-boarding / grand-parenting those who are already practicing
3. Studies on what interviewing in non-software related technical fields looks like. I see lots of anecdotes (probably data now) on what software interviewing is like, but mech / civil / elec, actuary, etc. interviewing isn’t something I’ve seen discussed as openly.
I hope I’m not misrepresenting or coming across as negative here or in what follows.
- - -
1. The F.E. and P.E. exams seem to be aimed at people with engineering degrees, so it’s the interaction of both education and practical experience being certified.
For the F.E. exams from [1], “It is designed for recent graduates and students who are close to finishing an undergraduate engineering degree from an EAC/ABET-accredited program.”
For the P.E. exam from [2], “It is designed for engineers who have gained a minimum of four years’ post-college work experience in their chosen engineering discipline.”
Even after passing those exams, there is still annual education and training requirements to maintain certification. Yes, it’s not nearly as rigorous as whiteboard coding that people are currently subjected to, but it’s not a one time activity either.
In both cases there is emphasis on college.
I’m Canadian and it’s pretty similar for P.Eng. There are some exceptions, but they do require a college education.
This leads to tiered credentialing in the Canadian system. There are:
- technicians (1 year education) - technologists (2 years of education) - engineers (4+ years of education)
There is a defined scope of work for each of these professionals. To move up the tier requires education, exams, and apprenticeship. To switch between specialties, I’m not sure if it’s possible.
Not everyone in the engineering profession needs to be an engineer. It is entirely okay to have tiers. However, tiers become very restrictive and could be perceived as gatekeeping, among other things.
2. I think there will have to be a dividing line of some sort to keep those who have valuable experience without an CS education in the field.
Something like: All people who can prove work experience and practical experience are under this one assessment and credentialing method. All others after follow a different credential evaluation method. Or the tiers allow math, physics, self-taught, etc. to be credentialed as such.
3. Technologist interview anecdote. When I was interviewing as a manufacturing engineering technologist the assessment has been:
- read a shop drawing and tell me what these symbols mean
- jump on a computer and start producing a 3D model in the software used by the company. Produce a 2d shop drawing from that model
- explain how you would come up with an inspection plan to show the product has been manufactured correctly
- solve statistics problems. Set up a control chart. Interpret what the points mean and explain the next steps. Design an experiment. Tell me the hypotheses, tell me how you would calculate sample size, how do you know that’s a good sample size?
- go on the shop floor be handed an inspection sheet and inspection tools. Check if this part conforms to standard
- whiteboard ladder logic for PLC
- handed some print outs of CNC code and asked to explain what the lines meant
Those are technical questions I’ve been asked in a series of interviews for manufacturing technologist jobs. It’s not one 8 hour day of interviews like some tech companies. It’s usually 2-3 sessions x 2-4 hours each session. That line of technical questioning is not a substitute for education. It’s on top of having education and certification in the field.
My point is I don’t think software is unique in asking technical questions. I just think it’s not as widely publicized in other fields.
I'm an immigrant who finished a pure-math PhD and went into software engineering afterwards by building up a portfolio and leetcoding in my spare time. With your system there is no chance I could have done that. Passing all of the exams would not have been possible without a strictly CS education, and I couldn't have studied for the exams after my PhD finished because my visa status at the time was tied to being actively employed.
So many people nowadays are becoming productive software engineers from slightly unconventional backgrounds (pure math, physics, boot camps) and this would stop immediately if CS certification became part of the job requirements.
Barriers to entry exist today, and will always exist in some form. The question is who gets to define them. I am arguing that the workers themselves should have more of a say than they do at present.
One union certification could literally be passing some randomly selected leetcode problems. Ideally, there would be a variety of certifications to reflect the variety of niches in software (someone doing TLA+ for embedded applications shouldn't need to know anything about web app architecture, necessarily).
The difference is that you wouldn't have to do it for every new employer, and workers would have more say in defining the body of knowledge considered relevant.
I don't think anyone would advocate for university credentials to be a hard requirement. I personally have no relevant university credentials except some math courses from a community college.
That said, I think it would be fine for someone to submit a transcript from a CS degree to be certified for basic algorithms knowledge in lieu of sitting an exam on that topic.
Do executives have to demonstrate their knowledge of acquisitions or something similar?
Also let’s not act like this only applies to FAANG. Every dev job from internships and 50k entry level positions and up require the same testing. How many 70k/year jobs require testing every time you change positions outside of tech? Very few. Law, some medical fields, and a few other highly skilled fields do require licensing, but you only do that once per state at most.
Tech is the only field I’ve ever seen where your experience doesn’t matter and you have to prove your skills with every interview. In other industries, it’s mostly about personality.
In comparison, software has no equivalent credentials. Universities, collages and bootcamps have no incentive to fail anyone. As a result plenty of weak students pass - only to discover that they’re largely unemployable. This does a disservice to lots of people - companies can’t trust degrees, and need expensive interviews. Good candidates have no way to reliably demonstrate their strengths. And weak students waste tens or hundreds of thousands of dollars and years of their lives failing to learn to code.
But the benefit of our system is that we allow programmers to be self taught. If you can’t afford to go to collage, or you are from a poor country, or you just don’t like school, that’s no barrier. You can learn programming in your own time and still get a great job. There’s lots of great programmers with the aptitude to become lawyers or doctors - but who would never be able to get the piece of paper they need to get those jobs. That’s something we as an industry should be proud of.
Most well-credentialed people would.
Most under-credentialed people are thankful for skills-based testing because it levels the playing field.
I'd like a way to prove my skills once, rather than with every interview I have. I bet CS grads would as well. The interview process is just so... tedious. And in a field where you get significantly more money by changing jobs, that's a problem.
It's a market inefficiency imo - people get stuck in jobs where they aren't paid enough for at least some amount of time. People can't hire new employees quickly because the process takes forever. I've been on both sides of the interview process many times and it's extremely inefficient on both sides. We're developers... this should be streamlined and automated.
Not sure how serious you're being but the answer is yes, surgeons seeking to change from hospital A to hospital B have interviews where a surgeon from hospital B will visit hospital A to supervise a surgery or other operation. Depending on how critical the position it may even be a partner from one hospital doing the supervision. In fact nowadays the supervision can be done remotely.
Furthermore surgeons are required to maintain their accreditation by earning credits on a yearly basis through continuing education and/or training and they do so on their own time.
These guys don't mess around and if you think surgeons get hired because of their wonderful personality then you sorely underestimate the medical profession (and overestimate their personality ;P ). It's incredibly competitive, demanding, and prestigious in almost every sense imaginable.
The comparison would be more direct if the surgeon was asked to operate on a dummy using a kitchen knife in front of the interviewer.
Then there's the problem that there's no way in hell a software company is going to let another company watch their employee work on proprietary code.
And even that wouldn't be comparable, since they'd be observed on something they actually do every day as part of their real job.
In software the interview drills are about thing nobody ever does as part of the real job, so one won't have any recent experience doing algorithm tricks.
Most surgical procedures are mostly the same regardless of which hospital they're performed at. It's not like software engineering where the tasks and difficulty vary greatly from company to company.
A surgeon's record at one hospital is their interview for the next job. So yes, every surgery they perform is, in essence, contributing to their interview for any future jobs.
This sounds like a good thing to me (for tech). The interview process may suck, but at least everybody has to endure it. And then you're in a meritocracy. That's the theory, anyway.
I sure don’t think leetcode interviews are great, but I’ll take it compared to that.
I don't understand how anyone can think that 7 or more years of med school and grueling residency is somehow easier than studying Leetcode for a few weeks or months.
Med school has a very different selection bias than FAANG interviews. No one seriously attempts to attend medical school unless they've committed to 7 years of grueling training. A FAANG interview, on the other hand, is barely a blip on the radar over the course of an engineering career. A lot of people apply to FAANG jobs just to try their chances at the application process. Not so for medical school.
It's obviously easier if done only once.
But doctors go through education & residency once and then start their careers.
Software engineers need to repeat this every job change for no reason.
Part of it is things like the MCAT and organic chemistry are hard, part of it is there's a whole "hidden" component of med school applications related to volunteering, shadowing, research etc, that is opaque to most. This is part of the reason 50% of med school students already have a parent working in medicine.
[0] https://www.aamc.org/system/files/2020-10/2020_FACTS_Table_A...
I'm not sure if the chances of success are any higher for getting into a medical school in the US. As a one-shot thing, a FAANG interview loop may be tougher, but there are a lot of big tech companies and you can keep trying your luck. I think Amazon alone has like 50K software engineers, they churn engineers like crazy and the hiring bar isn't quite as high as some of the others. Whereas if your undergraduate credentials aren't good enough or you simply don't do well on standardized exams, you're kind of out of luck in terms of getting into a US medical school. I could be overestimating the difficulty of getting into the least competitive medical school in the US, but my understanding is that they are all pretty difficult, leading many people to go to a medical school in the Caribbean.
Doctors in particular (with residency) and lawers to a lesser degree (bar exams) have a more difficult path into the profession. But they don't have to prep and go through the bar exam for every single interview after that.
It would be unthinkable to make an established surgeon balance chemical reaction equations or something obscure like that from their undergrad days as part of the interview! But that's what software engineers must deal with.
Getting that license is significantly harder, though
Tech hires quickly and frequently for the short-term. The algorithms test approach is intended to condense what would be a much more expansive investigation into something straightforward (and supposedly quantifiable.) This discards a significant amount of information which is considered in other high-end jobs.
Plenty of easier process exist but they are not jobs you can apply for. A baseball special assistant hired by an owner can be hired after drinks.
In terms of regular jobs a sales staff working on commission could be easier.
You can really leave a lot of money on the table with this attitude of "oh well, I dodged a bullet, if the interview was hard then the job is probably bad and the whole company too."
I'm not quite there, but if I leave money on the table to avoid a place that treats people in an abusive way, I'm okay with that. I don't need the extra money that badly - it's too expensive.
With interviews - my claim is this: A well designed interview has a high statistical correlation between passing the interview and being useful on the job. Eg when I was interviewing we gave candidates some buggy code (with failing tests) and asked them to find and fix the problems. The ability to debug unfamiliar code in a job interview is correlated with the ability to do the same thing at work.
If you can’t read code, I don’t want to employ you. Please practice and reapply, or find work elsewhere. This is a reasonable position - and probably the only reasonable position for an employer to hold.
There’s lots of skills other than debugging: coding, profiling, algorithmic analysis, CS fundamentals, architecture, communicating with coworkers, etc. A mediocre interview assesses 1 of these skills. A good interview assesses 5+.
Are there bad interviews out there? Yes, lots. But interviews themselves - even badly designed ones - aren’t abusive. (Unless you think a rejection is abuse).
I get that some people put themselves through leetcode practice hell to get a job because they’re unemployable otherwise. I have sympathy for this but I don’t think this is the fault of the interview process. I suspect any decent assessment process would have the same result - where some people need to improve before they can get hired.
> If you can’t read code, I don’t want to employ you. Please practice and reapply, or find work elsewhere. This is a reasonable position - and probably the only reasonable position for an employer to hold.
> There’s lots of skills other than debugging: coding, profiling, algorithmic analysis, CS fundamentals, architecture, communicating with coworkers, etc. A mediocre interview assesses 1 of these skills. A good interview assesses 5+.
I agree with every bit of that. I'd be happy to interview at your place, if I were looking. My objection isn't even just to interviews that ask you random stuff that doesn't correlate with being useful on the job. My objection is to interviews that ask you random stuff that doesn't correlate with being useful on the job and that requires months of your time to prepare for. I think that's abusive.
I don't prepare for interviews. I just don't. My preparation is the 35 years of my career. Either that made me into someone you want, or it didn't. Sure, I'll take on your buggy code and failing tests, in an unfamiliar code base. No problem. But if an interviewer throw a bunch of leetcode questions at me, I'll fail (by the interviewer's standards). And I don't care. I'll go work for someone else.
Great. The natural result of a poorly designed job interview should be missing out on good candidates. Thankyou for giving those companies an incentive to improve their processes - by missing out on you.
It breaks my heart a little to say this but the earlier they pick a different career path, the better their lives will be.
I suspect a lot of people who complain about technical interviews do so as cover for struggling to be good enough at programming to be hireable. I think we need to take the stigma away from that - its ok to find programming hard. Honestly, that makes you a more normal person. It doesn't say anything about your work ethic or your value as a human. And its not a failure to choose another career.
You complain about studying unpaid, but who gets paid to study? Many pay tens or hundreds of thousands to study law, medicine, business, etc., and it takes years. Spending a couple months studying algorithms may not be easy, the process certainly isn’t perfect, but calling it abusive is really a stretch.