Why do we make this the gate keeper to our industry when we know (except for the very specific roles) we will rarely need leet code type problems. When we do we just google them.
So silly to me.
Yeah, older people are more likely to have other priorities, but they’re also more likely to be financially secure and thus able to trade money for time to study. Also, they’re more likely to have gained time management/prioritization skills and discipline that they could apply toward studying.
Ultimately it seems like arguing that older people lack time or inclination depends on ageist stereotypes.
I could never go back to university for that reason - studying, fine, I did a ton of courses on edX and Coursera, but I pick what interests me and a lot of test problems you are given (at least in my experience, at university and later online) too often are more about understanding the intent of the person creating the problem rather than anything useful. I could also never go back to the army (Germany, mandatory service, battle tank mechanic) and take commands from some guy who just wants to posture.
I'm not any less willing to study than I was at university - but now I refuse to do what I think is useless or meaningless. Studying for tests is high on that anti-list. Not all tests, I had no issues with tests I took for things that needed certification, e.g. sailing or for the pilot license, but that stuff was useful in practice and not nearly as over the top because those tests were not designed to "weed out weaklings".
EDIT: An anecdote for that last phrase
After writing the comment I got curious and googled that exact phrase. I found this in https://en.wikipedia.org/wiki/William_Smythe_(physicist)
> He authored a textbook on electromagnetism called Static and Dynamic Electricity, which was a widely used reference in the field during the 20th century. His electromagnetism course was modeled after the Cambridge Mathematical Tripos examinations and designed to "weed out weaklings." Smythe's course was so infamous that future Nobel Prize in Economics laureate Vernon Smith switched to electrical engineering from physics to avoid it.
Why is it weird that people should spend time preparing for ask for a new job? I mean, ask an orchestra musician how much time they put into preparing for auditions, or how much time many degreed professionals put into passing a certification (e.g. the bar exam or medical boards).
If you don't want to spend time preparing for job interviews, then fine, don't. But don't claim "discrimination" when there are those of us willing to sacrifice to put in the hours to prepare.
Does seem like there is a growing movement to explicitly not do leetcode style reviews at many places which is good.
Training is basically the main work performer has to do to earn his life, and all training is valuable. You could compare with professional athlete and see how it’s absurd.
> If you don't want to spend time preparing for job interviews, then fine, don't.
The idea is that you have to understand the process. If you don’t see the point of certain exercise, you search for a rationalization, and discrimination looks like a good one. Also, the discrimination is not against people that won’t train for interview, but to give a bias to people that don’t evaluate returns on their invested time
By and large, professional musicians are paid for a standard level of performance competence and a strong level of versatility. The small handful of remainders are the famous ones renown for exceptional levels of performance.
Plenty of professionals are paid to play the musical equivalent of e-commerce site.
Pretty much anyone can do that. We’re looking for someone who can do the other 20% of the job that’s novel and difficult. Ideally someone who recognizes that rereading glue code is a waste of human effort, and automates it away instead.
Additionally, I find the logic behind this strange. It implies that just because some people can afford to sacrifice that this setup isn’t discriminatory. But the criticism is that some demographics are disproportionately unable to sacrifice. Discriminatory doesn’t mean no on in that demographic is able to afford to dedicate whatever resources towards the thing. In fact systems of discrimination often work better when there’s a model minority or “one of the good ones” that can be pointed to as an example as to why a discriminatory system isn’t really a problem.
Doctors have to recredential over their whole career. Used to be every ten years, but some specialties are moving to annual “quiz-sized” credentialing over once-a-decade cramfests.
It's weird because the preparation is often the thing we're not doing in our day to day.
I'd also go as far as saying if you need to cram crazy hours shortly beforehand to pass any exam or test then you're not really qualified to pass. If you were qualified you wouldn't have to do this because you'd already comfortably know the answers. I get wanting to casually review the finer details which is fine, but if you're in "oh crap, it's Tuesday and the test is in 3 days, time to drop my life and cram 10 hours a day to prepare" mode, maybe you're not ready?
I also think you can't compare software development to musicians or sports. I do play the guitar and there's a massive amount of muscle memory involved. I've gone a few years without playing in the past but within a few minutes of picking it up somehow my brain can resume where it left off and my hands just move to the right places almost on their own.
The same can be said for sports, there's a lot of practice and warming up to burn in muscle memory and literally get your physical body in an optimal state. Also the stuff you're practicing is directly applied to what you're "really" doing in your professional day to day.
Tests are different because you are on a timer and they are balanced around it. I almost got straight A's in university, apart from a single B in a course I was confident I actually understood. I got A's in shit I couldn't even begin to explain. But signals and systems, which I genuinely understood at the time, I got a B because I didn't bother studying and memorising shit. I had to work stuff from first principles and ran out of time.
I feel like it's the same in programming interviews. There's no time to actually work out anything from first principles or any original thoughts. Either you know the answer immediately and you spew some shit to make the interviewer happy, or you fail.
Like you say, it's very different for physical activities (can't comment on music), because you cannot drastically increase performance by cramming for a few hours. I was an amateur powerlifter, I stopped training when covid started. There's no way I can get my strength back in 3 days. But I bet I can get an A in some random exam after cramming for 3 days in some random university course I did however many years ago.
I've had a professor who said that the purpose of an exam is to study for it.
The same professor said that if you don't learn something in an exam, then the exam is useless.
Because that preparation, by and large, is not related to the actual job.
> I mean, ask an orchestra musician how much time they put into preparing for auditions, or how much time many degreed professionals put into passing a certification (e.g. the bar exam or medical boards).
Those are all instances of people being asked to do/know things that they will need to do/know for their actual jobs. An actual comparison would be if the orchestra musician was asked to perform blindfolded on a random piece of music, and have to spend 6 months training to memorize the most often requested pieces to be ready for the interview, only to play for the rest of their career with the sheet in front of them. (Not trying to compare difficulty, but absurdity. I don't doubt orchestra musician's auditions are harder)
Also, bar exam and certifications are not job interview. You also have exams and certifications in CS and no one is complaining about having to train for those. A lawyer/doctor certainly doesn't have to pass the equivalent of the bar/medical exam every time they want to change firm/clinics. They just talk about their past experiences. Barely any prep required beside being able to give a good sales pitch about you.
Meanwhile, as a dev, you are expected to do it all over again every time you will change job. Even for internal moves, many of the GAFAMs expect you to go through this again.
Granted, it's more representative than leetcode performance but still far from a perfect system.
A bit off topic, as this isn't orchestral music, but in college I was in a couple of bands as a bassist, and in one of them the guitarist was probably one of the best musicians I ever played with technically. However, because he was so good, sometimes he would get taken by surprise when someone less talented in the band messed something up during a performance. When practicing before one of our gigs, I noticed that our rhythm guitarist was playing a certain section incorrectly and essentially finishing it in half the time he was supposed to; the drummer and I would generally catch on immediately and course-correct, but the lead guitarist tended to be flummoxed and took the longest to group up with everyone. I made sure to mention it to everyone since I figured it might come up again, but I think everyone else forgot by the time the gig happened, and the same exact thing happened, and even though it was the rhythm guitarist who made the initial mistake, the lead guitarist ended up being the one who "looked" the most wrong to the audience because the drummer and I knew that the only way we'd get back on track was grouping up with the rhythm guitarist and leaving the lead guitarist behind. If anyone were trying out our two guitarist to join an existing group, I think almost everyone would take our lead guitarist due to how much better he'd perform in an audition. However, if the band he tried out for wasn't able to keep up with him, it's very possible he would have been the wrong choice. This seems pretty similar to "leetcode" style interviews for a software engineering role; the person who is able to impress the interviewers the best technically might end up being a bad fit for some teams if they aren't able to collaborate as effectively with their team.
TBH, depends on the job.
I think the problem is hiring people with these skills to do jobs that don't require them. That's bad for both parties. The employer is going to be paying for a skill it is not required, and the employee will get bored and switch jobs, costing everyone time and money.
They only do it once, though, not for every single interview.
Interviews are by definition a legal way to discriminate.
To be clear, I dislike the current way interviewing is, but do you have a better solution to screen out 7,000 applicants? The vast majority will be knocked out by the leetcode style interview, and sure, some brilliant minds might fail because they can't remember linked lists in the moment, but atleast you screened down from 7,000 -> 70. If there is a better way, we'd all love to know.
I am prepared for this to be voted down, but I am genuinely wondering the answer to this.
I've been in organizations that were spawned by both of the above extremes. The former is definitely more pleasant to work in (everyone is at least competent) even if the interview was much less pleasant to do. I do feel like more orgs should try to target the middle ground instead of just aping Google and going ham on the leetcode shit.
My belief is that if you aren't doing Ph.D. level research, all you need to do is get the candidate to prove they can write themselves out of a bag with React/Python. Anything else is overkill, and a real cost loss to the business in terms of money and time.
I will admit that for most businesses there will be times to do the first, and time to do the second. But I imagine this distribution is something like 20/80, whereas most companies are doing 80/20.
Coding is hard, but so is marketing, accounting, management ... But are your marketing candidates being put through the ringer too? I suspect software engineers are being uniquely hazed.
Peace & Love
My girlfriend works on the business strategy side of Fortune500’s. Our interviews look like a joke compared to theirs.
That’s kinda what they do.
You are put through an initial ringer to vet for basic fit and competence. Then you get a take-home exercise that consists of several business case studies. You have to detail a strategy for what you would do in that situation, support your argument with research, etc. My girlfriend said it’s a lot like writing a term paper in college.
Last time she interviewed it took her I think 2 or 3 days of full-time work to do the case studies.
Then you go back and defend/present/discuss your work at an interview.
Her job consists of doing basically that, but with a team, larger consequences, more direct ownership, and loooooonger processes because so many people get involved in everything. Her team is strategizing what could become a trillion dollar product (in like 10 years) if they get it right. It’s pretty cool.
I've always been of the opinion that a take home software engineering project that I can present in the interview would be preferable. Coding alone for a few hours and then being able to get all my ducks lined up.... Sounds like a practical and great interviewing process to me.
He's now doing two jobs at the same time and the companies don't notice he's barely doing anything but appearing in meetings.
YMMV
Big corporations are incredibly wasteful, so I'm not surprised.
I also know plenty of developers who do little at work, but at least they need to produce a substantial amount of code, at the end of the day.
I've never had to prepare for an engineering interview in some 15 years of doing this professionally.
> the job takes way less effort compared to software
The easiest part of my job these days is writing code.
The challenging fun part is setting a technical strategy that aligns with the business and gardening the team around me with soft influence towards that strategy. Super challenging. Would've been easier to just do it myself, but there's only so much I can do on my own.
Ultimately, you should go do whatever comes to you easiest and/or is most fun. No sense grinding away at something you're not good at. Maybe your friend has an immense talent for business and strategy.
And yet, all these companies would have complicated hiring pipelines to hire. I have seen examples which made me laugh; like receiving tens of cvs and asking almost all of them for take home exams (felt sorry for the reviewers and the candidates who lost their time), multi stage technical reviews for companies with less than 10-20 employees, final executive level interviews with more than 5 candidates in parallel, time to hire times of 3-6 months, etc.
But if I must write code as an applicant, it better be similar to real world tasks and not some bullshit, especially if my chances of getting hired are still slim. Having to do work in order to get hired is literally sucking the lifeforce out of me, so don't suck even more out of my via the agony of glorified brain teasers.
Do you have any hard data behind that ratio?
Or are you just kind of ... making those numbers up?
Because they, you know, "feel right"?
I concur with the parent's point. HN is perpetually complaining about tech interviews, but nobody ever suggests a viable alternative that can cope with such application volumes.
https://www.cnbc.com/2019/04/17/heres-how-many-google-job-in...
The parent poster was literally saying that LC screening by itself will get you your 99 percent reduction.
The actual hiring ratio at google is something like 0.2%. They pass over 998 out of 1000 applicants, so no matter what they do, they'll pass over a substantial number of qualified people, and no matter what they do there will be complaints on HN.
It was this resorting to made-up numbers that I found to be kind of weird.
While remote positions can certainly receive a lot of "noise applicants", as I discovered in my last job, you can filter out half, if not more, on just a quick pass. Most companies are dealing with dozens of candidates at the most, often less. Certainly not thousands of them.
If they "cheat" by having stack overflow do their work for them, but they can explain it well enough, they probably understand the concepts at least.
More realistic explanation: they try to make an 'American Idol' like process, this gives them the feeling of having chosen 'the best'. Now it probably takes some standardized task to do that kind of competition, as it is necessary to maintain the claim of having an objective hiring process.
I was once told, that in the olden days there was a different kind of hiring process (that was not about programming jobs, actually, they didn't have that job at the time). It would go as following: the owner would invite the candidate to join the crew for lunch, if the candidate eats a lot, then he would count as a good worker. Actually that would make a good test for 'culture fit'...
BTW, the article has a link to a free course on hiring practices, thanks for the link! https://course.jobsearch.dev/01_introductions/01_course_intr...
I've thought this too. Apple, Google, Intel, Adobe, Intuit, Pixar, and Lucasfilm were hit with antitrust litigation starting around 2010 because they were all involved in colluding to reduce the ability of devs to switch jobs. Since then we've only seen the rise of leetcode style interviews. We're way way past the days of tree traversing and FizzBuzz. We're asking candidates to recite Dijkstra's but pretend they've never seen it before. It's just way more convenient for tech companies if people don't leave in the first place. I know I've stayed at my job much longer than I should because I hate interviews.
> as it is necessary to maintain the claim of having an objective hiring process
Yeah no one wants to admit they don't know what they are doing. It's bad for FAANG myth-making. A company the size of Google or Facebook is never not hiring. They are a big boat that can't just stop moving like that. They have a constant churn rate, the need to keep interviewers sharp, and a certain target rate they need to hit of applicants in, new employees out. All the process between the in side and out side is Scientology. It's just complete fabricated cultish nonsense. The owners of LeetCode must be enjoying it though.
I didn't know that, really interesting detail.
>no one wants to admit they don't know what they are doing.
Interesting perspective, though I don't know about the vodoo part. They seem to be taking the matter quite seriously, at least google does. Take the matter of competitive programming: Peter Norvig says they were checking, if taking part in programming contests would correlate with good performance at the job [1]; I think having read somewhere that Norvig revised his negative judgement later on, as they had examined more data [2]. (actually that would mean that they didn't act on the data to begin with, well well).
These companies are good at data processing, any data that is, at least they seem to be taking it dead seriously (disclaimer: I never worked at google, though I have managed to fail at interviewing there, however i am not sure if i would have accepted an offer ;-)
[1] https://www.youtube.com/watch?v=DdmyUZCl75s
[2] https://en.wikipedia.org/wiki/Competitive_programming#Benefi...
If any of these companies knew what they were doing then they wouldn't require multiple interview rounds. I expect the correlation between one's ability to perform at Google with their ability to pass the interview gauntlet to be no better than a coin toss.
But I guess, that this is all speculation..
I do nothing that looks anything like leetcode whatsoever.
It’s hazing. Nothing more.
That being said I’d rather work for a shop that had at least some code tests. I’ve worked in places with none and the code quality is about as shifty as you’d expect.
You’re right though — I might as well be saying they were also incredible bakers or skaters. If those were also high signal identifiers of good devs then we’d be kneading dough while doing ollies in the interview rooms.
What irks our industry is that there are plenty of good developers out there that produce quality day to day plumbing and integration work that suck at leetcode. That’s fine. We should hire them too, but if you are FAANG you don’t need to if you have post grad leetcoders knocking down your door every day of the week to supplement your already burgeoning cadre of sensible staff engineers.
It’s easy to study leet code, and it’s relevant because it shows the interviewer you can write code.
I’ve had non-leet code interviews, like write some feature in 60minutes. It was fine. It tests code and knowledge as opposed to just algorithms and tricks.
I dunno I’ve always felt that the people who can’t leet code are the ones that complain about it. The ones that can just spend a bit of time to practice and ace the interview.
You mean the ones that randomly receive a random problem that they hadn't memorized before.
I'd say a lot of us learn about algorithms and data structures early in their career. But most of them are guidelines, not rules. So, you just remember how to google for them, not learning specific ones by heart. No one has ever told me: You need to work on this string manipulation and be done within 30mns.
So I dunno, it’s not fun doing the gimmicky leet code questions but it definitely filters candidates.
I think people in this thread take them for granted… many candidates struggle with them. The ones that think they’re easy and you just gotta study a little bit — they’re honestly probably pretty smart.
I have a million things I want to learn about. If a potential employer would rather I spend time on what amounts to trivia, then great, I don’t want to work there.
> I’ve had non-leet code interviews, like write some feature in 60minutes.
This is also a problem because it’s impossible to understand the constraints, context, specifications, etc. during this time. When I am asked to implement a feature in the real world, it takes time to understand the domain and context. Writing code is usually the last and easiest bit. It also never occurs that you need to understand and complete something in just an hour or two.
So in leetcode interviews you’re asked to turn on a bunch of knowledge you don’t really need. And in implement this feature interviews, you need to turn off a bunch of important knowledge and experience.
Both are irritating interviews.
The best way to interview, in my experience, is to ask about a project or projects someone has worked on. Even better if there’s time for them to present on it. That way you get a real world picture of their skills, they are comfortable, and you can ask detailed questions without jumping the shark. Further, it is perfectly reasonable for someone to be required to present and answer questions over something they’ve worked on in an hour or two. That does happen in the real world.
This doesn't scale and introduces a bunch of biases on other dimensions. People who don't have time to prepare for leetcode interviews might be the same ones that don't have time to work on FOSS, and it could be that they can barely talk about their past work for IP issues. It's also way easier to fake your way through a high-level discussion of a software engineering project (that the candidate prepared) than through a leetcode interviews.
I've interviewed hundreds of people over my career and I've never had an interview where I couldn't figure out their technical abilities through a conversation.
I'll tell you what leetcode interviews do find you though, they find you people that have no idea how TCP/HTTP work, they have no idea how you would debug a distributed system. They've never deployed anything to a server. They probably have no idea how to even measure the amount of work being performed by a server. They've never thought about CI/CD/Deployment/Scalability. They've never used any cloud resources. They have potentially never been through a code review.
etc, etc, etc, etc.
Someone crushing a leetcode test tells me about 1% of the stuff I'd like to know about their knowledge and abilities.
Some solutions are rejected on the spot (bad practices, does not solve the task correctly), other candidates are invited for a technical interview. Some generic questions, then we go through the solution - with emphasis on less than perfect areas. It is quite easy to see when someone is bluffing, and you also see how the person deals with feedback.
I am exceptionally good at algorithms problems and I recognize it is not a useful skill I want to filter on when hiring. A dev team of 20 may only need a few to really understand algorithms to look over relevant pull requests. and even then such situations may be rare
And that you just don't particularly see a need to cater to other people's made up (and sometimes downright farcical) rituals to such an excessive degree.
No matter how much money they may dangle in front of you.
> And that you just don't particularly see a need to cater to other people's made up (and sometimes downright farcical) rituals to such an excessive degree.
> No matter how much money they may dangle in front of you.
I confess to not understanding this take, money can purchase back a substantial portion of time. Working at big tech can fairly easily reduce your working life to 10 years if you spend conservatively. Outside of big tech the norm seems to be more towards 20-30.
The cost of those decades of saved time? About 100ish hours of prep for your first interview, 40-50 from there on (based on personal experience, conversations with my colleagues, and a friend who runs a FAANG interview class). Assuming 3 job hops in your 10 year working life, that's 200ish hours to save 20 years. Is there a reason you don't think that's worth it?
(1) Most chiefly, the egregiously unethical behavior of nearly all of the "big" players (the rest being merely moderately unethical)
(2) Reports from close friends of the day-to-day grind at these places (literally none have anything more than superficially positive to say about it; some have suffered significant health problems, include one full-scale nervous breakdown)
(3) And the intellectual dishonesty implicit in the LC process also, but only as icing on the cake, as it were.
And independent of all that - it is by no means a binary (either you work or for big tech, or you grind along at for an extra decade or two at middle range). There are high-paying opportunities out there, if that's what you're out for -- they just aren't as immediately obvious to find as FAANG.
Sounds like you'd need to spend some time to find these :)
To your other points, I get feeling revulsion to Google or Facebook, but I feel there are other companies like Netflix or Stripe that are ethically fine. The idea that the employees are generally overworked doesn't mesh with my lived experience the bay area, I have a fairly wide social circle and I don't know anyone putting in more than 40 hours a week at a big tech company unless they're trying to climb the ladder super fast. I think we also may have to agree to disagree on whether all leetcode is intellectually dishonest. 4 leetcode hard problems is a silly way to interview, but when working on problems at scale I appreciate a gut check problem on big O and an algorithmic workhorse like depth-first search or something.
Meanwhile your data points on 'N' and 'S' are appreciated and I will add them to my (mental) notes.
No I won’t get a job at a FAANG this way, but I’m not particularly fond of megacorps.
I've interviewed at plenty of them (only one in recent years, though) and while I wouldn't say they were easy, they aren't doing completely irrelevant challenges like leetcode.
I've certainly never studied for one, unless you count flipping through a book or two just to remind myself of things I may not have thought about in a while. Like 1-3 hours tops.
You don't have to dribble the ball, you don't have to answer a quiz about the rules of the game, you don't have to tackle anyone, you don't have to kick the ball, you don't have to be good at positioning yourself.
Clearly the test seems pretty odd as a way to pick players. But it has benefits as well. The expectations are clear. People who can't do it won't try. People who are in the ballpark and pass will feel special.
Grinding leetcode also shows you've got grit, and are willing to prepare for a task and do what it takes to succeed.
Grind leetcode, show the companies that you can meet their minimum threshold of cognitive and executive capability for entry into their tech department... or don't work for them, it's that simple.
If I ever do an on-site interview again, I’ve given thought to just bringing in a six pack of beer. If I get any bullshit questions, I break out the beer and say “how about we pretend that I did a good job on this question and talk shop about what you really need here, because that’s what I’d like to talk about.”
I've interviewed at a lot of other places and it's mostly take-home assignments or just talking about past projects or my open source projects. I've never had to do leetcode for an interview in 14 years of working as a software engineer.
Most startups I have applied to previously rarely asked ds/algo interview questions.
It's not that they want to, it's that they have to.
You have 10 dev positions in your team. You receive 5000 applications, where 3000 look like a suitable match based on the CV. How do you proceed?
It is a valid metric. It screens for "overachieving" types who have the will power to power through unpleasant drudgery for a pot of gold in the end. If they really want those kinds of people who am i say its 'silly'.
I think it is a case of this being the least worst option.
Not a great metric, but is there a replacement? Not everyone has github side projects to see how their code actually looks.
This is not about having to use leetcode type problems in day to day work.
Knowing about those is about a state of mind and a culture: that you are passionate about tech and have what it takes intellectually to dig very deep into it and not just another drone that learnt Java just because you knew it would give you a decent-paying job.