5 ms·

I see these posts a lot, and I sort of disagree with where they are coming from so I'll play devils advocate. Leetcode is used to select for one of (or both of

I see these posts a lot, and I sort of disagree with where they are coming from so I'll play devils advocate. Leetcode is used to select for one of (or both of these) 2 things for the average IC hire: 1. Do you work hard (i.e a person who studies many problems, memorizes solutions, and regurgitates then) 2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question) Now in a vaccuum, my takeaway from someone who doesn't pass a leetcode question is that they are more likely to not be either of those (given no other information about them). In my opinion, solving at least one leetcode easy - medium question (maybe with some direction from the interviewer) should be the standard for any role where you need to code. And realistically, companies index less on leetcode skill as you become more senior or apply to more niche roles. And plenty of companies out there have bug squash rounds, system design, behaviorals, take homes, trivia, background specific questions, etc. Leetcode is usually not the be all end all for hires above entry level. Leetcode is not meant to magically select for the best engineers. Its simply another signal for the hiring committee to use.

poisonborz 2y ago
2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question) Leetcode questions can by definition never come close to real life problems - they are simply out of context. Working on a project even a few weeks will grant a smart person any insights he might actually need. The kind of out of the blue puzzle problem a leetcode presents is more akin to crosswords in old leisure magazines.
- dep_b 2y ago
  It took Dijkstra an hour to come up with the Dijkstra algorithm. Why would you expect me to do better?
fzeroracer 2y ago
> 1. Do you work hard (i.e a person who studies many problems, memorizes solutions, and regurgitates then) This isn't working hard. And you are competing with the people that are working smart. Such as people having a separate computer/screen to either look up the answer to a problem or ask an LLM to regurgitate some code you can transcribe. It selects for people that are dishonest. > 2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question) See above. A lot of the problems have nothing to do with real world coding scenarios. Do I need to pull out memoization and know how to work with grammar rules off the top of my head? Or the functionality of quad trees and how it applies to partitioning? No; I've literally never used them in my career and likely never will. What I do need as a software engineer is understanding the high level concepts and when to apply them and refresh myself on the use case when and if appropriate.
kristopolous 2y ago
It's skills that a 4-year college student learns at approximately 19 and then promptly does not use for their next 50 years of actually building things. It leaves out looking at the engineering skills it takes to put something past the finish line on budget. It's at best, an adjacent sideshow and at worse a proxy for ageism to preference people closer to 19 and less capable at getting quality software out the door. And maybe that's why the industry has such a damn hard time getting quality software out the door. Maybe. Here's a far better idea. Give them a broken build or crashed code or some other failure and ask them to fix it. If they can navigate around a system, diagnose a defect, find the cause, offer a patch, and match the coding/commenting style etc, that's an actual player you need, not someone who can still solve an algo question from their CS101B midterm exam at 37. This version can go deep as well. You can have separate branches and an issue tracker, maybe with the conversation of the bug already going. Maybe the comments have a patchfile that needs to be manually applied. Maybe the patch has a new bug in it ... Perhaps it's a red herring and addressing a similar but unrelated issue. Maybe it's a closed bug and a regression and nobody wrote a unit test for it. Maybe the unit test is there and it's up to the candidate to discover it or the unit test is out of date, buggy and useless. This is the real stuff. Get them to communicate after. Saying something like "the unit tests were broken" versus "I was unable to understand how to get them to work right so I moved on" ... That's a huge difference in attitude - only one of them is a team player.
- kristopolous 2y ago
  also if you're going to "timebox" be very very generous. If you think it takes 30 minutes, give them 5 hours and say you're being generous. I've known people who program things like jet engines and stuff that goes into space. They know their stuff, are super methodical and take their damn time to do it well. Quality programming is a rarely practiced time consuming art and you'd be lucky if you have 10% of your workforce doing it. Heck, you'd be lucky if you have 1%. Those people save the ship. I'm not one of them. When you meet them, they're like a different kind of human. If you timebox them to 30 minutes, the people who write mission-critical quality code will fail to get it in on time and be filtered out. These are the people who write those 10,000 word articles that appear on HN with carefully constructed schematics, equations, and code that you struggle to understand and bookmark to study later. On the other hand, if you give people 5 hours, I assure you, the morons will still obviously be morons and you give the "True" Engineers who take their craft dead seriously a chance to shine.
