> Somewhat related, I noticed a surprising correlation between programming skills in the small, and programming skills in the large. You can solve a problem in five lines of code, or, if you try hard, in ten lines of code. If you consistently come up with concise solutions in the small, chances are large scale design will be simple as well.
Well, my anecdotal evidence doesn't support this.
I've done 500+ interviews for big tech, and often it is easy to spot people who have grinded leetcode. They excel at DSA, but fail at system design, or even low level design.
The thing is that overall I kind of agree with this article. Leetcode is great as a fun coding exercise. I also think they help the craft like katas help martial artist to practice.
The problem is when me getting the job depends on solving a coding puzzle. Sometimes I can solve a leetcode hard with ease and sometimes I get completely blocked in a medium one. Getting a job becomes more of a random toss than assessment of my skills. And yes, my company, and by extension me, are very guilty of this.
I think our observations are consistent: I would say that candidates ability to solve leetcode-style problem during an interview reveals very little of their ability to code in the small or in the large. "Algorithms during code interview" is a completely separate genre to what's discussed in the article.
To give a positive example here: when someone sends a 1k lines PR implementing a new big feature, how well a body of a single function is implemented is often a good predictor of whether the whole PR makes sense.
I'm not sure our observations are consistent. What I'm saying is that I've seen many times people who crush the DSA problem, but struggle to define clean APIs, write clear, maintainable and extensible code, or just design systems. In fact in some cases leetcode makes this worse, with it's emphasis on very terse code (e.g. single letter variables, all code in a single method, hard to understand coding constructs...).
About your second point, not to be a dick, but if someone on my team sent a 1k loc single PR for a big feature, I would sit down with them to have a conversation about why that is bad (I have indeed done this before).
I believe you're seeing people trying to game the interview system who think grinding Leetcode is all they need to do to become qualified as programmers. That isn't what Matklad is saying as far as I can. To keep up the analogy to physical training, you're not going to master or even get good at any particular sport, other than competitive lifting, just by lifting, but it provides a basis that makes all of your more specific practice easier and more efficient.
> Getting a job becomes more of a random toss than assessment of my skills.
I’ve coined a term for this throughout my long job search, it’s called the “leetcode lottery” (patent pending).
You can do a couple of hundred leetcode problems, but you’re still at the mercy of the Gods when your technical interview comes around. The worst part of this whole charade is that I come out of most interviews having learned nothing valuable and I can say the same for the interviewer. They haven’t learned about my strengths and weaknesses, etc.
I don’t have a better solution for how you can get an idea of my knowledge and skills over 2-3 hours of technical interviews though. And until someone does come up with a better idea, we’re stuck playing this game.
I think certification is essentially the same thing as having someone else interview the candidate, so it won't be better and is easier to game than interviews. Working together with someone on the kinds of problems you actually face is the most realistic way to assess a person's abilities on the work to be done because it's less of a proxy than anything else.
Yeah kind of. I think of it like DRY though. Most people aren't good at interviewing. Everyone does some random thing they think is better then the rest. But really it's uninformed. Just like you wouldn't implement your own hash map for most cases, you don't need to do a technical interview for everyone. I had one company do three seperate coding rounds. How many candidates do they have, what a waste of time for everyone.
> The problem is when me getting the job depends on solving a coding puzzle.
I have worked somewhere that we used online coding as part of our hiring process and it was valuable, but I agree that it's terrible as a gate. We used it because recruiters seemed to keep sending us people who can't write software, and it's just soul-destroying to sit down and interview people who are completely unable to do the job and had just sort of hoped we wouldn't check.
My favourite interview though was somebody whose coding was excellent, and I spent the interview trying to figure out whether she's acting the way she is because she's terrified, or because she's incompetent. Turns out she was terrified, she's Russian and our interview was her first time using English, a language she'd learned in the classroom, in real life -- and she'd only been in the country for about one day.
The reason I cared is, humans can't stay terrified for a prolonged period. No matter what's happening, even if it initially causes blind panic after not long they adjust to it. So if she was terrified that'll wear off after we hire her, which we did.
>They excel at DSA, but fail at system design, or even low level design.
Leetcode was the gate for a while, then system design was added on to it.
>Leetcode is great as a fun coding exercise. I also think they help the craft like katas help martial artist to practice.
I know this is completely subjective, but it bothers me to solve toy problems that people have likely already solved (and now ChatGPT might be able to point you in a general direction given a plainly written problem description).
And practicing it for a muscle reflex effect seems silly because you're unlikely to run into these again.
However on the flip side, even business problems which are composed of things that people have solved before still seem novel, so I'm more engaged on those kinds.
To be fair, if I am given any choice of leetcode I'll know the place isn't somewhere I want to work. I have little interest in that whole thing. I'm not grinding away hours and hours and hours of my life just so I can get denied in the fourth round, again.
I have done a bit of competitive programming, occasionally, but I have never been in a competition where there is a penalty for wrong submission.
You obviously have to fix your bugs to validate the answer, and you obviously lose time when you didn't make it right the first time and have to debug your code, but when it comes to ranking, the only thing that mattered is the time it takes to get a right answer.
But I agree that competitive programming can be a great exercise. Not just for the algorithm, but also for everything around the algorithm. For instance, you don't have time to waste parsing a list of integers. You have to get these parts right the first time almost without thinking, so that you can focus on the hard parts, like the algorithm. For example, if you are not confident that you parsed the input data correctly, you will lose time trying to figure out if you algorithm was wrong or if you fed it the wrong data.
> and you obviously lose time when you didn't make it right the first time and have to debug your code, but when it comes to ranking, the only thing that mattered is the time it takes to get a right answer
It seems possible this might be ICPC as well... I mean there is a time penalty, but it's still consistent with the literal wording of the description quoted above.
I'm not sure if you're making some kind of weird pedantic point, or if you're just mistaken.
The ICPC rules state "20 penalty minutes for every previously rejected run for that problem that was not rejected due to Compilation Error". The quote you referenced claimed "the only thing that mattered is the time it takes to get a right answer". Clearly the only thing that matters is not the time it takes to get a right answer: someone who gets the right answer with 1 failed submission and 30 minutes will end up behind someone else who gets the right answer with 0 failed submissions and 40 minutes.
While there often is no penalty for a wrong submission, the score you get for a correct submission very often depends on the number of attempts you needed. E.g. ICPC, topcoder, ...
I don’t doubt it is a very good skill to have, but have you found it making any bad habits? Like always having an external oracle you can rely on to tell your solution is correct or getting used to problems having a “right” solution?
I'd say just try it out and see how you feel. If you feel defeated and discouraged, then that's the end of it :) However, if you feel motivated to get better results, then you'll find the info you want easily (esp. how to solve the problem[s] that tripped you up)
IPSC ( https://ipsc.ksp.sk/ ) used to be my favorite until they stopped organizing it :'( - but you can still play with the problems and see how you would rank :)
I would advise against reading a bunch of materials first before you do your first contest -- a lot of those stuff are niche and probably doesn't feel different from leetcode grinding, so only do as much as you feel motivated to read and practice.
I definitely agree that it improves writing fewer bugs. When I first began using leetcode, I was proud that I was able to begin at leetcode medium and even solve the hard ones because the tip was to grind the easy ones before progressing to medium and hard problems. However, reading up on how DSA interviews are conducted, I realized that I probably would be penalized for not getting my solution right the first few times, whereas my style of solving leetcode problems at first was to get it right only after like the sixth+ try. Also, leetcode problems are also a good way to learn new languages, I'm currently using it to learn Rust, and learning Haskell probably would've been smoother if leetcode supported it.
I immersed myself in Competitive Programming this year and I'm very glad I did. I like it a lot for a couple of reasons:
It is a very nice challenge/sport. The skill ceiling is high but there are many high quality resources online. The rating systems on competitive websites makes seeing your improvement very rewarding.
It serves as an endless source of problem solving "ingenuity". Many problems have extremely elegant solutions. I find it especially satisfying to find subtle ideas/intuitions from one problem being applicable to another one.
I share that sentiment. I've been practicing Competitive Programming off-and-on for some years now. I still struggle a lot with it. But sometimes I manage to come up with a nice solution, and that makes it all worth it to me.
When I make no progress at all, I take comfort in an anecdote I once read about the statistician Jimmie Savage [1]:
"Jimmie had what he called 'a long-standing neurosis about Pólya-Szegö' (the most famous and long-lived problem book in analysis). Even when he was working on his first (and major) book in Paris, he was spending evenings on that neurosis. 'Pólya-Szegö humiliates me', he wrote. 'I never really know what's going on, but I can now work quite a few of the problems and seem to learn thereby some things of general interest.'" [2]
Thinking in terms of proofs — what the article mentions as properties and invariants — is what’s critical for writing correct code. This doesn’t necessarily depend on DSA knowledge, but it sure helps in developing the understanding. Likewise, writing code that scales performantly relies on an understanding of asymptotic and amortized runtime, which DSA provides the practical examples of.
I have been wanting to get into competitive programming. I am quite an experienced programmer. Is leetcode still applicable, or are there other sites that are more suited?
- Codeforces: https://codeforces.com/
the de facto standard community for competitive programmers, regular contests with editorials, huge archive of problems (https://codeforces.com/problemset) with pretty accurate difficulty ratings so you can focus on problems of suitable difficulty if you want to progress quickly. They also have an incipient EDU section: https://codeforces.com/edu/courses that covers basic algorithms with practice problems.
The problems are indeed of very high quality. But it can be a difficult place to start. For example, even the very first problem has an overflow gotcha built into it. Also, Kadane's Algorithm appears as an early problem even though several mathematicians and computer scientists failed to discover it: https://en.wikipedia.org/wiki/Maximum_subarray_problem#Histo...
Great resource, but it's hard to practice there as a beginner because there are no solutions (unless you solve the problem yourself). So you might have to get comfortable with being stuck. Which is fine when you're experienced, but will demotivate you if you're just starting.
> Debugging complex code is hard, first simplify, then debug
I've always made it a point to do a first pass just reading code and forming a hypothesis about the problem (which is often wildly wrong) before making any changes or even running it in a debugger.
If nothing else you usually find other oddities, and get more familiar with the code as written. It isn't fast but it tends towards being beneficial for more than just solving the specific bug at hand.
All practice is good, but in my view there is a large difference in quality between having a go yourself and memorising the current state of the art implementation.
ie does memorising large tracts of poetry make you a great poet?
I think if you do a technical exam - then it should be done in a way that explores how people think - not what they have memorized.
My theory is that origially the variable name "i" meant "index", and then when someone needed one or two more temporary variables, they added "j" and "k".
Oh, here's a more likely explanation:
> i and j have typically been used as subscripts in quite a bit of math for quite some time (e.g., even in papers that predate higher-level languages, you frequently see things like "Xi,j", especially in things like a summation).
> When they designed Fortran, they (apparently) decided to allow the same, so all variables starting with "I" through "N" default to integer, and all others to real (floating point).
There's a recent stream where @tsoding decides to learn Fortran, and soon enough the instructions tell him to turn off Fortran's implicit types with "IMPLICIT NONE". And so of course as a contrary person and with experience of many modern languages with lovely type inference he doesn't want to and... yeah, there's a reason for IMPLICIT NONE. That's not inference @tsoding, it's complete madness.
Well, my anecdotal evidence doesn't support this.
I've done 500+ interviews for big tech, and often it is easy to spot people who have grinded leetcode. They excel at DSA, but fail at system design, or even low level design.
The thing is that overall I kind of agree with this article. Leetcode is great as a fun coding exercise. I also think they help the craft like katas help martial artist to practice.
The problem is when me getting the job depends on solving a coding puzzle. Sometimes I can solve a leetcode hard with ease and sometimes I get completely blocked in a medium one. Getting a job becomes more of a random toss than assessment of my skills. And yes, my company, and by extension me, are very guilty of this.