At the time, I had been coding for 15 years in multiple languages. Out of the blue I got poked by a Facebook recruiter and on a lark decided to go through the process. I made it through the phone calls and screen-share coding sessions just fine. I went onsite and had a several interviews that went swimmingly.
Then near the end of the day, I ended up getting a whiteboard coding challenge that involved pretty simple array manipulation and my brain absolutely locked up. In retrospect it was comical, but at the time it was incredibly humiliating. There I was just alternately staring at the whiteboard and the interviewer with what I can only imagine to be the most hopeless expression. My brain fog absolutely impenetrable.
At this point in my life, I'm fairly familiar with the condition. Basically for some random reason, the thought pops into your head just how disastrous it would be if you failed at this thing you're being asked to do. Then your consciousness inevitably becomes obsessed with this thought and it's all you can think about. You start panicking and soon you have absolutely zero mental bandwidth to accomplish the task and your mind is basically singularly focused with getting out of this terrible situation. It sucks.
So, I'm always a little annoyed when I hear people say, "what's the big deal with a little leetcode?"
I mean, I get it, if I actually could not solve those problems, I would not be eligible for the job. But the reality of whiteboard leetcode is that you're not screening for people that can code, you're screening out people that can have panic attacks. In my opinion, it is borderline disability discrimination.
This is such a relatable description.
I don't think you even need a panic disorder to have this happen to you, this has happened to me a handful of times and it's absolutely the worst. It really is humiliating, totally ruins your day and you end up kicking yourself for several days after. I think this is just something that a lot of people do, like stage fright or something. The only way I know to avoid this is to do a lot of interviews with different companies that you don't really care about to get more confidence before you finally do get to the interview you care about, just so you don't choke during the one you want.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
Is that part of the job description now?
What are these characteristics that:
1. Are present in the day-to-day work of a great many impactful software engineers that employers want to hire?
and
2. Do not discriminate against gender, gender identity, race, national origin, faith, sexual orientation, veteran status, age, and any and all other characteristics that employers are forbidden from discriminating against?
and
3. Are present and can be easily recognized in a leetcode-style interview keeping in mind that the number of similarities/amount of overlap between leetcode-style and day-to-day software engineering work is very close to zero if not zero?
Having said that, I am sympathetic to companies not knowing what to do that is better. There are real tradeoffs with all approaches.
I kind of think if I were to design the hiring system from scratch I would 1. Hire essentially anyone interested at the entry level for low paying 6 months apprenticeships, and 2. Hire more senior people based on their resume alone, with aggressive use of performance improvement plans for underperformance after 6 month or so probationary periods. I'm sure this idea sucks too.
I couldn't even remember how to write a for loop in bash, something so familiar it would be like asking me to recite the alphabet. Utterly humiliating yet comical experience looking back.
A few years ago I was hiring for a non-coding role with a company that pops up here on HN periodically. The interview was entirely leetcode. I completely blew it because I was so flummoxed that this was how they were interviewing for the role. I tried asking some non-code related questions about the role and company and was shut down from even being able to ask - it was clear their expectation was that the interview process was a one-way street.
It wasn't the straw that broke the camel's back, but it was a chain of things that led me to finally conclude it was time to move on in my career. That is, jumping through these kinds of interviews might have been something I'd do at 20-something, but at 40-something I've got other options and am not willing to put up with it. The hiring process in the software industry is completely broken in how it assesses talent.
Can I write pseudo code that doesn't compile, is an amalgamation of various languages and probably understandable by anyone that can code even though there's probably no language w/ that syntax out there but it get the idea across perfectly? Sure!
foreach (number in numbersYouWantMeToFizzBuzz) {
if(number MOD 15 eq 0) print fizzbuzz
else if(number MOD 3 eq 0) print fizz
else if(number MOD 5 eq 0) print buzz
else print number
}
Despite being fairly experienced and having a rather solid grasp of Python/Go/JS/etc I still have to look up basic things like file modes (with bash syntax being especially notorious for being forgettable to me).
What I'm good at, however, is keeping references in my head, i.e. I know precisely what to Google to get the exact answer that I want. This way I compensate for my bad memory.
And for the record, I'm in my 20s. Sometimes I worry if it's going to take a toll on my career in the long run but so far it hasn't been much of a problem (apart from being a source of insecurities).
It's true for people working in technology due to the rapid pace of progress. As soon as we learn something it's out of date!
This happens to me all the time! You’ve described it so succinctly. How do you cope?
Ultimately, it is in the company's best interest for an interviewer to look past things like nervousness-induced panic attacks, and I've heard on numerous occasions that good interview sessions involve the interviewer and candidate working together rather than adversarially.
Once it gets past a certain threshold it gets harder, so being mindful that one is coming on and routing it before it gets into a positive feedback loop is very important. Leave the situation you're in, e.g. tell others that something has come up and you have to go.
I am really grateful that you brought up this point as well sharing as your own experience 'ryandvm. My own experience when I fail to think of an answer to a leetcode question is extremely similar if not identical. I would add that my own experience is always a silent panic similar to how I experience going on a rollercoaster. Many people will scream out loud when they are going down a rollercoaster; I just clench the safety/restraining bar really, really tight and look onward while clenching my teeth. I am surprised that it took this long in my career to hear similar feelings expressed by someone else, but I am grateful that it did.
Thanks again 'ryandvm! I really appreciate it.
[EDIT] What I'd liken an interview to isn't an emergency, but a date, a visit to the bank for a mortgage application when you're very much not sure whether you'll get it, participating in a talent show, and shopping for a car, all rolled in to one. That's closer to what it is, than an emergency. That also makes it very unlike nearly all activity anyone engages in at work, emergency or routine, social or solo, except for certain high-pressure sales or top executive jobs, maybe.
Great quote. Those feeling pretty much summarize to perfection the current fad of interviewing pressure.
As for those who code without guns to our heads, I'd take the candidate who ships well-tested code over the candidate who ships emergency code. Prefer few large fires over frequent small ones and just roll back.
Edit to add: The kinds of pressure experienced on the job are not at all the same as those experiences during an interview. "Doing well under pressure" is not a generic skill. Someone who freezes up during an interview may be the coolest head in the company while restoring a database backup during an outage, and vice versa.
It's completely different, not even remotely comparable.
The pressure during a real-world outage is not a big deal. It's collaborative, we're all trying to solve this. And the work that needs to be done is actual real work. I'm extremely good at that, so I basically feel no pressure at all no matter how high the stakes are.
Interview pressure though? Whole different monster. It's confrontational and I'm expected to basically do improv acting on topics that have nothing to do with the actual job while someone nitpicks and eyerolls every irrelevant nonsense.
It's probably correct to answer "the person with 5", but does it automatically prove that "# of languages under the belt" is a great metric for evaluating engineering prospects?
We can come up with all kinds of justification for the current state of engineering interviews, but most everyone conducting the intervews know that our methods are extremely primitive and are thirsty for a better path forward.
But just blanking when suddenly put on the spot happens to everyone. Human memory retrieval is a complicated process, nothing like a computer. You can have vast expertise in there but not be able to retrieve it instantly, unless of course you've practiced interviewing that very subject a lot recently.
This rings pretty true to me, thank you for sharing your experience.
Like a driving test and the training with parents/adults beforehand.
Even with some judgmental/skittish passengers its the same.
We need a credential that counts as passing a technical interview, so we don't have to take these tests for every single job that we apply to.
If I pass a coding test, stay at a company for a year, then apply to other companies, I'm going to subjected to coding tests even though I just passed one only a year ago. It's like companies are afraid that programmers will spontaneously forget how to program.
A credential's test is not limited by the very time constrained format of interviews. This means it could ask more questions to reduce false positives. People would be willing to invest time because it saves them the hassle of interviews in the future. A centralized testing entity could work to reduce cheating instead of every company having to do that themselves. Plus, administering this test would be full time jobs for folks, so it would likely be a higher quality test than what most companies give.
Well it’s not like the company you’re applying to has access to the test results from the company you’re leaving
> It's like companies are afraid that programmers will spontaneously forget how to program.
To be fair, I think most leetcoders agree that you need to practice regularly to keep your skills up. So if the point is to see how good you are at thinking algorithmically for the job you’re applying for, it makes sense that they’d want to see recent test results.
Every skill degrades without usage, but if you can verify that I've recently used it successfully, I'm not sure why I'm being tested on it again.
Which is a better signal? Passing a leetcode style interview, or 5+ years in a development role at a reputable company?
Yes, of course. If you have a degree from a recognized schools and many years of experience at the job, why would you be hazed on undergrad trivia you've forgotten decades ago?
None of my high school friends who went into accounting, finance, medicine, law, etc have this problem. What is it with the dysfunctional hiring BS in software development?
A surgeon with many experience at a top hospital most certainly does not get grilled on organic chemistry trivia from their undergrad classes when chaning jobs.
The reason I would ask this because I don't want to join a team that writes bad code.
They would tell me that each engineer did the same test and passed.
I would then say, "I don't believe you, I demand a live exercise so you can't cheat and help each other out". After all, their skills could have deteriorated since they joined!
People are only offended because companies don't believe our past demonstrations of competence.
So we could call that a degree? And have institutions that specialise in testing for it? And because some of those institutions will be better at measuring this, we could rank them?
I thought most people complaining about the current approach didn't like this one either.
Having a Medical Degree (Doctorate in Medicine), doesnt mean you are credentialed to be a practicing doctor either. Doctors btw dont get asked to "go diagnose this patient real quick" during their interviews.
Credentialism in tech is an interesting rabbit hole. We basically do have nurses vs doctors with degrees of speciality, but some places pay them all the same. Some places do pay the backend engineer differently from the front end guys.
Its well known that bare metal C engineers are not making as much as React devs in alot of cities, and most people seem to broadly agree the C engineer has a harder task than the React one.
So we would need to figure out whats the CNA/LPN/NP, doctor, general doctor, brain surgeon, and veterinarian of our fields. But it's not quite so simple right? We might think front end where you are grinding out simple React or PHP apps is easy, but if you are a front end dev on a billion plus dollar selling system or with very high stakes stuff going on you probably do want a "doctor level" dev right? You probably dont need the AI dev though (the brain surgeon) if we continue the analogy.
They might not be asked to do this because their board has already done it for them: https://www.abim.org/Media/h5whkrfe/internal-medicine.pdf
A US-centric view. My (Swiss) engineering degree certifies me as a software engineer ("ing. info. dipl. EPF", whose use is legally restricted to actual graduates).
At least in California, you don't have to go to law school to take this exam, and if you pass it you are just as qualified to practice law as someone who did go to law school. I doubt that happens very often but at least it's possible.
OTOH a Software Bar Exam would probably be much worse than the leetcode grind because it would inevitably become something you can only realistically pass right after finishing a very good CS degree, or equivalent study, in your 30's at the very latest. And it would become a de facto requirement for the better jobs, making the privilege bias even worse.
https://www.calbar.ca.gov/Admissions/Examinations/California...
A qualitative hiring interview would be perfectly fine if the interviewers had no discrimination in their minds. The real solution is having minds without it. It's probably a goal hard to achieve with grown up people. Easier with newborns. So any solution starts from their parents, grandparents, etc and will stretch over many generations. Education, mingle with people from every origin and background, etc, pick your favorites.
How many generations? Limiting ourselves to the USA think how long it took for women to get a vote since the Constitution and for an Obama to become president since the end of slavery. We can hope that the trend is accelerating but who knows what's going to happen next. The state of the rest of the Western world is not so different.
This is the optimum. Now the good because there will be interviews to do this year. Any stop gap solution would do but don't invest too much into it because if you don't remove the real problem any fix will be worked around.
Agree in that if discrimination is the problem, then thats the problem that needs fixed. But, if these companies really wanted to solve the problem of discrimination then they would be making efforts to do so besides leetcode.
I saw it mentioned earlier in this thread, people can subconsciously discriminate without necessarily realizing it from something as simple as seeing someone's name, their voice, appearance, etc. It's not that the hiring manager is consciously racist but they may have a picture in their head of what a "software engineer" looks or acts like, and if the candidate doesn't fit that mental model they are dismissed regardless of their skill.
In that case, why not anonymize the candidates as much as possible? Don't let the interviewee and interviewer see each other during the technical interview, don't even let those making hiring decisions see their name, distort the voice, etc. Make it as close as possible to "anonymous person A being asked technical questions from anonymous person B." Make the hiring decision and only then de-anonymize the candidate.
I recently had an interview for an ops role (sysadmin type) and was asked a series of PowerShell questions, normally no problem - but the interviewer wouldn't accept "I don't remember the exact cmdlet, but I could do Get-Command Get-xyz* to find it" as if they expected an encyclopedic knowledge of every powershell cmdlet ever made. On the actual job built-in help exists, google exists, KBs exist, etc. Why would I ever be expected to have all this information in memory when the resources to find the information I need is a keystroke away. Test for understanding theory and methodology, not specific commands/language function.
People still have to see people to work together unless we spend all our time in Matrix like cocoons. When they see each other and don't like what they see somebody gets fired or mobbed.
We can't expect companies to solve social problems. It's not what they are built for. They can hack around problems, create plausible deniability or anything else and that's all.
People solve social problems. I wasn't alive when they happened in the 50 / 60s but I saw recordings of people doing Civil Rights marches etc, not companies.
What we really need is for companies to stop trying so hard to find the absolute best most perfectest candidate that they screen out huge numbers who could have done the job but who missed some arbitrary keyword or coding test by a fraction.
If we could take a gamble on people and see if they sink or swim we could give a lot more opportunities.
It is very easy to fire someone, especially in the first 90 days. Most states are "at will," meaning you can fire anyone at any time for any reason (outside protected classes) and the employee can leave at any time.
Unfortunately, my company is not unusual in this respect.
This idea already exists in many forms. Pick any language, platform, or technical concept and there's someone offering training and certification.
It also describes the whole recruiting industry. "What if there was one person who did a lot of interviews and then presented just the best people to employers?"
It's an extremely human incentive alignment problem. Any certification program, interview farm, or bootcamp that makes more money when they produce more candidates will make quantity the goal, not quality. If you can figure out that problem, maybe there's a niche. Otherwise, it puts us right where we already are.
Most of the recruiters I deal with are only doing screens and maybe soft interviews -- I may be on the lower rungs of the ladder here though.
For the last point, I'll offer Offensive Security as an example because I have one of their certs. OS wants people in its programs as we're a source of income, obviously, but they don't get revenue from people passing. In fact, they get more revenue if you don't pass because they charge per attempt. They offer training for organizations too.
They also act as a verification service for their certifications:
https://help.offensive-security.com/hc/en-us/articles/360040...
The idea for a programming credential would be the same: an organization that offers training, doesn't make money on pass rates, and also is a trusted point of verification.
Some companies have offered to do technical interviews, then pass you to employers. This is a start, but it isn't industry wide.
We could call this a degree, perhaps in computer science?
This seems like an excellent idea!
Unfortunately my CS degree from a very-top school (CMU) counts for nothing in so many companies.
https://people.engr.tamu.edu/d-walker/Quals/GRE_CompSci_1.pd...
I guess one upside of these types of interviews is I've been able to disqualify candidates just because I don't like them and saying they didn't do well on the algorithm question as justification is a easy way to reject them without much explanation.
And what about every other field that doesn't use leetcode style interviews? Does a biotech company make their interviewees do lab work live? What makes software engineering so special that we need a different interview process?
Google had this process because they are very academia inspired and want to hire the best academics, with a college campus but better work experience, because they had very high back end scale requirements, where algorithms do matter. They also had a shit ton of applicants and favored the false negative over the false positive, which they explicitly and publicly state. You might be able to argue that scale doesn't matter as much at google anymore, but google has no reason to change its process since it first established it, and back then they really had those hard scaling problems to scale up.
The reason why the software profession tends to have extensive interviews is because we don't trust credentialing or even prior experience. [0] We don't want to hire the unskilled bozo who can talk and have brand name credentials but when you actually put them to work find they are not that good at all. So we actually test their skill as directly as possible with various forms of work sample testing with as long as an interview process the market will tolerate, which has stabilized to 5 - 7 hours, or an entire working day.
The beauty of this is that you don't need to get into a med school equivalent with it's crazy requirements, spend 10 years-ish of training and go into 6 figures of debt, get a residency / hazing ritual in a few limit slots in the USA and can come from almost any poor background or country even and eventually make more than most surgeons. In that light, needing to spend 3 months to hard core leetcode doesn't seem so bad.
[0] https://blog.codinghorror.com/why-cant-programmers-program/
And willing to take false positives -- good at grinding for interviews, bad at actual work -- and just carry that dead weight forever in order to get the true positives who keep the money machine whirring along.
I've come to realize this is hard for many to swallow, but as much as it feels unfair -- just like only hiring from Stanford and MIT -- it was an enlightened business decision for Google. The cost of the dead weight is a rounding error on some distant Sheet, and the opportunity cost of the false negatives can't be measured anyway.
I think they realize their process isn't perfect, and worse of all, all processes are imperfect and this is the tradeoff set they've chosen. Google also tracks how successful people are after the interview process, so there is a feedback loop inside it. I think it's partly why they dropped the degree requirement from applicants, because their internal data showed no correlation with internal google success.
I think leetcode is bad, and I've tried to get interview processes to change to go full work sample at my big tech with relevant coding exercises, but it's hard to do! And in some sub-specialites where you are implementing graph algorithms and more, a subset of algorithms is in many ways a relevant interview question.
I think slowly the industry is moving away from no-leetcode, but it's going to take a generation or two of startups to really succeed at that, and most vital of all, it has to become a FB / Google level company that defines the industry for the next decade. The current millenial and gen z wave suffering under the leetcode regime and think it's bad need to become the next directors of companies and push for no leetcode in their interview processes. This is just starting to happen which why you see some companies like slack doing no-leetcode in their interview process.
Before leetcode we had microsoft defining the industry interview process with bullshit lateral thinking puzzle questions, and now nobody knows about their existence, nobody complains about them on HN and you never, ever run into them. I think in 10-15 years, leetcode will be the same and we will all complain about impossible work sample coding exercises and take homes.
in other countries LC is not that common
I've never been challenged with algo questions - just purely day2day stuff, but those were software houses interviews mostly.
Leet code is the equivalent of math word problems. What they show is problem solving ability with algorithms and code. That's a different skill set. Almost like an IQ test.
>Does a biotech company make their interviewees do lab work live?
Not biotech, but according to my cousin, pharmaceutical research interviews are even more arbitrary. He had chat with 5 employees who asked questions about their own rather esoteric specialties. Most of the questions were completely unrelated to the work that he ended up doing, and my cousin thought that the interviewers themselves were unlikely to be able to answer each other's questions. Unlike leetcode, this isn't something you can predictably study. It just so happened that the labs my cousin had worked in happened to specialize in those same niches. There are so many qualified postdocs that want to move to industry that interviewers can afford to be picky.
The combination of absurd profitability (of which the tiny slice allocated to employees still seems like a lot) and a complete lack of any actual objective measure of quality.
Because there's no way to really test whether someone is good at programming other than hiring them and seeing how it goes, and because there is an effectively limitless amount of money to spend trying to organize a "solution" to this problem, and because learning enough about each candidate to make a properly educated guess doesn't "scale" enough for fast-growth companies, senior management has plenty of room and lots of incentive to look like they've got it figured out.
For some, this is following their creative whims; for most, it's "do what FAANG does because it must be working, look at all the money they make."
Anyway that's my opinion on it. If I ever have the power to change hiring at any large scale, I'll probably follow my own creative whims and make it even worse.
Leetcode style tests meanwhile are simply a waste of time. I might as well ask someone if they have seen that problem before and know the trick.
Here's an actual study with real data. All women failed the leetcode challenge when grilled (probably by a man). They all passed when allowed to do it in a low stress environment.
Just because a criteria doesn't match one's notion of "fairness" doesn't mean it's inherently a bad criteria. If Google wants to only hire people that are good at cracking leetcode and that ultimately leads them to have their current reputation of being out of touch, that's kinda on them.
The problem isn't discrimination, it's unfair discrimination -- that is, discrimination on the basis of something that should have no bearing on a decision to employ someone.
Any criteria you choose will rule out people who aren't able to optimize for those criteria for whatever reason. I believe that's OK, as long as you are aware of the tradeoffs and try as much as possible, in good faith, to minimize unfair criteria while maintaining those criteria that help you hire people who have the best ability (or potential ability) to do the job.
As for leet code vs an actually relevant test - I think this is probably laziness on the interviewer's part. Coming up with a good test (and keeping it up to date) is hard, and leet code questions are "good enough" to filter out the people who don't know what they are doing. Remember, most companies are fine with a high false negative rate if it keeps false positives low.
That is also my understanding, but everyone except young white males are in a protected class. Granted, young white males are pretty common in tech, but you would still be wise to design your HR practices in such a way as to avoid lawsuits.
From the hiring side, this is 100% correct. Giving everyone the same coding interview is one of the most effective ways to remove interviewer bias.
A lot of HN commenters advocate for a “just trust me” hiring process where they want the interviewer to just read their resume and have a quick chat to decide if the person should be hired, without any type of technical interview. That results in people hiring other people who are as similar to their own backgrounds as possible (everyone likes to think their own background and learning style is optimal).
We know LeetCode style tests aren’t perfect, but they’re repeatable and the study material is free and widely available.
> or give take home work (because it's discriminatory against people with time constraints)
IMO, this complaint is baseless. A lot of companies give the option of LeetCode style interviews or take-homes and almost everybody chooses the take-home.
The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.
I'm sympathetic to the hiring side argument. But, I don't think the parent comment is insinuating that no technical question or test be asked of the applicant. They're not insisting on trust, they're insisting on showing their own intelligence. They're saying that the test or technical question should be directly applicable to the job at hand, for the company at hand. You can just as easily ask every single person who applies the same specific questions for the role at hand in your company. You don't need to rely on generic leetcode questions if they don't specifically apply to the job at hand.
In other words, hiring needs to actually be specific and targeted rather than adopting the "cast a wide net and catch whatever we can" strategy that many places seem to employ.
9/10 it feels like the insistence on leetcode from hiring comes as an excuse for rather weak recruiting standards and practices.
Biotech interviews, for example, are usually conversational: what have you worked on before[0], how would you tackle this new problem, or troubleshoot a particular problem. There's this persistent meme that charlatans can BS their way though such an interview, but I really don't see how someone could learn enough to parrot their way through 4-5 x 45 minute meetings, often with fairly probing questions. It felt quite a bit like a thesis defense, in fact.
It's true that these aren't "repeatable": each applicant won't have exactly the same experience. This is "unbiased", in a sense[1], but has enormous variance: you're not only testing the applicant's aptitude, but also whether they've encountered this particular problem before. OTOH, tailoring the interview to each applicant' strengths might inject a little bias in exchange for a massive reduction in variance.
[0] It does help that candidates for these jobs had masters/PhDs, and therefore had at least one project they could discuss publicly.
[1] But not really...There's a subjective element to "code quality", fluency, whether the applicant wrote "enough" tests, etc.
The software industry is unique (or so we think) in that we can directly test a candidate to judge their competency in an hour, either by white-boarding or going over a take-home problem (or similar).
I'd argue that software is similar: projects don't falter because it takes someone five extra minutes to run a gel (or implement a red-black tree); they fall apart because people don't think about whether they ought to be doing that at all.
The most effective hiring process I've been through is one where there was basically no interview, I was given contract work to perform during which I was compensated for necessary company tasks with no real expectation of enduring relationship. After a few days of performing tasks to the satisfaction of the company, I was offered a permanent position.
Not only did this process eliminate the BS, it allowed me to perform a task in a relatively low-pressure but high yield setting while simultaneously not exploiting me (I got paid) and allowed the employer to see how I would actually behave as an employee. This is also the longest and most successful position I've held, partially because there is no lingering bitterness and hatefulness I've harbored at those expecting me to solve bullshit problems for free, like some kind of performing monkey.
One of the things that gets me here on the hiring side is that the ease of “grinding leetcode” as a strategy seems to defeat the entire purpose of it as an interview question. I don’t want to dismiss the value of someone being able to study a skill and learn it, but I see a lot of people fixated on rehearsing leetcode answers like they were magical incantations you recite to get jobs, there’s not always a lot of real learning happening. That’s not reflective of the kind of candidates I’d want to hire or the peers I’d want to work with.
> A lot of companies give the option of LeetCode style interviews or take-homes and almost everybody chooses the take-home.
If true I’d like to see more of this. No hiring process is good for everyone and I think flexibility can be a better way to make a process fair, but I haven’t seen much of it personally. I don’t think I’ve personally gotten a leetcode problem at an interview in years- takehome problems have been the more common screening tool, but I don’t think I’ve ever been offered a choice in the matter.
> The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.
I’m not sure this is entirely on the mark. On problem with takehome a is asymmetry. Most take home assignments I’ve gotten have come toward the end of an interview process, and there fine, but when I talk to more Junior folks it seems like they are often given hours long takehome problems before they ever talk to a human. That seems disrespectful of peoples time- it’s a lot to ask from someone who doesn’t even know if they are a fit or want your job yet.
In any case the hours long takehome is usually in addition to an bourse long set of interviews- not in lieu of them. Another common problem pre-Covid was that a lot of people just weren’t set up to work from home so it was harder to get the space and time to work on a project at home. I expect that’s probably changed a lot these days though.
I think that's irrelevant for FAANG and friends. They pay so high that they can afford to make their interviews so miserable and time-intensive to prepare for that tons of people never even try, purely as a first-pass filter. They don't care that you can prep for it, they just want it to be (exactly the right amount of) scary and unpleasant. The resulting, self-selected group probably is, in fact, far better on average than the set of all software developers, including those who never apply to those sorts of jobs (but might if the interviews were less awful). Furthermore I think that's why some results show that they could randomly select candidates and do about as well as the interview process does—sure, maybe, but they could not do that if the set of people applying wasn't already heavily biased to have a fairly high average skill level (& IQ, that's absolutely part of what they're filtering for).
Now, companies paying half or less what FAANG does and trying to do anything remotely similar, are simply making a mistake. People with a tolerance for and ability to pass those kinds of interviews are going to apply to the much-higher-paying options, not to your company.
This is something I completely agree with. I'm not so sure about the motivation though.
> The resulting, self-selected group probably is, in fact, far better on average than the set of all software developers, including those who never apply to those sorts of jobs (but might if the interviews were less awful). Furthermore I think that's why some results show that they could randomly select candidates and do about as well as the interview process does—sure, maybe, but they could not do that if the set of people applying wasn't already heavily biased to have a fairly high average skill level (& IQ, that's absolutely part of what they're filtering for).
This is where I disagree, and my disagreement comes in two parts. First, is programming skill what this is actually measuring, and second, is programming skill what this is intended to measure? I don't have hard data, but I'd guess no in both cases. I've certainly known plenty of early career people who get obsessed with leetcode grinding, and I've never known them to be any better on average than the people who don't fall into that trap. What they are better at is letting themselves be convinced they need to work long hours and burn themselves out for an opportunity. The cynic in me says that's what these companies are actually selecting for, although it's likely at least some people involved in the decision making aren't doing it consciously.
Yeah, no, and, no. I agree.
I don't think it's measuring programming skill. I think there's a strong enough correlation between that skill and being willing and able to study for & attempt their interviews that simply conducting them the way they do yields a set of candidates who would practically all be acceptable hires—but they can't drop the unpleasant and/or useless parts and make them easier, or that would stop being true. There are definitely lots of people who'd be good, or even great, that it excludes, but I don't think they care, probably regarding the cost of finding those folks as too high to be worth it. As it is, it barely even matters how good a job they do of weeding out candidates who show up. Most of them are probably good hires (for what FAANG is looking for, which is some combination of IQ and "how bad you want it", as far as I can tell).
> The cynic in me says that's what these companies are actually selecting for, although it's likely at least some people involved in the decision making aren't doing it consciously.
Heh, yeah, I agree that's likely part of it.
I think there's also a hazing component. Hazing is effective at creating strong in-group sentiment and bonding, in a hurry.
Overall, I think measuring programming ability has almost nothing to do with why they do what they do. I also don't think that necessarily means it's ineffective at achieving their goals. I think complaints about FAANG-type hiring, when directed at companies that pay in the top-tier, are misguided for that reason. I also hate them, and don't think they're good at measuring actual programming ability, but I think there's likely a non-crazy (though a smidge sociopathic or cruel, maybe) point of view from which they are the right thing for those companies to do.
I personally like take-home problems. It's hard for an employer to time-box them without resorting to basically leetcode though. I know that, as a student, I definitely spent many hours on them.
That's how your manager is going to be hired, as well as all of his bosses on up.
At some point a technical interview rightfully doesn't make sense for a role (at least by itself), some transition up the chain typically needs someone who trusts a technically competent person below them and uses their advice. These transition layers really require someone with business acumen and technical acumen which are often unicorns, not in these positions and if they are, are not in a position to command change upwards. You need to really understand business direction, financials, market pressure and so on while also understanding all the technical challenges. You also need people who don't override your assessments frequently.
What usually happens though, from my experience, is you have an interface in the hierarchy where someone above understands a touch of tech but is primarily business and human management focused and a person below them knows a little business but is primarily technical. The bias will typically ignore, override, or pressure the technical challenges based on business focus in this structure. That bias comes from someone who didn't take LC and doesn't understand the technology or problems often at all.
There's this weird mindset in the software industry that by hazing one another and pushing for only the most skilled engineers at leaf nodes of an org, we can command change upwards or at least make our lives better by filtering out incompetent teammates that make our lives more difficult. Meanwhile, none of this matters to me in the big picture if someone is technically incompetent up the chain yet is pushing technical decisions either directly or indirectly that makes life miserable for very technically competent staff. You can have the most competent staff in the world with incompetent leadership. In a best case they're hands off and have a nice gig where their department makes them look good while they do nothing. In a worst case, they get actively involved in areas they shouldn't.
One may argue this only happens in bad orgs, and that could be correct. In that case, the bad orgs vastly outnumber the good orgs. I don't think this is the case though. Technology is typically to some degree considered a cost center for any business, even technology focused companies (its a cost center until certain efforts prove their value). It's a means to an end to keep afloat and make money so business interests will always override technical interests and this is very often embedded in the very power structure of a given org. Someone above you didn't LC, someone just trusted them during their interview, and now they tell you what to do. Maybe they're competent and didn't need to, maybe they're not.
I have a good friend who was a world class (quantum) chemist well recognized in his field and a technologist by heart in an S&P 100 scale org. He held the role essentially akin to a Fellow or Senior Fellow at a place like Google in a Fortune 100 chemical industry leader (the next step up would be something like VP research IIRC). He was frequently overriden by VPs that had no inkling of the science or technology needed to accomplish the baseline innovation business that made them money. So no matter how competent he and his staff may have been, someone who didn't care or was incompetent around the issues commanded decisions that effected him and every department he lead. This is in an org where someone doing real daily scientific and technical groundwork was able to interact at executive levels. Some of this leadership probably couldn't identify lead on a periodic table if their life depended on it (and they might not need to, assuming they listen to people who can), yet to get to the role just below them, you needed to be a leader in your discipline.
Purely by chance, the last place I worked that had a CIO title, my LOB CIO probably would have had a good chance at passing a Leetcode interview, despite managing 10,000+ people.
No reasonable person is suggesting that we need to eschew historical context and nuance to redefine statements like these. At the same time, we should acknowledge that language isn’t immutable - as 1400 years of English language momentum can attest - and there’s nothing inherently wrong about its generational evolution.
If you make literally mean figuratively as well, it loses all meaning. In what context is that word ever useful? It describes literally everything. Making the language less expressive and more difficult to use is wrong.
In the same sense, is the idea that I now have to look when a particular piece was written to understand how to interpret the pronouns? How does that make the language better?
I'm all for improving the language. Slang, new words, new idioms, have at it. I just don't see how either of these changes improve the language.
We already interpret language through the lens of its era all the time.
For example, when's the last time you heard someone use the word "gay" to mean "happy" or "awful" to mean "awe-inspiring?" They have very different colloquial definitions today, but when I hear the Flintstones theme song I know what "have a gay old time" means, and when I go to church I know that the hymn "God of awful majesty" isn't sacrilegious.
[EDIT] fixed a mis-labeling.
If they want to be really undiscriminatory, the interviewer and interviewee need to not be able to see each other, and even real names (which can indicate gender and ethnicity) must be hidden.
When orchestras started doing auditions with candidates anonymous and behind screens, they ended up hiring a LOT more women and minorities - even when the selection committees had previously thought they were trying to be nondiscriminatory.
Deeply embedded biases are really hard to root out, even for ourselves.
The number of women increased, not so much the number of minorities[0].
[0]https://www.nytimes.com/2020/07/16/arts/music/blind-audition...
For others: https://www.eeoc.gov/age-discrimination
U.S. Equal Employment Opportunity Commission
Age Discrimination: <<The Age Discrimination in Employment Act (ADEA) forbids age discrimination against people who are age 40 or older. It does not protect workers under the age of 40, although some states have laws that protect younger workers from age discrimination.>>
* German academia has some incredibly stupid rules related to time-since-graduation, but age per se is a protected class.
The companies making you do this though likely don't want someone like me. They want someone young who will burn themselves out working 80 hours a week for them.
So I guess it's a good filter for me as well.
However, we don't ask employees to work anything like 80 hours a week. In fact, we track overtime hours (> 40hrs/wk) and pull the red "panic" lever when it goes above a threshold as a control for burnout.
But like you said, you're applying a filter too (if no coding test -> low overtime required). It probably has false negatives (my company), but it's worth it for you because you have found that it rarely shows false positives.
I'm sure what you're talking about happens too, but I've seen the other thing first hand a couple times so I know it can be less malicious than that.
Has it gotten worse in the last 5 years?
The practice is just a veiled hazing ritual meant to strip you of dignity and agency.
If it isn't meant to do that...well, guess what? That's what it is doing.
And if I study real hard and maybe take a boot camp, I can join one of the illustrious paragons of internet virtue such as Facebook (sorry, meta block chain addicts inc.) or Google to spread ad-tech throughout the known universe.
Most development jobs require very little CS theory or hobby projects to do the actual work. Most of what software engineers build are glorified CRUD apps. What those things tell a prospective employer is that you’re willing and able to grind yourself to the bone.
Case in point: I’ve been hiring people from local minority jobs programs for entry level dev roles. Yes they’re green as heck (usually just a coding bootcamp) and we have to handhold them for a few months, but it gives mentorship opportunities to our mid-level devs and after 6 months of project work you’d be hard pressed to tell the difference.
Not everyone can take a couple years off work to go get an advanced degree. These jobs are not so hard they require one. Credential inflation is out of control, and trying to hyper-optimize individual achievement often ends up building poor teams. Give me someone with good work-life balance and priorities outside work any day.
Word. I left the industry to sit around my farm and raise my kids for about ten years. When I came back and started working with people I was shocked at how long it takes to learn anything about tech on the job. I was working on my own trying everything while I was away.
I noticed that my "senior" co-workers who had been working the previous whole ten years knew far less about the inner workings of the various tech they used daily than I did. I would rattle off something and expect a comment or answer and would repeatedly see architects and lead devs freeze up. I watched as they completely botched implementations simply because they didn't read the manual. The surprises were many because they used the same mental model to understand everything.
One implementation with a vendor required socket programming. They snapped and threw up their hands immediately in a big huff. I pointed out that C# had libraries to support that and that it was fairly trivial and probably way more fun than consuming a HTTP API. It took a few of us to calm them down and get it working but the dev who was assigned to it continued bitching. They were incensed at having to program against a TCP stream. It was so easy and trivial (imagine a binary string the size of an encoded JWT). He fucked it up bad and blamed the network for weeks.
In another instance, they were having trouble selecting a protocol for an external message passing framework. After selecting one at random I started asking about the protocol, mentioning that it sounded like it was based on "remoting (RMI binary non-routable transport). They had no idea. That concept of not having any idea about the underlying libraries and tech they selected was spread across an entire project, causing many real life disasters.
This all worked out great for me because I got use my deep knowledge a lot to identify root causes and fix thier messes which led to mahoosive salary increases and bonuses.
These bros were trying to leetcode everyone they hired. I couldn't do fizzbuzz to save my life. Just not interested in it. Is leetcode a filter to make sure you can work on the same old boring shit without losing it?
I don't understand. You clearly could take a spec "output numbers ..." and turn it into code, as you can take more complicated specs and code against them no problem.
If asked in an interview "Why should we use jitter when doing exponential backoff when packets fail", is that a more interesting question?
Is it the blank editor with no compiler/docs which makes it hard to write code, or the interview stress of someone watching?
How would you try and separate out the best of your co-workers from the rest in a day or two?
And yeah, I feel you can adequately gauge someone’s skill level across a technical subject area in 4 or 5 simple “how would you” questions. The way they explain it will tell you a lot about their understanding of the subject matter. In the old days (when we were in-person and I was still a technical SME) I would have them use a whiteboard to explain a technical concept to me.
This job is not that hard. I think a lot of companies have an overly fond view of themselves and most of these complex interview processes are for their own ego.
The argument is that leetcode is a means to dress up the latter as the former. Prima facie, this seems plausible. I dont think it's racially/etc. motivated -- I just think interviewers like people "like them", and leetcode selects for "like them".
Hiring is not about absolutes; it is about relatives (local maxima). When you work at an "elite" company, you quickly realise that you don't need to be a genius. For each open role, there must be 100 qualified candidates. As a candidate, you need to be a more-than-a-little-bit lucky to get the role! How does the hiring manager choose? Start with a baseline. Then pick the best.
Be curious to see numbers on burn-out rates between people who do practice leetcode to get hired and people who don't bother with it.
Our firm has every candidate take a quiz of five coding problems. Two of which are quite easy and the remainder a bit more difficult but none of them even approaching "leetcode" levels of difficulty. Even so, let's just say that most candidates don't do very well.
For a long time, I used an easy-to-understand, but hard-to-be-perfect interview problem: Please implement the classic C-function atoi() [string to int] in any language. (The candidate cannot use a built-in to do the parse!)
The best candidates immediately dissect the problem and start to ask about edge cases. The worst ask no questions and very rarely do a good job, and never think about test cases.
I’ve been able to stay comfortably employed and even climb the ranks in software dev for 7 years now, but had it not been for the company that first hired me eschewing the leetcode in favor of practical exercises in their interview, I wouldn’t have gotten in until a couple years later at minimum, assuming the resources required to continue studying held out (I was extremely cash-bare at that point, so absolutely not a given).
Now that I have years of experience under my belt it’s not as much of an issue — lots of places want to hire me regardless, but if I really had to I could drill leetcode for a couple months to prep for an interview. Back in the early days that wasn’t really practical, though.
However I have seen the "leetcode" process defeat discrimination at least once in my career, when HR was assuming a black guy was not qualified but he was able to prove himself on the white board.
There are plenty of good critiques about the whiteboard process, many of which I agree with, but this critique is silly.
Perhaps. I've been building software for over 30 years and I still find that I learn a lot when I practice and push myself to work quickly and efficiently.
> If you haven’t seen a particular problem before or had time to research it, it’s unrealistic to expect a candidate to solve it in twenty minutes in a high pressure situation.
Someone just slipped a bug into production. We now have $12,399 per minute in transactions that will not be processed. CEO needs a report for a board meeting in 20 minutes. Junior dev didn't show up and four team members were waiting for the commit he was supposed to have in yesterday. Dealing with high pressure problem solving is really every day, and practicing against the clock is a great way to learn to be calm and focused when it matters.
> For example, I work 50+ hours a week with two kids and a parent with cancer.
So sorry that you are dealing with cancer in your family's life. Cancer sucks.
While it's helpful to have rockstar devs that fix that kind of situation in 5 minutes, I'd say you still have to have boring people who test thoroughly, document properly, and have deployment procedures and rollbacks figured out, none of which is something you identify from a Leetcode type test; yet these practices which lower the chances for that scenario to happen in the first place.
> Junior dev didn't show up
Why is the junior dev in charge of something so important? What were the senior people working on instead that was more important than this? Sounds like he cracked under the pressure. Where was leadership?
I think you are blending all of those problems together (there are three - hopefully not all of them at the same time... that would be a worst day ever). It's pretty normal that someone can't get to work, and you end up with a last second scramble to get something fixed. When something ships into production and is buggy, what matters is fixing it quickly.
The point is that most developers do end up having to work under pressure from time to time, and the higher up you get, actually, the more critical it will be.
I don't think that there are any conclusive studies covering this, so both sides might be correct for all we know.
Then they go to Harlem to ask people what they think of those comments.
As for your claims themselves, In 3 months I studied 350 hours to pass the hardest test in finance while I was married, had three young children and worked full time. Nobody has time to do the things required to advance your career. You have to make the time.
For years, I also recruited and mentored students from an inner city bootcamp near me where the students spend 80-90 hours per week for 12 weeks learning software engineering. The vast majority of students are minority and there is fierce competition to hire graduates by local companies.
Maybe they should have asked in one of the states that is actually passing restrictive voter ID laws, and that is at the same time closing DMV offices in minority areas, limiting the hours that DMVs issue IDs, and has nearly non-existent affordable public transit.
The might have gotten different answers than asking in a state that is pro voter rights, in a neighborhood that has a DMV office, and that has excellent access to public transportation if for some reason the neighborhood DMV is not available.
In order for me to add my family to my insurance I had to provide identification for each of them, including a marriage certificate and drivers licenses for myself and my wife. All that just to get health insurance.
In order to vote you should have to identify yourself and that you are eligible to vote in a US election. It's complete nonsense that getting an ID in the US is just too much of a burden.
https://www.aclu.org/blog/voting-rights/voting-rights-act/al...
Almost no one opposed the idea of voter ID if it is free and easy for everyone who is eligible to vote to obtain such ID.
It's when shenanigans like those in North Carolina described in footnote 360 in this report [1] take place that it is a problem. The government knew that 25% of black voters lacked DMV-issued photo ID but the law provided that all government issued IDs would work (even expired ones), so that was fine. Then with race data in hand, the legislature amended the law to exclude most of those non-DMV IDs that black voters had, and retain the non-DMV IDs that white people were likely to have.
[1] https://www.usccr.gov/files/pubs/2018/Minority_Voting_Access...
Regardless of what some people in Harlem think, data shows that minorities are in fact much less likely to have government ID.
https://www.brennancenter.org/sites/default/files/legacy/d/d...
The study you provided was a phone survey of less than 1,000 people that occurred 15 years ago. It along with other studies showing similar results were debunked by researchers at Stanford, Yale, and the University of Pennsylvania.
The phone survey of less than a 1,000 people is still a perfectly valid piece of evidence. The methodology wasn't obviously flawed and the delta was so large that the sample size was more than enough.
Here's another survey from 2012 that shows a similar number.
http://www.projectvote.org/wp-content/uploads/2015/06/AMERIC...
Sure as your comment paper points out, you can't use nation wide data to prove state level causation, but there's still good evidence that minorities are much less likely to have government ID.
It's not a shocking result either. We know that not having ID correlates with low income, and minority status also correlates with low income (on average, sure there are some minorities that actually have higher income).
[1] https://www.aclu.org/other/oppose-voter-id-legislation-fact-...
The first reference on your link is the exact link to the exact study the other commenter provided.
The second reference on your link itself uses as a reference the exact link to the exact study the other commenter provided.
Free, state issued ID is part of the answer but the opportunity cost getting to a photo booth (!) is still a surprisingly large inhibitor given the stringent requirements on photos. (I do my own photos at home, you have to have a reasonable colour printer, I edit on the computer but you could probably do it on a smartphone nowadays).
If people of a particular background are over-represented amongst the [very] poor (such as "White Irish" in the UK) then they'll be disproportionately disenfranchised.
CFA is just a decoy.
I don't remember much of algo questions before 2010 outside of actual GOOG. If anything, OOP design like "for a game of chess" were common in LNKD-like companies. And j.u.c-like real life knowledge.
I remember being asked to implement quick sort or reverse a list in 2010 or so. Then to do DFS on a graph or detect all connected subareas of a matrix in 2015. DP questions were so new I din't know what they were back then. I had interviews last year with two out of three rounds being DP puzzles.
I don't know about junior engineers but I want to go outside at least on weekends and not think much about computers. So the hours I have for "studying" can be spent either on learning something new and useful (Flink? ML? golang generics?) or memorizing this mindless leetcoding. I've done development for too long to have any interest in algo trivia or problems not based in real life situations.
Often the same thing in for example, typical wall street firms before 2008.
I read that to mean that the tests are geared towards white candidates! Is that really what you mean? Coz I can't wrap my head around that!
And I bet Asians (a minority) , as usual, do better on them on average than the white candidates. Not because the tests are designed for Asians, but because of culture of studying hard.
https://thepractice.law.harvard.edu/article/the-model-minori...
Also Asians isn't the only minority group that outperforms whites.
In this case, it just doesn't stand up to facts. Yes, Asians have greater income disparity, because the top 1% of Asians are way at the top 1%. According to the U.S. Census (https://www.census.gov/data/tables/time-series/demo/income-p...) in every single year, Asians have out-incomed White and all-race averages in the 20th, 40th, 60th, 80th, and 95th percentiles.
That's a pretty compelling picture of "Asians make more money than whites," full stop.
Familial wealth provides an individual with more free time, generally.
More free time before a big interview means more leetcode prep time and memorization of the answers.
More leetcode prep time leads to passing leetcode interviews more often.
This isn't that complex.
It really bums me out when people reach for this kind of "how are you not getting this" slight. You could have just explained the reasoning without implying that the asker is an idiot. You're just making yourself harder to hear.
I don't have familial wealth and I can study for stuff. I happen to spend around an hour a day (most days) studying programming-related topics.
I'm sick of this woke nonsense pervading society.
Studying for a Leetcode exam has sweet-fuck-all to do with race!
I guess 'poor [edit: low on money] candidates' would be more precise.
You literally can get good at leetcode with an hour a day for a couple of months provided you studied computer science or even just like took AP Computer Science in high school. And even that just requires an internet connection.
The kinds of questions most companies ask are not hard.
I think this partially explains the phenomenon of external candidates at Google entering Google at the college-hire tier when they may have been repeatedly promoted at their prior employer. Of course the comp is usually more so it's not a big deal...
Can you flesh this out because you claim it but then provide nothing to back it up other than saying minorities don't have time, which just seems to be a strange and unsubstantiated claim.
To me these are far better for eliminating discrimination as the interviewer and interviewee can't see each other over a phone screen so there is no racial bias introduced, all you have is can the interviewee code. Plain and simple with far less chance for discrimination than a face to face interview.
It's about as close to the famed blind music auditions as we currently have.
Stephen Jay Gould's "Mismeasure of Man" appears to be defensive of minorities for protective colorization. The real problem Harvard has is that it is flooded with legacy admissions who couldn't test their way out of a paper bag -- people like Gould get funding because their work supports the interest of those people. By saying it is about minorities they get support from the general public.
Standardized testing is a path to opportunity for poor people and other outsiders to demonstrate their talent. It's true that some rich people can improve their results by spending money, but also true that some of them are as dumb as a post and the only way they are going to beat standardized tests is bring in a ringer to take the test for them.
In every other aspect of education rich people are much more able to "achievement launder" and use their parents money and connections to appear to punch above their weight. Standardized tests can keep the bottom 40% of those people out.
The bottom line is there are more qualified applicants than there are spots available. No matter how people are selected some group is going to feel unfairly treated.
This is actually such a bizarro answer I’m surprised it is getting tons of upvotes. All the techniques you learned in school can solve nearly every leetcode problem. You can get good at it with an internet connection and an hour a day. If you're going to work at my company for 2 years you better demonstrate you can do some preparation when there's literally 400 of you applying.
It’s been 15 years since I’ve been in school, and probably about 5 since the last time any of the things I learned there were relevant outside of interviews.
You can certainly get good at it with an internet connection and a hour every day. But that is 50% of the time I have left to myself after all my obligations are fulfilled.
Anyway, that’s not the issue. The issue is that the alghoritms tested for in leetcode are never relevant to the performance of my application.
....And it's also kind of disgusting to say that jobs should go to the people who are willing to sacrifice their free time to study utterly pointless interview questions just in order to "prove" to the employer that they "want it most". That's essentially selecting for those willing to worship at the altar of the company—corporate bootlickers. (Don't get me wrong, I can see why employers would want to select for bootlickers. I just think it's disgusting and shouldn't be allowed.)
There really is no comparison in difficulty from getting a few simple binary search or iteration questions from a FAANG company and the kinds of things higher end game studios ask you.
On the interviewee side, I think many candidates fall into the same mental trap as the smug interviewers; they think of it as a school test where you have to match the answer sheet. In reality it's more about selling yourself to the interviewer in between the lines.
I don't really buy the busy family argument; my wife finds time to practice leetcode despite having a full-time job and two kids in the house for a good half of the day. In my experience, people that work more hours per week than the local standard on software roles either have trouble setting expectations w/ stakeholders (and this ability is evaluated in unicorn interview loops for senior level and above) or they just volunteer to overwork when it isn't really necessary. I've seen high-paced environments where the family folks did a consistent 9-to-5 no problem. Extenuating circumstances like family cancer are indeed a valid concern, but at the same time, a minority of cases.
I've seen plenty of bitterness along the lines of "some ethnicities/age groups/etc just work too hard" or whatever, but at the end of the day, if we're talking about roles paying north of 200-300k/yr, the dynamics of the incentives will pretty much guarantee that one needs to put above average amount of effort into getting one of those jobs.
The thing is there are companies out there like Duolingo or Zapier that are willing to hire from non-hub locations and pay 6 digit salaries, and they may not even ask leetcode questions per se, but their hiring bars are very high nonetheless.
I completely agree. Many years ago, I was challenged during a telephone interview to determine if a linked list contained a cycle. At the time, I did not know about Floyd's cycle-finding algorithm. Of course, I failed the interview miserably, but the experience stayed with me for many years.
In 2014, there was a blog post about this exact algorithm and interview question: https://www.nomachetejuggling.com/2014/06/24/the-worst-progr...
I pounded the desk when I read it!
It was even discussed on HackerNews(!): https://news.ycombinator.com/item?id=7953725
One way to think about LeetCode is that it helps to expose you to 100+ obscure algorithms that might come up in an "elite-level" interview. Knowing them off the top of your head will either make your look like a robot / genius / both(!). Also, for interviews that require keyboard or whiteboard programming, "kata"[1] is undeniably good for your performance. Like anything, the more you practice, the better your performance will become.
Currently, we are interviewing at my office for software engineers. I always interview as a pair with the same person. We have slowly evolved our interviewed in an attempt to find a "local maxima" during a one hour time slot. No, we don't do whiteboard programming -- everything is f'in Zoom/WebEx these days!
I struggle with this: With the advent of Java and C#, a lot of average programmers know "enough" algorithms and data structures to get through an interview. How can we push harder to find better than average candidates? I don't know a good way without take-home programming assignments. Asking people to memorize 100 obscure computer science algorithms before an interview is just silly.
I would struggle to explain how a sorting algorithm works, but I know all about O-notation for time & space complexity of the best sorting algorithms. (My sort sizes aren't very large, so TimSort[2] works 99% for me.)
Just ask them where they needed to solve a problem with an algorithm, why/what they did, how they implemented, tested, validated. What other problems could use the same approach, how could the problem be changed to invalidate assumptions, and so on. etc.
(While writing I realised that this fails in cases where the interviewers are not competent enough to follow along in random directions, which then gives the rationale for a leetcode quiz - basically a battleship-game that the interviewer prepares in advance so that he can pace the discussion and grade the candidate.)
How is that different from learning any skill/profession?
Everywhere you gotta put time / effort.
The difference is that LC questions allow you to get highest paid jobs.
Average software shop probably does not require them.
The solution is to overturn Griggs v Ohio.
So making a test to see who you'll recruit is unlawful. I don't know what to say.
Yes, maybe we should consider leetcode interview as something of a rorschach-blotch. The interviewer can take the discussion in any direction he wants, under the pretence of "evaluating technical competence" or whatever.
Note: this is a genuine question, I am interested in understanding your view point.
I’ve been a software engineer and now architect for 15 years. Studying leetcode like problems won’t help me at my current job or a future employer once I get past their interview processes. What leetcode does do is make it difficult for minority candidates, those with external obligations, or those with families to get into firms. For example, I work 50+ hours a week with two kids and a parent with cancer. I work hard at work and have a lot of external obligations. I don’t have time or to study leecode problems.