throwaway346434 2y ago
Yeah, no. Show me your GitHub commit history, and point out where you used some leetcode magic. Should be easy, right? Like every other week you'd be using it? Or... is 95% of code somewhat boring, and ideally maintainable?
varjag 2y ago
> 2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question) I'm sorry but it's incredible hubris to think you'll come up with say Dijkstra's algorithm during the interview from the first principles. The only reason you can do it is you studied it before.
- kristopolous 2y ago
  Right. I look at this like a Bayesian Chance of someone - seeing it before: 10% - being a liar: 5% - being the next Claude Shannon: 0.000001% So someone coming up with the right answer and claiming they've seen it is useless. Right answer and claiming they hadn't seen it is basically a guaranteed liar. You can use it to filter out the liars I guess. But you'll also filter out your Claude Shannons as well. Either way, it's a dumb test unless you're genuinely getting a steady stream of Princeton and Cambridge magna cum laudes waltzing through the door and can reliable bump the last two priors by a few decimal points.
weatherlite 2y ago
> 1. Do you work hard (i.e a person who studies many problems, memorizes solutions, and regurgitates then) Most people applying already have a job. And if they work hard its actually quite uncommon for them to have ample energy to do leetcode questions on the side. So you might get the opposite - you'll get candidates who aren't great performers in their current roles but used their extra energy to grind leetcode.
cranium 2y ago
I know people in the four quadrants of {no-hire, hire} x {would not pass LC, would pass LC}. In my world, conditioning on [would pass LC] does not improve the hire odds. Even worse: it misses out on the hire people with no formal training too busy to waste time on skills with little use outside of the interview (in the real world, they'd use a library).
- beezlebroxxxxxx 2y ago
  Spend enough time around hiring teams or recruiters and you'll see that 99% of them are simply very bad at hiring. They put almost no effort into a search. They can definitely find someone. But finding someone that is hired for their actual ability to solve the problems that the shop or team is working on is rare. Leetcode is just a way of culling the herd. The idea that it somehow reflects the requirements of the job are a useful fiction to obscure how little effort most teams and shops actually put into hiring.
johnnyanmac 2y ago
>And realistically, companies index less on leetcode skill as you become more senior or apply to more niche roles. when does this start? I'm over 8 years in and I'm tired of being told to make a dang NxM Bingo solver in 30 minutes. >Leetcode is not meant to magically select for the best engineers. I'd agree with you in 2022. in 2024, I'm being way more filtered out for questions that I get right but didn't solve fast enough, or with zero hints. I was never a leetcode savant (too many other things to study for, and LC is maybe 20% of my interviews) but I don't feel that much worse than 2 years ago. Companies just have sky high expectations and are on a bargain bin for 15+ year roles paying 5 year salaries.

poisonborz 2y ago

2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question) Leetcode questions can by definition never come close to real life problems - they are simply out of context. Working on a project even a few weeks will grant a smart person any insights he might actually need. The kind of out of the blue puzzle problem a leetcode presents is more akin to crosswords in old leisure magazines.

dep_b 2y ago
It took Dijkstra an hour to come up with the Dijkstra algorithm. Why would you expect me to do better?

fzeroracer 2y ago

> 1. Do you work hard (i.e a person who studies many problems, memorizes solutions, and regurgitates then) This isn't working hard. And you are competing with the people that are working smart. Such as people having a separate computer/screen to either look up the answer to a problem or ask an LLM to regurgitate some code you can transcribe. It selects for people that are dishonest. > 2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question) See above. A lot of the problems have nothing to do with real world coding scenarios. Do I need to pull out memoization and know how to work with grammar rules off the top of my head? Or the functionality of quad trees and how it applies to partitioning? No; I've literally never used them in my career and likely never will. What I do need as a software engineer is understanding the high level concepts and when to apply them and refresh myself on the use case when and if appropriate.

kristopolous 2y ago

