https://www.amazon.com/Destroy-Tech-Startup-Three-Steps-eboo...
Based on my experience, you are most certainly correct that the companies using leetcode aren't following any line of reasoning, and certainly not one as sophisticated as what the parent is implying. Most decisions made by "leadership" are irrational and self-destructive as you describe there (your book looks very interesting btw).
However what the parent is claiming, as far as the effects of the leetcode interview process is certainly true. I also think that the parent is correct in that these, perhaps unintended, consequences of leetcode interview in attracting a docile though technically competed work force are beneficial to large organization.
I also think the parents second comment, about these consequences not being beneficial to startups ultimately aligns with your view: startups do great harm to themselves by mindlessly aping the behavior of big name tech cos, mostly out of ego and fear.
And once you hit LeetCode employee critical mass your culture becomes LeetCode employees. Management may have started it, but employees amplify and make it ubiquitous (especially engineers promoted to management/hire/fire).
Bingo. IMO this hits the nail absolutely on the head. $BigCo wants docile people who will show up and jump when they're told to jump without asking questions or making a fuss. And they'll throw a big bag of money at you to do so.
Obviously this is an incredibly narrow/limiting employment experience. But different strokes for different folks I guess
People just want to meet attractive people, compatibility be damned.
I'm glad I met my wife in 2010 before online dating became an utter cess pit.
We had one of those people as a client and thought his "special sauce" of Myers Briggs, some Neuroscience research test bullshit we had to build into the system and have people, and some bullshit matching algorithm based on astrological sign would be the next big thing. Of course it wasn't, but my boss was happy to take the guy's money to build it anyway.
The client actually told us that it would have ten million of users after three weeks of release, with basically no money spent on marketing. It did not. Nowhere close.
edit: sorry, just realised you are the author!! (lack of sleep - not work related ))). Great reading, really enjoyed it. "Sital" gonna be used as a nickname )) Thanks mate! :praise
So yes, that absolutely is who they are recruiting. It probably comes down to no more than believing big tech companies have the very best in the industry (ie. like being in an Ivy League school) and standardizing the hiring bar w/ other companies they're actively in competition with. More than obedience, it probably is the aspect that they're smart and determined to succeed.
Yup that's what it's about!
The problem with trying to test how good you are at the job is that you simply can't do it in a 1 hour (or even a 1 day) interview. You can however assess how smart somebody is, which is definitely correlated to job performance. It's also connected to growth potential - even if it were somehow possible to accurately measure how good a programmer a candidate is at the moment they are applying for the job, companies would still want to try to predict how good they are likely to be over the next few years.
Are you saying the Leetcode-style interview assesses how smart someone is?
If you don't get the answer, you might still be above that smartness threshold, but didn't get it for some other reason (didn't have time to study, didn't sleep enough the night before, interview anxiety, etc.).
I know we try to stay away from the “we’re smarter than you” vibe here because it’s gross, but pretending leetcode style questions don’t require some degree of complex thought is absurd.
I think it's unreasonable to expect people to spend their off time practicing these sorts of problems, in the same way we think it's unreasonable to require everyone interviewing to be working on personal development projects over the weekend. I suspect most working people simply do not have the time.
Nothing tells me more about someone that is full of it than simply being dismissive of others. I ask for an example to support your argument, instead you chose to be defensive and give me attitude.
Why not just give candidates a standard IQ test then? They are probably more reliable than Leetcode...
leetcode is the SAT for coding, not perfect, but at least it's close to fair play.
this is what everyone said a college degree was for. Or experience. Neither of which matter when a senior dev with 10 years of experience and two kids still has to find an hour or two a day for three months in a row to grind out textbook algorithms to fake problems. Just to switch their fucking job. Thanks to cargo-cult insanity, god help those stuck in miserable jobs that just want out.
Yes, they're rarely encountered in most day-to-day jobs. But that doesn't make them fake...
The actual solution for encountering a differential equation at work is wolfram alpha, not getting a pen and paper to apply heuristic knowledge on solving differential equations
It would be amazing if leetcode were like the SAT, and you could just get one good score and then never think about it again.
Anything like that would make it much lower-friction to switch between FAANGs (and friends), though, which I suspect is a big part of why they've settled on doing things this way.
In fact I believe software should have some qualification tests, e.g. general coding, database, cloud computing, etc. Like CPA for accountants. Each test should be valid for a few years in each category.
What some of the people in these comments seem to want though is some sort of standardized score/ranking system, which I suspect might lead to even more nightmarish outcomes than the current leetcode-y interview processes. (e.g. Employers setting absurdly high cutoff scores, choosing one applicant over another because simply because they scored a couple points higher, applicants grinding unimaginable amounts of unpaid hours to bump up their scores a bit, etc.)
As many other comments have indicated right here on Hacker News, professional licenses are commonplace for occupations such as plumbers, electricians, doctors, lawyers, and even many types of engineers.
I suppose that central governments (such as the US federal government) should offer licenses for myriad types of software engineers, hardware engineers, software architects, hardware engineers, and so on.
Wouldn't it help companies if they could choose to interview only candidates who were licensed as, say, a level three penetration tester (intermediate penetration tester) or a level five database architect (expert database architect)?
The whole "Let's reinvent the wheel mentality" surrounding software, The Internets, and hardware simultaneously bemuses and frightens me.
"The eye never has enough of seeing, nor the ear its fill of hearing. What has been will be again, what has been done will be done again; there is nothing new under the sun." King Solomon, Ecclesiastes.
and
"I only wish that wisdom were the kind of thing that flowed ... from the vessel that was full to the one that was empty." Plato, Symposium
Why don't we simply allow unqualified, blind, inebriated people to drive automobiles on public roads at whatever speed they would like? Why don't we let a guy who watched a bunch of YouTube videos call himself a brain surgeon, and perform brain surgery on people who don't even need brain surgery in the first place? Hey, wait, i've gotta gureaat idear: y botherr haviing aany ruuules at al! Sheesh.
Without rules, men simply return to a state of nature where life is short, brutish, and mean (Hobbes).
I just found this on Google...
****** Origin of Life is Nasty, Brutish, and Short
This expression comes from the author Thomas Hobbes, in his work Leviathan, from the year 1651. He believed that without a central government, there would be no culture, no society, and it would seem like all men were at war with one another. ******
The “Wild West” mentality of folks who seem to believe that rugged individualists (not federal agencies such as the US Department of Defense) built Silicon Valley, is perched atop the same type of popular, yet nonsensical, mythology (falsehood) as Horatio Alger's famous character who was actually named Ragged Dick. (Really, Ragged Dick was the character's name, I am not being facetious) who metaphorically pulled himself up by his bootstraps to rise from street urchin to CEO (who was a wealthy industrialist).
Imagine a military, any military, anywhere, anytime in human history, that didn't have ranks, titles, and gasp... tests which members had to pass to move up the ranks. How well do you suppose a military without ranks and without tests would fare in combat? Obviously, such as military would be in a state of hopeless disarray.
Licenses are not a necessary evil; they are a good, and proper way to identify and reward qualified professionals, while simultaneously enabling "the rest of us" to know, for example, who's a mere private, whom we can walk past without batting an eye, and who's a colonel, whom must stop and salute.
Imagine a hiring manager say, "Hey, this kid never went to college, but he's a freshly minted level one software engineer, I say we bring him in for an interview."
Why should every company need to create their own initial screening tests? Imagine a trucking company that needs to hire a truck driver with a particular type of commercial driver's license (CDL). In the employment advertisements they post, such companies almost invariably include verbiage such as, "Class A CDL required" or "Must have a Class B CDL." See? The candidate must have already passed an initial screening test, by acquiring a particular type of license, prior to being granted an interview.
This is obviously a huge benefit to both candidates and companies alike because it saves both sides a lot, and I mean, a lot, a lot, a lot... of time!
These days it is comically inane that tech candidates are normally expected to take an endless stream of initial screening tests to prove their mettle to each and every prospective employer (unless they were referred, famous, or for some other reason exempted from the requirement).
Imagine a CPA (certified public accountant) being required to pass a basic auditing test before he was granted an interview for a new job. Why would a company ask a CPA to take such a test? If a candidate is a CPA, then (unless, for example, he cheated on his CPA test, or suffered some sort of memory loss) he has already proven that he has a substantial amount of knowledge about auditing.
Yes, of course companies should administer their own tests. But professionals licenses can, and do, enable both candidates and companies to avoid the sort of initial screening test which companies commonly require of software engineering candidates. Currently initial screening tests, such as LeetCode, are a response by hiring companies that are typically deluged with a sea of unlicensed (and almost entirely unqualified) candidates, all of whom claim to be qualified.
There are React Boot Camp folks who can whip up a frontend in no time who are arguably more competent at this task than a PhD in Comp Sci, and there are PhDs in Comp Sci who never wrote a lick of code in their life.
Technology in software IS Political, and 30 years of development experience shows me various parallel worlds that are arguably better than our current one.
Someone who grew up coding and loves hacking as close to the bare metal as possible is worth more than a dozen of your certified software engineers.
Let me know when the world standardizes on a Comp “Sci” curriculum.
Actual computational science has very little to do with computers and software development, which is a thesis statement I will be happy to support if pressed. For now, I end my rant
How is it fair, it favors young graduates and people with lots of time to prepare tremendously. Would it seem sensible to you that every time a doctor applied for a job, even if he has 20 years of experience, he'd need to compete with recent medical school graduates on some first year medical school exam?
But if we're saying Leetcode is simply testing for IQ and not really for software engineering ability, why not just test for IQ? IQ tests are designed in a way that after a certain threshold it's pretty hard to improve in them - they actually test some innate ability. Leetcode tests how well you are prepared for Leetcode, and perhaps how well you do under stress. It correlates only slightly with intelligence and even less slightly with programming ability.
In other words, whatever it's intended to do, one of its primary functions in practice is to screen out people who are bright, driven...and poor, working long hours and trying to keep themselves and/or their families going.
That it's a bit of a sacrifice is the point. If you're naturally smart enough this stuff comes quickly, great. If not, you're going to have to work for it - that requires discipline most people don't have.
Better put, smart and/or determined to succeed.
Whether you realize it or not, you're advocating for keeping people who aren't already mid-to-upper-middle-class (among others) out of these kinds of tech companies. Anything that's designed to make you work hard extra, outside of work to learn separate skills just to pass interviews is guaranteed to make it disproportionately harder for people who are, for whatever reason, unable in practice to devote many hours of their free time to fairly complex technical studying.
No matter how "disciplined" they are, people already working 80 hours/week just to put food on the table don't have the luxury to be doing that. No matter how "smart and/or determined to succeed" they are, people raising 2 kids by themselves would be irresponsible to be doing that.
Now, maybe you think that kind of person should be denied an opportunity to join the super-1337 hackaz' club that is FAANG or whatever. Personally, I think that kind of classist gatekeeping is disgusting.
Ah, you're talking about those programming jobs that never require thinking about algorithms?
I've been working as a programmer—largely PHP, Java, Objective-C, and Swift—for over 20 years now, and never, in my work, have I been asked to invert a binary tree, reverse a singly-linked list, or any similarly contrived scenario.
There's a huge difference between "thinking about algorithms" in the most general sense of that phrase (which means basically any programmer who does any of their own design work) and in the sense of the particular "algorithms" that we learned in CS classes and are featured in Leetcode problems.
Search engine: read material about the heart of the problem from domain experts, try different approaches and then decide.
Leet Code exercises are a blight on our industry.
If you want a shibboleth just say so.
I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million DNA sequences and want to count the number of occurrences of each sequence" (could be hash table, could be any number of other solutions; he just balked and exited the interview).
Only if the person can get all that right would I even consider asking something more complicated.
Maybe he's just been around the block a sufficient number of times to have gotten tired of the standard SV "here's a hoop, jump through it, now do it again, and again and again" ritual that it likes to call "interviewing" for some reason.
Seriously - your questions are fine for junior or mid-level roles, but beyond that, you should have more important thinks to talk about. And both of you should be able to tell if the other is a bullshitter and/or a lightweight within about 30 minutes at most (and often far quicker than that) of a normal, focused technical conversation -- without having to specifically grill the other person, or otherwise put on the pretension that you're one whose bona fides are established beyond question, and they're the one who needs to jump through a sequence of hoops to prove that they are worthy of your time and attention.
Just cut the crap, get down to brass tacks, and talk what needs to be done as if they're a peer. That's all you have to do.
So usually I end up after 45 minutes finding that the candidate has more or less tapped themselves out at "make a hash table of string keys, use it to store counts" (OK for a very junior programmer) or "make a perfect minimal hash" (I help them get there if they don't know what those are) or "use a probabilistic counting filter". This is about all I need to make a determination.
If all you do in my interview is know that a hash table or other associative data structure is good for maintaining counts, that using a full ASCII byte to store symbols from { A G T C } is wasteful and compress the letters to 2 bits each, you can pack multiple 2 bits into bytes, and can write a function that codes and decodes such data, I'm happy and you get a pass. I'm even happy to sit there and help people through nearly all the steps of the codec. Not trying to trick anybody or select for obscure CS knowledxge.
To me the real question is, how much hinting is reasonable for the coding and decoding function? Many programmers (including senior ones) struggle to implement:
x <<= 2 # left shift the int to make room for the next item x |= pattern # or the new 2-bit item into the accumulator.
Since I never use bit munging in my day job (it's 90% python data science) should I really ding somebody for not knowing about left shift or or-assignment?
What I really don't get is why people immediately jump to trying to implement huffman coding, RLE, or lookbacks as a solution to reduce the size of the DNA string. I still wonder if how I present the question is giving everybody a fair chance to shine.
I think "key/value counts" is absolutely the correct starting answer. Anything after that is optimization. In the real world optimization comes at length through research, learning, grokking, reading, benchmarking, sleeping, mulling things over. The only way to short change that is knowing about those optimizations in advance, so might as well just ask about those algs specifically.
All that being said, I think it's an enlightening question. Thank you for sharing it! You've educated me. I've been coding a loooooooong time and didn't know about bloom counting filters specifically.
https://bmcbioinformatics.biomedcentral.com/articles/10.1186...
With Leetcode, you have to retake the test multiple times every few years when you change jobs for each company you apply to.
Leetcode would be a lot more tolerable if it was administered more like the bar exam or like medical exams. Whatever happened to DRY?
Which means... Always. Be. Leetcoding. Do the bare minimum at your job and then do LC the rest of the time. Because your job is just your job, but your career is LC. These companies don't yet realize they are optimizing for mercenaries that have no loyalty to the code nor the company.
On a slight tangent, some of the people over on Blind would sell their own mother for a tiny bump in TC. That mentality used to be limited to Wall St. or maybe Big 4 accounting firms, etc. But now it's the whole tech industry. I remember having a software job was a lot more fun, back around 2007ish. That culture is so foreign to me now.
Even having to pass such a test on a very aggressive set schedule—say, every 5 years—but only at those set times, would be better—for developers. Not for the companies hiring them.
Being able to quickly invert a binary tree and that kind of nonsense belongs in library code (at best). It's not something that the average developer should ever need to worry about the actual implementation of, let alone have to implement from scratch in under 30 minutes.
My coding question, for example,
You have a music player that should be playing a 900 song list randomly. You notice that you keep hearing a song being repeated during your drive and you are curious if its truly random. You also keep hitting skip in the hopes a particular song comes up. Write a piece of code that simulates this.
You should tell me three things; 1) the number of songs played before a repeat occurs 2) how many songs needed to be played before you played them all 3) after you succeed in playing them all, how many times has the most common song been played.
You can use libraries if you know them, and you can use the built in sort method in the language, I will google it for you if you don't remember the syntax.
This is the insanity to me, "Here, do this contrived task that doesn't represent anything you will be doing... to prove that you can do the job"
I once had a whiteboard interview for a senior engineer position where they demanded that I write it in syntactically correct python, indentions and all, on the whiteboard. I'm trying to talk about code at a high level with them meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method. It turned me off to the company as a whole and the entire interview went downhill from there.
Yes? Yes. Figuring out how to make a computer solve problems is very much the job of a software developer. They will only encounter harder and less well defined tasks in their actual job. If they can’t do this and you hire them that is like hiring an opera singer who is mute, or a baker who is deadly alergic to flour.
> putting them on the spot in an already tense situation and expecting them to code while you watch
There are mitigating factors one can do. We make sure our hiring managers let the candidates know that there will be a coding challenge. We ask the candidates if they prefer to chat while they work through the task or prefer to be left alone and we acomodate what they choose. We let them know that whatever style they prefer it won’t change anything.
> meanwhile they are deducting points because I assigned a dictionary key directly vs. using the dictonary's method
That sounds very unpleasant. Sorry to hear that. Interviews are a two way street. You are interviewed and at the same time you are interviewing them. I think you were right in judging them, and you dodged a bulet there.
By the sound of it you are a talented, and capable developer. It might be that you can’t imagine it, but there are people who apply for developer jobs, has a really good ability to talk about the job, they seemingly have the right experience, yet somehow they can’t program even super simple tasks. Even after you give them every acommodation immaginable to humankind. If you haven’t seen this yet you won’t believe it. If you have seen it you want a filter against this particular kind of candidate.
I’m not saying that this filter goes always well. Every filter ever invented had both false positives and false negatives. We might lose a briliant developer because some quirk of the task throws them. It is sad. We are trying to minimise the chances of this, but it certainly happens.
Yes.
> I'm disputing is your assertion that there is a correlation between doing the contrived problems under unrealistic conditions and future job performance.
You are projecting something here. You are saying, without any supporting evidence, that the problems are contrived. They are not. They are really the core of what me and my coworkers do day in and day out.
You are also saying that the conditions are unrealistic. What makes you think that?
You are right though I have no evidence they are contrived other than your example problem. The unrealistic working conditions though is indisputable, do you typically relay your google search's for syntax through your boss? Do you often work under extreme time pressure on problems you have never seen before? Perhaps you do, but I can tell you with certainty that it's not the norm in the industry to work in that way.
Indeed, this is a holy grail of the applicant funnel. If a tech-for-interviewing company comes up with a better way to remove the worst 50-ish% of applicants efficiently, they’ll have no worries about their future. (The overall applicant pool is significantly adversely skilled as compared to the have been or will be quickly hired pool.)
And they are, frankly, pretty bad at writing code because they have little empathy for the reader and greatly inflated sense of self worth. They’re the kind to use complicated C++ features or algorithms for little reason. Essentially, smart idiots.
They also believe in silly things like LC being a fair and rational way to evaluate candidates and don’t see the bias at all. “Eugh she’s an ugly woman, I think I’ll give her the LC hard and little help.”
There is another class who realizes how stupid LC is, but are happy to play the game to quickly accumulate power and prestige. They usually have psychopathic tendencies and aren’t great coworkers.
LC is great at hiring these types. Feel free to stick to it if you enjoy having them as coworkers.
I'm outside any major metro area, when we've needed to hire there haven only been a handful of people responding. When people come in for an interview it's been pretty easy to tell if they really can't code at all without making them actually code. I haven't found this to be challenging.
I suspect the issue is interviewing a large number of people in a short period of time. If you don't have 45 minutes or so to spend on each person, using automated leetcode style problems probably starts to seem like a pretty attractive way to weed people out.
Lastly, usually one or two people from my team would take part in interviews. If there aren't any developers available at interview time (i.e., it's a manager and a someone from HR), I can start to see how people without any real coding experience can make it through the process. Again, this is probably a place where automated testing looks like a reasonable solution.
Eventually, yes. But it takes time for them to start, time and money to onboard them, evaluate how they’re ramping up, then if not acceptable, to follow whatever performance management process is indicated by the company and local law, then transition whatever work they were doing. This could be several months and tens of thousands of dollars just to get back to a worse state than when you walked into interview that candidate.
Interviewing even slightly better than last year can pay large dividends.
# You have a music player that should be playing a 900 song list randomly.
# You notice that you keep hearing a song being repeated during your drive and
# you are curious if its truly random.
from collections import Counter
import random
r = random.Random()
songs = range(1,900)
unplayed = set(songs)
# You also keep hitting skip in the hopes a particular song comes up.
# Write a piece of code that simulates this. You should tell me three things;
# 1) the number of songs played before a repeat occurs
# 2) how many songs needed to be played before you played them all
# 3) after you succeed in playing them all, how many times has the most common song been played.
counter = Counter()
firstrepeat = None
totalplays = 0
while unplayed:
song = r.choice(songs)
unplayed -= set([song])
if firstrepeat is None and song in counter:
firstrepeat = len(counter)
counter[song] += 1
totalplays += 1
print(f"""
Number of songs played before a repeat: {firstrepeat}
Total number songs played: {totalplays}
Most common song: {counter.most_common()[0][0]}
How many times has the most common song was played: {counter.most_common()[0][1]}
""")
$ python3 foo.py
Number of songs played before a repeat: 50
Total number songs played: 7263
Most common song: 375
How many times has the most common song was played: 17One other thing, I just got a new car, and this was the first time I was using 'next' using bluetooth. So, as I was driving in, I was in my head trying to figure out whether the phone now only had 100 songs downloaded, or whether this bluetooth 'next' function on shuffle was picking a random song from the list, rather than 'next' on a shuffled list.
You might as well just stand behind them and breath down their neck for added effect.
Seriously, that's way too claustrophobic, and not to mention a huge practical annoyance -- for the added latency of having to ask you to google stuff for them and then give you the result somehow, instead of just letting them do it themselves, when all they want to do is get past this trite exercise and start having a real conversation.
Again, no different than having an Ivy League education. There are big advantages to scope/reach/opportunities in the industry.
At one point in my thesis defense, I derived several equations I hadn't seen before, on the fly, such as "What is the time resolved fluorescence of a fluorophore in 4-dimensional space?" and finally understanding ergodicity (https://en.wikipedia.org/wiki/Ergodicity).
My defense wasn't about determining if I was an expert and qualified to write a dissertation in my field (my questioners already knew that), but to determine if I was a well-rounded general intelligence capable of out-of-task prediction.
In my phd experience in the USA we had oral qualifying examinations which involved whiteboard derivations. The thesis defense after writing was really mostly focused on probing the results in the thesis.
Depending on your definition of success, I'd say determined to succeed could well be the same thing as obidience.
Personally, I believe the reason companies do LeetCode type questions is because everyone else is doing them and no one can agree on a better way. Large companies want a hiring process that scales and is relatively uniform and LeetCode questions meet that criteria. Is there a better way? Probably, but figuring out what that is takes time, effort, and investment and most companies don't want make that investment for something they may get wrong.
Basically, most everyone knows LeetCode is shit, but as long as everyone else is doing it, there's little incentive to change. If everyone is doing the same stupid thing, at least your company isn't falling behind. If you decide to do something different, there's a real possibility you could spend a bunch of time and effort only to make things worse.
The person watching on the other end can evaluate how far over 100 you got, whether or not your form matches best practice, and assess how you were breathing in case... you know... they hire you and then there's a business need for you to do 500 jumping jacks in five minutes.
They might not even end up hiring anyone different than they otherwise would.
First, it’s probably illegal in the USA due to ADA unless you could show that it tested something physically related to the job. Example: a big company is required to make accommodation for a, say, qualified analyst who is blind, but can reject a blind candidate for a job that required driving.
But after 45+ years of hiring programmers, the world hasn’t yet figured out which factors are germaine and which are not.
The trouble is, they actually can't do that because then the pool would change, quickly.
But I think like you say, what they did do was create a filter that only very patient and technically qualified candidates could get through. Beyond passing the filter, their very standardized process did not derive any useful information about candidates. But I feel pretty certain if they made an offer to every candidate and not just those on the pass side of the filter line, they would have seen some differences.
The other parts of the interview might be doing something per se useful, I suppose.
I thought it was just the leetcode, but it's the behavioral questions and system design exercises, too.
Eh, I'm coming across as cynical. I'll be fine--I just wish we (as an industry) had a better system.
Until, I don't have a job I'm not grinding leetcode. I also dislike people who refer to themselves as ex-faang. I really don't care.
Being able to tell a great story might not be highly valued at most orgs, but I think it's part of Amazon's culture and something they desire in their skilled positions.
I've noticed that Apple only uses simple leetcode-y style questions for its phone screens, but for their on-sites they ask very domain specific questions. It is interesting because if you're actually good at the domain you're interviewing for, they are very easy. If you're not they can be intractable. Its clear that each team puts a lot of thought into the interview process and I imagine Apple teams get a very high SNR, at least compared to Google / FB.
that being said, everybody talks about like leetcode tests for a week straight is the norm. I've recently been through the whole thing with several big tech companies and some smaller companies, and all of them only used them for the phone screen.
in fact with microsoft for various reasons they skipped my phone screen and I went straight to onsite, and there was no leetcoding involved at all. still some whiteboard coding, but rather about highly specialized problems relevant to my field, none of this algorithm puzzle bullshit.
It’s actually pretty hard and time consuming to come up with a mock scenario and evaluate it, especially when you also have your regular work to do.
Leetcode is seen as good enough and all the effort is on the interviewee. The current employees don’t see the pain and suckage. They already have a job and it’s not their problem.
That's a hard problem for some startup, not for FAANGs. They could do hundreds of those and keep switching them quite easily.
I think most companies are looking for the path of least resistance.
Probably the same people who think JIRA is a great project management tool :>) - when in fact, it (JIRA/Leetcode) gets used a lot, because it gets used a lot by other people - and for no other good reason.
> Big companies want people who are smart enough to do the work, but obedient enough to put up with all the bullshit that comes with working at a big company.
But then you also have the companies who see other companies do it, so they cargo cult. Those are companies you definitely want to avoid. Their entire stack is because of cargo culting not because of an engineering need.
I think you also have a few of the Bro Culture companies who do this as a hazing ritual.
The ego and status jockeying appeal of leetcode is very, very high and a lot of engineers just eat it up.
I think discussions of this topic which ignore the fact that there is a substantial population in our industry who fall into this trap are basically flawed.
I think part of the purpose is to cool competition between them.
Or Pixar which required you to excel in atleast one thing in your life
But overall that may be a good thing for society. If Google fired all their leet coders and replaced them with real engineers they would not need as many. And the biggest problem may be that there is a limited number of real engineers in the world. Companies have to figure out a way to make so with the people that are available.
nice gatekeeping. Shame on them for working to get a job they want.
You wouldn't let someone do surgery on you that hasn't been to medical school.
Culture is important at companies. Without it quality engineering can’t/won’t happen. People will rise to the bar set by their leadership unfortunately.
Example: The engineering of the Boeing 737 Max
Source: - https://www.netflix.com/title/81272421
> Ingenieurinnen und Ingenieure sind alleine oder – bei arbeitsteiliger Zusammenarbeit – mitverantwortlich für die Folgen ihrer beruflichen Arbeit sowie für die sorgfältige Wahrnehmung ihrer spezifischen Pflichten, die ihnen aufgrund ihrer Kompetenz und ihres Sachverstandes zukommen
Translated with Google translate:
> Engineers are solely or – in the case of collaborative work – jointly responsible for the Consequences of their professional work as well as for the physical performance of their specific duties, which are due to them due to their competence and their expertise
Carrying this responsibility is a (indirekt) requirement for being legally able to call yourself engineer here.
Edit: a Netflix movie is a form of entertainment and not a valid source.
You can hire the best artisans for your pot making company and make some of the best pots. However, sooner or later you will encounter problems like disparate outcomes of quality (due to different people having different standards of style, crafting and discipline), unpredictability and reliability.
An engineer role is to standardize processes and turn things like quality into a predictable outcome. It's not just about being good and not being bad.
What you are describing doesn’t match my lived experience in this industry
The quality of a product shouldn't rest solely on having faith that you hired good programmers by chance.
Instead in my day to day I'm able to recognize when a problem needs something beyond the braindead solution and a sense of roughly where the solution lies, and am able to then go do a bit of research on the topic.
Solving leetcode hard style problems in ~45 mins off the top of one's head is just not a problem many developers face in their jobs. I agree that these tests demonstrate some information, but the ability for that person to be a good developer is not among that signal.
Getting a random question from an infinite pool and completing it with fewer resources under a short time crunch is a different game.
The low-level/assembly course I took had tests that felt like puzzles, and those tests were a ton of fun to take. Can't say I've had the same feeling for leetcode puzzles.
You are just apologizing for fraternity hazing
A good engineer does not have to be a leet hacker, in the same way a good architect does not have to be a geeky concrete fanboy.
The former can deliver good software with less bugs, the latter might be able to, but are more likely to bikeshed endlessly, while being hamstrung by “best” practices that turn out to be inapplicable in a given domain, or even damaging.
Do wake me up when software engineering becomes a standardized practice that isn’t a mere cargo cult.
I swear, if I read one more comment about doctors and surgery and licensing I’m going to have to diverge on a rant exposing the multiple flaws in popular SE best practices.
Brilliant engineers don’t make safe planes. It’s actually teams with a culture of excellence and quality.
Source: - https://www.netflix.com/title/81272421
There is no standardized methodology in SE as of 2022 that has anything resembling actual science as it’s basis, or we would certainly have thrown out LC interview hazing by now.
Your comparison is inaccurate. You might as well rail against non-conservatory musicians who taught themselves to play.
For fields where software safety matters, THERE ARE ALREADY EXISTING LEGALLY ENFORCED CODING STANDARDS
In my mind, a real engineer really shines in the non technical aspect of things, like coordination, communication, prioritization, and getting hard questions answered. But that's just me, I'm curious what everyone else's experiences are.
Leetcoders just find the most efficient solution for the problem at hand. They don't see connections to other problems, whether current or potential. They're a scalpel when you really need a massage.
I've seen leetcoders throw away less-efficient, safer solutions just to implement something more efficient and clever. And when things fail, they're nowhere to be found. Too busy with whatever current Story they're on.
I think a bunch of this "engineers don't actually need to know stuff" comes from a generation that never had to deal with things that might kill people if it fails.
The right information is usually somewhere in the organization, but it isn’t shared or acted upon appropriately. The Challenger report is pretty clear that it was “an accident rooted in history”. They had a decade of data about O-ring performance in the cold, but it was ignored/overruled in the decision to launch. It certainly wasn’t the case that The New Guy just grabbed some rubber from the wrong shelf and blew up a space shuttle. The Mars Climate Orbiter was lost because of a metric vs imperial mixup, but it wasn’t one dev who capriciously decided to work in inches; there were whole teams that weren’t synced up.
Engineers certainly need to know something, but I’d bet the farm that a team of B+ engineers with good coordination can run circles around “rockstars” that won’t work together.
In fact, I'd go so far as to say that if a lone idiot can wreak havoc, it's usually a coordination problem further up.
For example, suppose your team generates and shares some kind of data. You want to change the wire format. You could just go ahead and do it, letting the chips fall where they may, but I think that's bad engineering/engineering management.
It'd be better to coordinate with the folks consuming the data. Can you make their migration easier? While you're making a breaking change, are there others that would make sense to roll in? Are there times when it'd be better/worse to roll out the new version? Being proactive about this sort of stuff seems like good engineering to me.
Terry Davis was a great engineer and he had the worst commutation skills you could imagine.
And I don't mean that as criticism, I mean ythat as "it is not their job"
The problem is not LC. The problem is companies not tailoring the interview to the position.
I've worked with many people much smarter than me. And I've watched smart, very technical engineers silo themselves off. And then I've watch smart technical engineers that make an effort to communicate and lead initiatives to improve the codebase, make arguments to management for tackling tech debt, and speak up during technical grooming to propose better solutions. And while the siloed off introvert might be able to write better code faster, the engineer that is looking at the whole picture makes an entire team move faster.
And just because in case of companies that purpose is often unspoken, doesn't mean it doesn't apply. And that's why leetcode and inane interview processes.
https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
People write all sorts of stuff on their resume. They took a C course in college 10 years ago and write C as a skill. They could be programming managers and not know what a pull request is.
I think its definitely gone too far, but basic coding proficiency is essential IMO.
Along with "if we all had to go through this shit, so should you".
IME its biggest defenders are people who were a little bit extra proud to have gotten a job at Google and I reckon its as much those types as much as upper management keeping it going.
Like frat hazing rituals the fact it intrinsically makes no sense is sort of beside the point. Like frat hazing rituals it'll have to be rooted out like a weed to actually go away coz it's well and truly baked in.
Maybe 1% of startups do this. The rest are shitting out the software equivalent of Juicero.
On top of that, the only people who can really get rid of leetcode are pretty much sr staff or principle engineers and high level HR people. It also doesn't get you promoted or paid more in most companies to go on a long project to change the interview process. Thus it doesn't get changed.
I estimate that leetcode will probably go away in many big companies in 5-15 years from now as today's sr engineers become the next sr management and founders that actually makes these decisions. Many startups today explicitly do not have leetcode interview loops, while 10 years ago many did have leetcode interview loops. When that generation of startups have their facebook that defines their decade and thus defines the next common interview fad, leetcode will start going away.
It also allows you have any engineer interview pretty much any other engineer, which makes interviews overall easier to do.
A point that I didn't see yet made. The truth is that lots (though of course not all) startup companies just have no idea what they are doing.
I had to deal with the complexities that imagined possible future scalability issues introduced into our stack when the whole customer base could be served by a raspberry pi, and it happened in multiple companies.
And it is not just infrastructure, but also code. I have to follow the twisted clean architecture rules and write tons of boilerplate code (that could make sense on the backend for a complex system) for a mobile app that is basically just a skin over a graphql API (basically no business logic on the client).
The same happens when hiring: we need top talent like FAANG companies do (but we can't pay for it), because we are awesome, where in reality anyone with a sceptical, product-focused mindset and a "get things done" attitude would do.
In my opinion this happens because we don't want to admit that our startups will likely not need the scalability for years, we won't need to follow fancy architecture patterns because our app is simple, and we could do well with developers who don't have top computer science skills.
"How you hire is whom you hire."
I have see an over reliance on leetcode style question in startups actually. May be more fairly, "we want to be google" style companies which is every startup. In fact some large companies have a more relaxed way of interviewing.
Which is why I love leetcode interviews: I get an insight at how a company, especially tech management, operates. During the dog-n-pony show interview, I will put up with it, but will definitely cast the company in a poor light. I tell companies that I am interviewing with that I will not prepare with leetcode (some will suggest it). I rather spend my time reading higher-level concepts. You know, the stuff that actually helps in modern software development.
I left out the word "big" in my quote. Companies of all sizes do leetcode interviews and want heads down and STFU type of developers.
"... However, employers do refer to the educational background to differentiate between high-quality workers and low-quality workers (Kasika, 2015). Consequently, individuals with higher-ability use their educational background to gain the "education signals" that allow them to move into high level and high wage positions"
In this case, the "educational background" is shown by solving leetcode-style algos.
[1] https://www.researchgate.net/publication/299509496_Signaling...
I wouldn't be so sure everyone realizes it doesn't measure anything relevant to actual job performance although it should be obvious (since nobody whiteboards algorithm puzzles all day in an actual job).
In all of these threads there will be many people saying they only want to hire the top% of developers (as if it was a strict linear scale, as opposed to hundreds of intertwined skills) and they justify leetcoding as the way to do that in a belief that top leetcoder is somehow a top software engineer, instead of realizing these are unrelated skillsets.
Leetcode rather measures whether you are into brutal cramming. Let's put it this way: the kind of people that fits this property is in my opinion often "a little bit special", i.e. not the kind of employee that in my experience both startups and big companies prefer.
those who will overwork, be on call 24/7, doing 10 men's jobs at once and can tolerate abuse from managers, because you want your stock options to vest
10 what now?
Not all big companies do, not all startups do and not all companies of sizes in between do. It's also a little bit up to the candidates to just not put up with the bs and stop the interview process or not even start it in the first place.
And in that case the leetcode interview may actually be very valid, and not even evil!
Is it actually? "Leetcode" is pretty much covered by 6.006 [0] or equivalent. You shouldn't have to "grind" or study for hours if you passed the class (your problem sets should more than cover what you'll do on the blackboard).
Anyone applying for a serious engineering job should have at least done one algorithm class. This is what leetcode filters for.
[0] https://ocw.mit.edu/courses/6-006-introduction-to-algorithms...
So it turns out that startups also want a culture of meaningless and arbitrary brainteasers instead of building cool shit that works?
You might ask, so why do startups do leetcode too? I heard startups are supposed to be, uh, innovating, developing new technology, and working on hard, meaningful problems? Shouldn't they want brilliant, super effective people, instead of smart-enough, obedient workers? Apparently not. Apparently they want the same workers bigcos want. The implication of this is left as an exercise to the reader.