I believe leetcode is a way to skirt around discriminatory hiring practices. It’s not at all representative of most work environments. Some want to pretend they’re cognitive wizards, but many of the algorithms used to solve problems took years to develop. 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. This process benefits individuals who have the luxury of time to spend preping. Something minorities, working parents, etc. don’t have.
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.
It's just as easy to argue that leetcode-style interviews are because companies are afraid of being discriminatory in hiring. If you aren't allowed to consider culture fit (because it's discriminatory) or education (because it's discriminatory) or give take home work (because it's discriminatory against people with time constraints) or trust your feelings in a qualitative interview (because they're discriminatory), what can you do? Solving real engineering problems takes too long for an interview, and full-day interviews are also discriminatory against people with time constraints. You can candidates give some automated algorithms problem solving test- that's what you can do.
If leetcode is intended to avoid discrimination, in my opinion it fails miserably. As the parent poster mentioned, it certainly rules out people that don't have the resources to study, but it also rules out another class of people prone to panic disorders. I'll share my leetcode horror story to illustrate.
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.
>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
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.
No. Some people have panic and anxiety disorders and need professional help and/or medications to help them. It is this kind of tone deaf advice, “just prepare more, you’ll eventually get it!” that prevents people with a panic disorder from seeking professional help for years. It is like telling someone with diabetes to just try harder to produce insulin.
And how beneficial is telling people they have a mental disorder if they experience common issues that even healthy people experience? A mental disorder has to significantly impact your life for a long period. A symptom list that consists solely of freezing up when put on the spot in a rare high-stakes situation is not going to qualify. Any teacher can tell you this happens to everyone. Stop right in the middle of lecture, point at one student suddenly, and ask them a quick question that demands a quick answer and wait. The most common response will be "uh!uh!..." even when they know the answer. It's about the situation itself that people weren't ready for, not the specific facts they were asked about. You indeed need to practice retrieving information under the particular circumstances to build the confidence to not freeze up like that.
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...
Spoken exactly like someone who has never had the pleasure of experiencing the vicious and debilitating feedback loop of a panic attack. Of course everyone gets nervous when put on the spot; panic disorders go well beyond that, to the point where you might believe your death is imminent during something like a routine interview, and your fight or flight response kicks in. Rather than concentrating on the problem at hand, your mind is focused solely on survival.
> You indeed need to practice retrieving information under the particular circumstances to build the confidence to not freeze up like that.
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?
True, though a lot of times the professional help will mostly consist of coaching you through how to "prepare more and eventually get it." The block is around taking the steps that help you improve. Yeah, medication is sometimes necessary, but exposure is a huge component of many different kinds of therapy.
Meanwhile on the job nobody is surprised or angry if you need to look up basics because they know you have five languages under your belt and are actively using three of them.
Yeah exactly this. "Figure stuff out without looking anything up or running test cases to see what they produce or going on a walk to think about it" is just not a useful skillset at all. I have zero, and I mean zero, times done actual work under those conditions.
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 experienced this recently in a surprise 'shared screen' coding exercise the interviewers threw in at the last minute.
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.
At this point I'm convinced "candidate froze up" is the cause of most of the cases behind the "LOL 2/3 of our candidates can't even write a for loop" stories. I think it's really common.
Allow me to pile on here for perspective, in hopes there might be people who hire people on here who can take this into account...
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.
My crowning glory for the interview-stupids was relatively early in my career going in for a PHP interview, which was the language I was by far the most familiar with at the time and had written many thousands of lines in, and not being able to come up with the "->" syntax for method invocation & property access when I was up at the whiteboard. I used a dot-style instead, and realized only after I left that I'd totally fucked it up (writing some OO code on the whiteboard was just about the first thing they asked me to do, and the interview was really short after that...) I'm pretty sure I also mis-named some built in functions. I'm bad at retaining language-specific details and have since started reviewing a relevant language syntax minutes before an interview, which won't stick by the next day but usually does for a couple hours so I don't do anything too embarrassing. Not being able to put together two non-syntax-erroring lines in a language I wrote a few hundred useful lines of the day before, without a reference, is otherwise the norm for me. This has mattered zero times—except in interviews.
Do you want me to write fizzbuzz in proper syntax in some language I have on my resume and 'can do' but don't actually do every day without the help of an IDE? Forget it.
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
}
Don't have the {}? Who cares, you might be a python guy. Don't have the indentation? Meh you pass but my next question will be about formatting and what you think about applying a standard code style (and fail PRs automatically if it doesn't etc). You used % because your language uses that for MOD? Sure.
If it makes you feel any better, I can never remember BASH syntax. I have a gist where I keep all the common junk like for loops and array manipulation.
Never had that problem in other languages as I can generally remember after 3 or 4 repetitions but my brain just can't grasp BASH syntax.
The correct way to write more than 5 lines of bash is to delete the file and write it in python. You will thank yourself when you have to modify it later.
For some reason, I just can't remember things for life.
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).
Your post reminds me of a joke punchline which was something along the lines of "an engineer doesn't actually have to remember very much, they only need to know how to efficiently find the information when required"
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!
> 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
This happens to me all the time! You’ve described it so succinctly. How do you cope?
Some perspective from the interviewer side: just tell us straight up that you're panicking. While I can't guarantee that an elitist smug interviewer is going to always respond appropriately, I at least would make an effort to try to help you calm down, be it by removing trivial blockers (e.g. fixing some syntax blooper for you) or trying to paraphrase whatever you're trying to say but not finding the words for, or asking leading questions in the hope of bringing you back on track. A little dirty secret among interviewers is that we're supposed to be accountable for managing the direction and quality of the interview (i.e. one that devolves into a awkward staring contest is a failure on the interviewer's part for not interjecting appropriately)
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.
Slow breathing exercises and grounding (e.g., look at the things around you and name what they are) work well for me.
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.
This topic of “is leetcode necessary?” and the more general topic of software engineering hiring practices appear regularly on this forum, but this time is the first time I am seeing someone mention panic disorders/panic attacks as part of the interview process. Other people might have mentioned it before here, but I do try to peruse the threads that relate to interviewing.
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.
If you as a hiring manager have the choice to pick between two candidates, one of whom stays cool and productive under pressure, and the other who goes blank in emergencies, which would you prefer to have on your team? Stressful situations can occur in software engineering, including for example a moment where you realize production services are broken because of code you just deployed.
Interview pressure is nothing like an emergency. I'm cool as a cucumber in an emergency. Hell, I kind of love them. Interviews are another thing entirely.
[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.
I’m normally cool under pressure and able to solve technical problems quickly. But in a situation where what matters isn’t actually solving the problem but evaluating my performance and my brain goes into overdrive with perfectionism/meta thinking about what they are thinking about me to the point where I sometimes can’t even do basic math.
Exactly, I have been in such high pressure situations several times with directors and CIOs breathing down my neck, but surprisingly I am quite composed in such scenarios. Severity of the problem at hand is in fact liberating as it is easier to focus. But that is not the case with interviews, when there is a strong "me" factor in the thought process.
> 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
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.
If I were that hiring manager I would have the wisdom to know that this provides no signal whatsoever of how successful those people would be on my team.
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.
> If you as a hiring manager have the choice to pick between two candidates, one of whom stays cool and productive under pressure, and the other who goes blank in emergencies, which would you prefer to have on your team?
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.
Your comment is not factually incorrect, but it takes a lot of logical leaps. Let's say: if all other things were equal, would you want to hire a candidate who has worked with just 1 programming language throughout her career or someone with experience on 5 different programming languages?
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.
I think I'd want the smarter candidate regardless in a job like software development that is overwhelmingly based on quiet focus time. It's easier to help them work through the rare emergency, than to help a less-skilled employee work through literally everything else.
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.
In the production issues I've been involved with, I was not forbidden use of Google, API docs, consultation with others, etc., and I did not have to work out anything on a whiteboard.
> 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.
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.
> 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.
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.
Well, the test result is pass/fail, and if you can verify I worked at a previous company, then you know I passed. The legwork might be finding out what their interview is like.
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.
> Are you proposing waiving technical interviews for people who worked in "reputable" companies?
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.
I mean, if I ask each of the engineers at a company I'm about to join to do a live coding test, they'll just tell me to go away.
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.
You get to see their standards when you interview with them. You are free to decline their offer if you feel that the bar was too low, and maybe their engineers write bad code. On the other hand, they do not know the standards of the company you came from.
In 20+ years, I have rarely seen a technical interview actually be indicative of a team’s standards. I’ve seen good, bad, and much in between, but mostly I’ve found the “standards” communicated during the interview to be purely aspirational at best.
> We need a credential that counts as passing a technical interview
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.
An Engineering degree from even a prestigious University doesnt make you an Engineer in many disciplines. You have to go do a different credential to start putting together buildings and bridges.
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.
> An Engineering degree from even a prestigious University doesnt make you an Engineer in many disciplines.
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).
I think the suggestion is for something more like the Bar Exam.
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.
I think that most people here are mistaking the finger for the moon. If discrimination is really the reason why we have this kind of interviews, the problem to solve is discrimination and not the hiring process that is attempting to fix it or to hide it.
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.
> I think that most people here are mistaking the finger for the moon. If discrimination is really the reason why we have this kind of interviews, the problem to solve is discrimination and not the hiring process that is attempting to fix it or to hide it.
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.
No. One of the reasons those leetcode interviews happen is because existing credentials, such as a bachelor's degree, don't work. Adding another one that some hirers will value highly and others will be skeptical of doesn't solve anything.
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.
IMO, I think we just need a way of easily firing people if they suck. It's very very difficult to termi ate without fear of retribution so the barriers to entry just keep getting taller.
If we could take a gamble on people and see if they sink or swim we could give a lot more opportunities.
It's not hard. At virtually every small company I worked for, not only is there no leetcode bullshit, firing wankers is as easy as giving them the termination slip. US has at will employment, 'you've been fired' is literally all you need to say, no explanation is required. You get hired after a conversation with a CEO, in my experience the hiring and firing process are both completed in under an hour.
I work at big companies. It's basically impossible. You have to transfer them to Milton's basement office and pray their inflated self-evaluations make them look for a new job.
>I think we just need a way of easily firing people if they suck.
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.
Legally, it's easy. But getting the HR bureaucracy to go along with it is a long and unpleasant process. The last time I fired someone for doing no work at all and arguing over everything, it took about 8 months.
Unfortunately, my company is not unusual in this respect.
There are a lot of companies without HR. Due to my background I haven't been hired for for a company with an HR (other than contract work) for probably a decade. If you want to hire and fire people easily, look for small companies, usually less than 20 people. Beyond that the CEOs tend to get tired of dealing with human administrative tasks, so it gets offloaded to HR. CEOs have a lot more risk tolerance so naturally when HR gets involved they focus on saving their own asses (which usually means taking low-risk rather than highest profit) rather than the good of the company.
> We need a credential that counts as passing a technical interview
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.
The trainings and certifications won't let you bypass technical interviews though. There's still inherent distrust of them. We need a credential good enough that companies can trust.
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:
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.
Maybe run the testing and evaluation side of things at cost. The certifiers instead get profit from companies that subscribe to their certification verification program. There's a small fee for the employer to verify someone's certification is genuine. Part of the employer's contract with the certifier would be that anyone the employer hires who has been verified to be certified, when they've been employed at the company for a year, they owe the certifier a bonus. There's a second bonus at five years and that's the end of the payments. The certifier is incentivized to only certify workers who have genuine skills as those are the ones most likely to hit the one and five year milestones. Talent acquisition is expensive, as is employee turnover, so employers will not have an incentive to layoff employees right before their employment anniversary in an attempt to avoid the fee they owe the certifier. They'll find that the anniversary fee is a small price to pay for having been matched up with an employee with the actual skills the employer needs.
I took a brief look at a CS GRE test prep book from a Google search, and it probably doesn't cover the same things leetcode does, nor does it really test code writing ability (because it's multiple choice):
If the true purpose of algorithm tests was to be non-discriminatory, the interview and interviewee should not be able to see each other, their voices should be masked to hide nationality/accent, and resumes should not be viewed when solving the problems. I assure you I can still discriminate against a candidate both consciously and subconsciously during a live algorithm question now.
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?
I don't think that much thought has been put into it IMO. It's cargo culting the google interview process, and no standout success since google has a very different interview process to cargo cult copy.
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.
> favored the false negative over the false positive, which they explicitly and publicly state
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.
When they say they favor the false negative, that doesn't mean that false positive wont happen, is they would rather tradeoff a with a process that produces more false negatives if it produces less false positives because they have a firehose of applicants to chose from.
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.
>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.
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.
I have yet to meet someone who can talk the talk but can't walk the walk. But I am technical, so I think you need a technical person to evaluate that. The risk is when non-technical folks evaluate the technical and they can be fooled.
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.
It's very rare that people intend to be racist. Rather, they have intuition of what a "good programmer" is in their head, which is subjective, and thus more likely to be discriminatory. If you give them an leetcode question and a rubric to grade their performance, it's hard to deviate from that rubric to much unless if you're intending to discriminate.
>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.
This is probably very dated, but when I worked in biotech the interview process was just about 100% trying to find a "culture fit" (to be fair, in an industry about a thousand times more diverse than software) and politics. If the hiring manager brought someone in then you assumed it was on them to have screened for competence, and you wanted to figure out which candidate you'd like to work with, and/or figure out which candidate was favored by which person in power so you could vote advantageously.
It is common for up to mid-level jobs in finance and consulting to require doing on-the-fly modelling and analysis in Excel. I am pretty sure things like structural, mechanical, or chemical engineering also have substantial technical components to their interviews. While it is not done directly by the employer, board certification for doctors entails 8 hour long tests. Similarly, tradesmen like plumbers and electricians require in-depth written and practical tests for licensure. You can definitely dispute the practicality of these for the job vs. leetcode, but I really don't think that the rest of the world is getting jobs with a resume and a firm handshake.
> What makes software engineering so special that we need a different interview process?
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.
I have conducted a fair number of interviews and never been surprised at their on the job skills. I really don’t see much of a difference between interviewing people for coding positions and management etc.
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.
Interviews are, by definition, a way to discriminate candidates based on some criteria (using the dictionary meaning of word here). There are certain classes that are illegal to discriminate against (e.g. religion, ethnicity), but things like education are totally fair game. Airlines, for example, use physical fitness as a discrimination criteria under the rationale that a flight attendant must be able to function in the rare event of an emergency.
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.
I think the problem here is that any criteria you use to choose one person over another is discriminatory -- that's the dictionary definition of discrimination: the choice between multiple competing options.
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.
Giving each applicant a tailored test also opens yourself to allegations of discrimination.
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.
Is discrimination even illegal? I thought unless it was a protected class, discrimination is ok. Unless you're giving all black people a shittier test or something I feel like it's a long and expensive road ahead of someone pursuing legal action, with probably not much to gain and no attorney particularly interested unless it is some class action against a big company.
> I thought unless it was a protected class, discrimination is ok.
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.
Agreed it would be wise to consider lawsuits when hiring. I do think though that's only one part of the equation. What you want to really optimize for is maximizing profit. Maximized profit may mean paying out lawsuits is cheaper than losing good candidates or implementing a poor or ineffective hiring process. There's also the risk of implementing a hiring process for which the expense of minimizing lawsuits is greater than the potential lawsuits themselves.
> It's just as easy to argue that leetcode-style interviews are because companies are afraid of being discriminatory in hiring
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.
> Giving everyone the same coding interview is one of the most effective ways to remove interviewer bias.
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.
Leetcode or "just trust me" feels like a false dichotomy.
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.
My guess (I have no experience in the biotech industry) is that this is largely because you can't run an hour-long experiment with the candidate to test their competence. They must rely on a conversational technique. I don't know how much we can compare software with other industries.
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 think you could dream up some one-hour tasks if you really wanted to. The issue is that they'd be so obviously unrelated to overall job performance that the process would be self-evidently silly.
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.
> We know LeetCode style tests aren’t perfect, but they’re repeatable and the study material is free and widely available.
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.
> 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 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.
> 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.
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.
> First, is programming skill what this is actually measuring, and second, is programming skill what this is intended to measure?
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.
It sounds like we’re mostly in agreement. I’m not sure they are actually the right choice, because I tend to think that companies that are trying to operate at such a large scale would be better off having a broader set of type of people working in engineering, and they necessarily limit themselves too much by insisting on their interviewing approach, but I’ll admit that I’m bringing a lot of my own bias about what a good company looks like into that view of the world.
> 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 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.
> 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
That's how your manager is going to be hired, as well as all of his bosses on up.
SWE manager here, at multiple well known companies, and this isn't how it's worked at any of them. Some of them I've had to do leetcode interviews while at others, it was important to know aubergine who could vouch for your work. Could just be me but I've never experienced the "I just have a good feeling about this guy" supply t if interview.
"He goes golfing with Jerry" isn't going to eliminate bias, but you can absolutely get jobs in management on that basis. I don't think any of my managers could do a leetcode hard off hand, I may have worked at the wrong companies.
I assume your CIO also took a LC interview as well. I believe parent's point is that this front line hazing commanding competency is moot when orgs are hierarchical in nature and you needent step far up from a leaf node in an org chart to find someone hired on "just trust me, here's where I worked and what I did."
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.
Irrelevant - a CIO's job isn't to be a hands-on coder, it's to set a strategy and manage an organization. Companies do a good but if due diligence on that, which is why it's really hard to break into the executive ranks - you have to find an opportunity that can grow into leading a large team because no one will hire you to do so if you haven't before.
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.
This strikes me as one of those linguistic squabbles - along with changing the definition of literally to include figuratively - where we just need to accept that language evolves, and usages that may be historically correct aren’t necessarily justifiable in a modern context.
I also only use literally literally. I refuse to tell my daughter that "One small step for a man, one giant leap for mankind" effectively equates to "this one is for the bros!" or that "all men are created equal" doesn't apply to her. You've got 1400 years of English language momentum to overcome if you want to change the meanings of established words.
> I refuse to tell my daughter that "One small step for a man, one giant leap for mankind" effectively equates to "this one is for the bros!" or that "all men are created equal" doesn't apply to her.
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.
> 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.
> 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?
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.
Including the definition of literally to include figuratively reflects how it is used by many, and dictionaries should do that. But it's possible (and my hope is) that it eventually goes out of fashion as a filler word for twitter-facing teens trying to sound smart, and effectively goes back to meaning what it meant before, since its literal meaning is very useful and specific, and will stay relevant beyond historical use. The new "meaning" is really to be meaningless, which is not what I'd consider an advantageous mutation in the evolution analogy.
Thank you. I noticed this a lot on HN, but I don't know how to react. There is a common presumption that co-workers and managers will be men. It bothers me. I work in Asia where there are lots of talented women engineers. Each time I read one of those sentences, I do a double take!
I'm pretty sure most people over ~30 in the US were taught that was the correct form. Common usage has changed only very recently. At any rate, as long as using the feminine is fine, so's using the masculine. Some writers even use both, switching between them. Me, I much prefer the singular-they, because I don't think keeping masculine the standard is tenable or desirable, and I find writing that uses the feminine harder to read (because there's a vast body of existing writing that defaults to masculine and it's by far the bulk of all material I've read in my life, so if I see a feminine pronoun it throws me off for a second as my brain reflexively starts to try to figure out who exactly we're talking about—this is getting better as the practice is wider-spread, but c'mon, let's just use the singular-they) and because it doesn't tend to generate discussion about pronoun choice.
The issue with take homes is that they are at the beginning of the process where you might have hundreds of candidates. I won't invest several hours in that. Whereas on-sites are the last stage in the process, so it's better than 50-50 that I'll get an offer out of it. So in that case I'm happy to take the time.
Ace Greenberg from Bear Stearns (former US investment bank) used to say the trouble with hiring friends and family: "You get 100% of the dummies." Sure, you get a few good ones, but you also get the lousy ones.
In the context of the parent comment which described how leetcode-style interviews are discriminatory, you have just nicely described nicely why the leetcode-style interviews are because companies are afraid of APPEARING discriminatory in hiring, and provided other methods of plausibly-deniable discrimination.
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.
Wait isn't it only illegal to consider Race/religion/sexual orientation? Have these other criteria become officially illegal or just a possible lawsuit? I can't see how any company looking to build a good team wouldn't consider culture fit. One bad hire could tank a team so I'd imagine they are very cautious?
It's illegal to use proxy metrics that impact a protected class more than others. This is to prevent companies from discriminating by hiding behind tests whose main purpose isn't to match on skills needed for the job but to filter out members of protected classes. An employer can prohibit the wearing of a turban if it is a legitimate safety hazard. They can't prohibit it if the purpose is to ensure no Sikhs get hired. What's the purpose of leetcode? Does it map directly to a job's primary task or is it a way of filtering out certain protected classes such as those of an older age?
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.>>
What's legal varies by location, but even if it's not illegal to discriminate against the other criteria in the GP's list, a company may consider those factors and try to avoid that discrimination anyway. After all, you want the best candidate, regardless of what their home life is like.
Like anytime you're evaluating someone's compentency, find out what they view as a good example of their work and judge on that. Don't stick to any standardized hiring process, instead get to a burden of proof.
Yes it’s a substitution for practices that are illegal for the same reason we use the substitute. No need to be defensive about achieving intended results.
Yeah I agree I'm similar to you in that I'm a parent with 2 kids 16 years exp and these leetcode tests kick my butt.
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.
I'm doing the hiring for a small company. We do coding tests as part of our interview process. I know it can show false negatives but it rarely shows false positives (wrt coding ability).
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.
Ignoring whether leetcode itself is useful or not. Do you believe it's inherently unfair to discriminate in favour of people who dedicated more time to e.g. studying CS theory, contributing to open source projects, working on hobby projects, earning advanced degrees etc. ? All of those things require time and money (in opportunity costs).
No, I think those are great ways to stand out and demonstrate interest and side projects and degrees are more representative of actual work. Leetcode itself though seems to be used as a gatekeeper benefiting those with the luxury of time to do the grind. It doesn’t mean you’re necessarily getting more qualified candidates and are possibly excluding some folks who would be more than capable.
Finding people with too much free time is the entire point of leetcode. Companies want employees who will dedicate their life to their work. If you don't have time to grind leetcode employers feel that you won't have time to work 60 hours a week and spend your free time thinking about work.
I think it's more common that people just have the unexamined assumption that programming skill is more of a natural talent than it is, and also that these tools are an effective way to test for that talent.
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.
I think people have over updated on spending free time on leetcode is the only way to solve these problems, but as a undergrad doing internship interviews, the problems weren't that hard?
There are boot camps for developer interviews now. The practice is bad and it is inhumane. They will eventually go the way of other unintended gatekeeping disasters like the standardized high school/college tests.
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.
I do think it’s inherently unfair that high-paying jobs are placed behind arbitrary leetcode gates. Dedicating time because you’re passionate is great, but I’m not here to feed your hobby. My experience is that people who dedicate lots of time to development outside of work burn out around the senior engineer level because they never get to use the cool techniques they play with on their own time.
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.
"people who dedicate lots of time to development outside of work burn out around the senior engineer level"
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?
I would submit that humans cannot easily be ranked from “best” to “worst”; and even the most genuine attempts at doing so will only capture it for a moment in time as both the individuals’ skills and the business’ needs are constantly in flux.
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.
You can discriminate on skills relevant to the role. The issue here is that these are extremely weakly relevant, but discriminate on features not relevant to the role.
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".
Another way to look at it: If you were running your own small business, given the choice between a candidate who had more of "studying CS theory, contributing to open source projects, working on hobby projects, earning advanced degrees etc" compared to another candidate... which would you choose?
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.
I think you're right that it's a filter in favor of people who are willing to waste more time for their employer. I don't think it's unfair, just a bad hiring practice.
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.
I'd argue that exactly the opposite. It allows those who don't look or speak a certain way to shine. It allows people who don't have good contacts and family networks to demonstrate their capabilities.
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.
I too am supportive of using LeetCode-style easy problems. FizzBuzz used to be all the rage, but dummies have memorised that now. :)
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.
As someone who broke into the industry without formal CS education, contacts, or family networks and struggled to speak confidently and coherently in interviews, leetcode didn’t do anything for me except stress me out that much further.
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.
Having been in charge of hiring a few times I can absolutely tell you that coding problems are not motivated by a desire to "skirt around discrimination". There is no need to skirt around it, we could just do it, via whatever method of interview you want to propose.
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.
> 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.
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.
If you have a major bug in production and have to report to the CEO in 20 minutes, all kinds of soft skills that you can show in interviews are going to serve you vastly better than knowing a leetcode algorithm.
> 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.
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.
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?
> Why is the junior dev in charge of something so important?
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.
The situation you describe is not what you face in leetcode. The key here is "a problem space not seen before".
Bugs in production by definition are problems in a domain on which you are currently working and are familiar with. So yes in that case I would expect someone to work efficiently even under pressure.
But a problem in a completely new problem space no. Someone may know for example that a presented problem can be seen as graph traversal problem but may be blocked for the moment on the actual implementation of it. This is a context switching problem and not a performance problem.
I don't think it is fair that you are downvoted, the parallel you are presenting is a real question, eg. how much does being good at leetcode correlate with being good at solving production issues timely and efficiently? (Even if real life production issues are _not_ leetcode problems, but nobody said that.)
I don't think that there are any conclusive studies covering this, so both sides might be correct for all we know.
Your comment reminds me of the video where they ask white people in Berkeley, CA if voter id laws are racist. They say yes of course they’re racist because African Americans don’t have id as often, don’t have as much access to the internet, don’t know where the DMV is, etc.
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.
> Then they go to Harlem to ask people what they think of those comments.
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.
How are all these people that are unable to get an ID able to finance a car, pass an apartment background check, open a bank account, buy alcohol, obtain govt. assistance etc?
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.
Those polls also show that they strongly favor free IDs that are easy to obtain.
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.
You can select people to display in your man on the street interview segment to make it look like the average American doesn’t know who the President is.
Regardless of what some people in Harlem think, data shows that minorities are in fact much less likely to have government ID.
data shows that minorities are in fact much less likely to have government ID.
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.
That comment paper isn't actually debunking that specific survey. It's just essentially saying that proving that voter ID laws suppress minority votes is hard.
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.
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).
Hmm. I dare say you could make the same video in the UK but not about race, instead about about how "poor people can't afford ID". But, statistically it's still true, and the people who can't afford ID are working one of their two jobs (or unemployed) not walking around town during the day.
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.
You could possibly make the same video about literacy tests used in Jim Crow. The key thing is having a racist outcome and then finding metrics to achieve it with plausible deniability (I don't find it plausible that leetcode was put into place like this, but for voting it has a long history).
It’s somewhat unhelpful to lump all the questions that leetcode asks in one bucket. I’ve been coding for 25 years and have never once needed to apply any dynamic programming methods. But I did some leetcode prep recently when looking for a new job and reviewing some of the tree and graph algorithms wasn’t totally useless because those things do come up from time to time in regular dev work.
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.
That's fair, but you also don't usually get the luxury of telling the interviewer that you only studied the tree and graph problems so you won't be doing any dynamic programming questions they happen to ask.
What does being a minority have to do with freetime? Most of the people I worked with at my first faang were minorities. Seems like weird pandering. Also, If i'm going to pay someone 3-400k a year they better be able to whiteboard out some honestly pretty basic algorithms. They're paying the best, want to hire the 'best', and the 'best' can do this in addition to having systems knowledge or whatever. If you don't want to prepare or find it too difficult then you aren't worth 3-400k because there are enough people that can pass the bar at that price range. And to be honest, I don't think 'grinding' leetcode is really too much to ask for how much you are going to be paid. These complaints always come across as whiney people that want something for nothing. You have to compete.
It's woke nonsense. These tests are obviously color blind.
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.
So their argument is "Asians are diverse, with a wide range of earnings, therefore it's myth". Sorry, but it makes zero sense. You should stop reading obvious illogical propaganda from race activists.
Also Asians isn't the only minority group that outperforms whites.
HN won't let me reply to the parent, but I thought your model minority myth was potentially interesting.
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.
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’m not him but I read his comment as simply taking issue with the idea that it’s minorities in particular who don’t have time for that, rather than simply poor people. (The terms are not interchangeable, since there are many wealthy people who are members of a minority, and there are many poor white people)
I think GP meant 'poor' as in poverty. It goes with your examples of economic hardship and not having the free time for leetcodes. My charitably interpreting 2c, anyway.
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.
How do you not understand that many people with families or other external obligations wouldn’t have the luxury of spending 7 hours a week for multiple months on leetcode?
Like everything else, it's an opportunity cost. Personally, I think LC is a great return on time invested. It takes far less time and money than say, any of the traditional gatekeepers, even for example a CS degree, or even perhaps a good data structures and algorithms class that is semester long.
If they need to spend that level of time in order to do a few search or sort problems on a whiteboard I'd be concerned that they don't actually know algorithms or datastructures.
The kinds of questions most companies ask are not hard.
I am 35 years old and never even heard if a high school computer science course. I spent one period of my last semester assisting the network admin with maintenance tasks, which was the closest thing we had to AP computer anything, and only 2 students in my class had the privilege.
My pet conspiracy theory is that leetcode is used to exploit imposter syndrome in candidates. After going through an hourlong session where you came up with the less-than-optimal but correct solution, I think it's easy for the interviewers to seem "disappointed" and lowball the candidate with a worse position/salary.
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...
> I believe leetcode is a way to skirt around discriminatory hiring practices.
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.
Yep, I'm waiting for the next Duke Power type case to happen. When I worked for an Am Law 50, we were prohibited from giving coding tests during interviews for developer positions because they could be considered a proxy for a discriminatory metric. Fizz Buzz was the most we could get away with. Even then, it had to be a pencil and paper evaluation.
The time commitment is pretty minimal. It takes at most 50 hours of studying to get up to speed on leetcode style problems. There are only about 20 different types and once you learn the patterns they get a lot easier. Professional organizations in other fields require continuing education in excess of that to keep your credentials. If you can't free up 50 hours over the course of a few months that is a time management problem. Worst case you could just spend 1 hour of your work day preparing. Lots of people spend more than that on HN and other sites.
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.
"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."
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.
This is always the response, but it still doesn’t make any sense.
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.
If you're not willing to spend an hour every day practicing to get the job the employer doesn't want you. That's the point of leetcode interviews. Find the candidate who wants it the most.
Yes, thanks, we got that. The point is that it is inherently discriminatory against people who don't have the free time to devote to that.
....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.)
In my case it's drastically simpler and easier than the types of interviews I've had at places with even higher applicant demand like say Game Companies.
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.
Yes you are given the tools but given a novel problem from leetcode, how likely are you to solve it within the pressures and time constraints of an interview environment? And how is the problem solving process indicative of engineering competency? It misses on some key points, for example integrating DB queries, refactoring, clean code, good git commit messages. And I’d argue the biggest miss is evaluating how well you can read other peoples code.
I think it's a bit more nuanced than that. Speaking as someone w/ experience on the interviewer side, there are two types of interviewers: the smug ones that evaluate on whether the presented solution matches the one on the answer sheet and the experienced ones that evaluate on signals that correlate to job relevance. I aim to always have interviewees solve the question, even if it means I'm dictating parts to get them unblocked. Because the things I'm looking for are things like fluency w/ the tools, communication, basic understanding of how to apply techniques to a problem, etc, rather than whether they can capitulate on some very specific eureka moment.
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.
Why do you think it makes it more difficult for minority candidates than other interview process? I'd argue it's the opposite. Minority candidates have the same access to leetcode than anybody else.
You wrote: <<many of the algorithms used to solve problems took years to develop>>
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.
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.)
> How can we push harder to find better than average candidates?
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.)
Great follow-up, and great idea! I never considered asking that type of question. To extend further, ask people when they used the wrong data structure, how did they notice, and how did they fix.
Griggs v Ohio made employer IQ tests unlawful, so employers started requiring college degrees. With the push to "give everyone a degree", standards have dropped so now employers can no longer use a degree as a filter for IQ. Thus: leetcode interviews.
This is kind of like saying requiring a bachelor's degree is a way to skirt around discriminatory hiring practices.
Ignoring your racists and offensive remarks, getting a job does require studying and prepping, whether you simply study the fundamentals or leetcode.
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.
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.