It's skills that a 4-year college student learns at approximately 19 and then promptly does not use for their next 50 years of actually building things. It leaves out looking at the engineering skills it takes to put something past the finish line on budget. It's at best, an adjacent sideshow and at worse a proxy for ageism to preference people closer to 19 and less capable at getting quality software out the door. And maybe that's why the industry has such a damn hard time getting quality software out the door. Maybe. Here's a far better idea. Give them a broken build or crashed code or some other failure and ask them to fix it. If they can navigate around a system, diagnose a defect, find the cause, offer a patch, and match the coding/commenting style etc, that's an actual player you need, not someone who can still solve an algo question from their CS101B midterm exam at 37. This version can go deep as well. You can have separate branches and an issue tracker, maybe with the conversation of the bug already going. Maybe the comments have a patchfile that needs to be manually applied. Maybe the patch has a new bug in it ... Perhaps it's a red herring and addressing a similar but unrelated issue. Maybe it's a closed bug and a regression and nobody wrote a unit test for it. Maybe the unit test is there and it's up to the candidate to discover it or the unit test is out of date, buggy and useless. This is the real stuff. Get them to communicate after. Saying something like "the unit tests were broken" versus "I was unable to understand how to get them to work right so I moved on" ... That's a huge difference in attitude - only one of them is a team player.

kristopolous 2y ago
also if you're going to "timebox" be very very generous. If you think it takes 30 minutes, give them 5 hours and say you're being generous. I've known people who program things like jet engines and stuff that goes into space. They know their stuff, are super methodical and take their damn time to do it well. Quality programming is a rarely practiced time consuming art and you'd be lucky if you have 10% of your workforce doing it. Heck, you'd be lucky if you have 1%. Those people save the ship. I'm not one of them. When you meet them, they're like a different kind of human. If you timebox them to 30 minutes, the people who write mission-critical quality code will fail to get it in on time and be filtered out. These are the people who write those 10,000 word articles that appear on HN with carefully constructed schematics, equations, and code that you struggle to understand and bookmark to study later. On the other hand, if you give people 5 hours, I assure you, the morons will still obviously be morons and you give the "True" Engineers who take their craft dead seriously a chance to shine.

throwaway346434 2y ago

Yeah, no. Show me your GitHub commit history, and point out where you used some leetcode magic. Should be easy, right? Like every other week you'd be using it? Or... is 95% of code somewhat boring, and ideally maintainable?

varjag 2y ago

> 2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question) I'm sorry but it's incredible hubris to think you'll come up with say Dijkstra's algorithm during the interview from the first principles. The only reason you can do it is you studied it before.

kristopolous 2y ago
Right. I look at this like a Bayesian Chance of someone - seeing it before: 10% - being a liar: 5% - being the next Claude Shannon: 0.000001% So someone coming up with the right answer and claiming they've seen it is useless. Right answer and claiming they hadn't seen it is basically a guaranteed liar. You can use it to filter out the liars I guess. But you'll also filter out your Claude Shannons as well. Either way, it's a dumb test unless you're genuinely getting a steady stream of Princeton and Cambridge magna cum laudes waltzing through the door and can reliable bump the last two priors by a few decimal points.

weatherlite 2y ago

> 1. Do you work hard (i.e a person who studies many problems, memorizes solutions, and regurgitates then) Most people applying already have a job. And if they work hard its actually quite uncommon for them to have ample energy to do leetcode questions on the side. So you might get the opposite - you'll get candidates who aren't great performers in their current roles but used their extra energy to grind leetcode.

cranium 2y ago

I know people in the four quadrants of {no-hire, hire} x {would not pass LC, would pass LC}. In my world, conditioning on [would pass LC] does not improve the hire odds. Even worse: it misses out on the hire people with no formal training too busy to waste time on skills with little use outside of the interview (in the real world, they'd use a library).

beezlebroxxxxxx 2y ago
Spend enough time around hiring teams or recruiters and you'll see that 99% of them are simply very bad at hiring. They put almost no effort into a search. They can definitely find someone. But finding someone that is hired for their actual ability to solve the problems that the shop or team is working on is rare. Leetcode is just a way of culling the herd. The idea that it somehow reflects the requirements of the job are a useful fiction to obscure how little effort most teams and shops actually put into hiring.

johnnyanmac 2y ago

>And realistically, companies index less on leetcode skill as you become more senior or apply to more niche roles. when does this start? I'm over 8 years in and I'm tired of being told to make a dang NxM Bingo solver in 30 minutes. >Leetcode is not meant to magically select for the best engineers. I'd agree with you in 2022. in 2024, I'm being way more filtered out for questions that I get right but didn't solve fast enough, or with zero hints. I was never a leetcode savant (too many other things to study for, and LC is maybe 20% of my interviews) but I don't feel that much worse than 2 years ago. Companies just have sky high expectations and are on a bargain bin for 15+ year roles paying 5 year salaries.