Role of Algorithms
matklad.github.io
matklad.github.io
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.
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.
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’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 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.
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.
- It makes you habitual to pushing bug free code as there is a penalty you give in every wrong submission.
- You have to make sure that you get the submission done is shortest possible time, you learn to execute with speed.
- You have great debugging skills
- Edit (Edge cases as well)
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.
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.
In software development you also have test cases where your code should pass so you have in CP
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.
this series is a good start:
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.
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]
[1] https://en.wikipedia.org/wiki/Leonard_Jimmie_Savage
[2] Quote from Paul Halmos's Automathography
What I found to be more useful is working abstractions, learning more about language theory, and etc.
Algorithm is a branch of Computer Science and should be treated as such. It doesn't surpass or transcend it.
Here are some more resources:
- USACO: https://train.usaco.org/ and https://usaco.guide/general/
- 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...
In practice it seems most people just use C++ (87.5%). Add Python3 (7.5%) and Java (5%) and 99% of submissions are accounted for.
* It has a large selection of problems with many good starter problems.
* Once you've solved a problem, you can see how others have solved it (wish more sites had this feature).
* You don't have to write I/O code, so you can just focus on the problem.
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.
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.
Wait, really? I love that.
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).
https://softwareengineering.stackexchange.com/questions/8690...