Learning to program at an early age because you enjoy it has always been the differentiator.
Even if that child doesn’t have as much raw talent, the desire itself (paired with extra years of experience —- especially when the brain is at its most malleable) will drive success in a way the pursuit of money alone never can.
Guns vs Martial Arts.
There are absolutely benefits to doing martial arts that are not self defense, but when you have to defend yourself in a pinch a gun is pretty helpful.
> I really think the rise of LLMs has demonstrated quite well that most people don't care. Only a minority of us have ever had this desire.
I think people care about the problems they have to handle. Not having to deal with a problem eliminates the incentive of training to fix the problem, because you don't waste time on problems that don't happen.
People also stopped caring about what machine code was generated by compilers. In the past people had to roll out asm to get things to work. Not anymore. With llms it's the same way.
It’s kind of like how in early aughts everyone was telling their kids to become nurses and now we have a surplus of nurses with absolutely zero bedside manner.
Idk, basically anyone who speaks candidly about this to me says their use of LLMs over the last year has stunted them in some way.
LLMs aren't comparable to anything thats come before, in my opinion. We had much more time to adapt and integrate with original forms of computing, as well as many other technologies from centuries past.
Sure you can use llms responsible and perhaps in a rewarding way (that isnt just related to making money), but very very few people are making that effort or even know how to.
Its more likely people use them irresponsibly like we do cars. Walk half a mile... nah I'll drive. Now we have endemic diabetes.
It's trending down because researchers found a magic pill (well, peptide) that was clinically proven enough to become over-the counter. This trending down started in 2023. 40 years of policy barely did anything (partially because it never fixed the systems, but I digress).
So are we just going to pray in 40 years someone finds a solution to brainrot?
Antti is a wonderful teacher, he is one of my lecturers. His courses are pretty hard, since they go into very very bread and bones of CS (algorithms, memory allocation, etc), but I always feel I 10x’d my understanding after them.
This one is quite difficult, it sacrifices some readability for cleverness and conciseness. I find Algorithmic Thinking by Zingaro much more approachable but almost as dense.
I think if you always follow the same abbreviations, they'll be readable to you.
Remember, these are throwaway programs; not something that you need to worry about someone else maintaining, or something you need to worry about opening up 5 years later.
I’ve been looking for some coding puzzles to make my head hurt a bit. Somehow I can’t get into Leetcode and problems from the interview prep sites. Maybe this tome will land a bit better since it has an aim other than getting a job where you probably won’t use the stuff anyway.
I’m a big fan of this book. It’s an equally great algorithms reference and way to prep for coding interviews. I haven’t had one in a while but doubt they’ve changed too much in the last half decade.
I guess what I meant is that if you've read stuff like Cracking The Coding Interview and taken an undergrad algorithms/data structure course - that's sufficient knowledge for Leetcode style problem.
The additional stuff in TCPH was fun to read/learn, but I never used it to solve any of those problems.
A note: In my last round of interviewing, I read Beyond Cracking the Coding Interview (the sequel), and the tips it gives for technical coding problems were great - much better than the original book. I can't say it helped getting a job, because the job I did get had its interview just before I read that book.
I used this book back in 2nd year of uni to prep for interviews. I did electrical engineering and so I didn't have a strong background on CS and primarily used this book to get over the software engineering interviews. Helped me got my internship (and probably my job now lol). Another book that I used was the OSTEP for OS and another book about networking that I don't remember. Also Harris & Harris DDCA for computer architecture & Digital Design.
In the past this book was interesting since getting good at it did somewhat help you become a better programmer. At the very least, your typing and ability to write a first implementation with fewer bugs improved as you practiced competitive programming, to some extent even your ability to problem solve and come up with good architectures improved.
That’s all out of the window now. If we are really in “do we even read the code?” territory, then this is just a hobby to do for fun, and doesn’t matter for any real world work. But even if we read the code, but most code is written by prompting and iterating with agents, I don’t know if this will be helpful at all.
People tend to underestimate to what extent pre-LLM programming experience contributes to their ability to steer LLMs in the right direction and produce decent results.
In 5 to 10 years, we'll see what kind of engineer is produced from pure LLM steering without years of hand coding experience. Even many of the more experienced ones would have some of this skill atrophied.
I see this sort of thing as a mind gym, and staying sharp will help your critical faculties as a programmer. Of course, the specific problems are nothing like the problems most of us solve day to day, but it still has many benefits.
Let's take a hypothetical where we really do all stop reading or writing code, because the models and tooling get good enough. In that scenario I would still argue for this of thing. Studying algorithms gives you a lot of insight and a powerful way of thinking. This class of problems is ultimately about how aspects of software work, so having some familiarity with famous algorithms is part of computer literacy. I'm not saying that you need to be an expert, but struggling to solve a few hard algorithm problems teaches a lot.
As a totally mundane way of looking at this, I treated leetcode the same way for years, where I'd do it for fun and because there was a strange satisfaction in solving some of the harder problems, even though it very rarely had relevance in my SWE day job. Except for very rare occasions where I had to write simple graph algorithms.
In the past few months, all of the technical interviews I had involved some form of live coding exercises. Some with hard leetcode level problems even though the positions I interview for are backend/fullstack web engineering, not some kind of high performance algorithms enhancements and implementation jobs (like HFT trading or low level libraries).
I encountered this so often nowadays that I am now allocating a few hours per week for algo problem solving to keep my coding skills polished because the AI is writing my code in my day to day job also
I'm not a competitive programmer and won't be one, but this book seems to be a very practical, hands-on intro into many useful algorithms. Really good!
is leetcode still a thing in interviews. I personally want it to be. We need to start gatekeeping this profession hard ( this is a hard 180 from my stance for last 2 decades). Also regret contributing and being pro opensource.
Closedsource, credentialism and gatekeeping is my new stance.
Who exactly is it that will be doing the gatekeeping? I have a hard time imagining companies caring much about competitive coding scores, and I’ve certainly never heard of layoffs being decided based on LeetCode performance.
I'm not sure if I agree with this but I find the downvotes at even the suggestion of some mechanisim to protect employment sad.
No other profession is as eager to make themselves obsolete as those who build software.
Maybe they think the world runs on meritocracy. Anyway looks like now they are seeing what happens when there are no gates at all and anyone can do what you do.
Two decades learning from others, then close the gate. Can’t ding you for inconsistency though. Your contribution to this discussion is consistent with your new ethos. Good luck with your new approach to the world.
I took his comment to mean that programming jobs should be kept for people who genuinely care about developing a deep understanding and a willingness to learn, instead of those just typing prompts and not really caring beyond that.
That's the charitable way of interpreting it. The less charitable way is that they're bitter that open-source has basically been used to train their replacement, and that they want to turn programming into effectively a guild-based profession to protect the jobs of those presently in the industry. Similar to the button-making guilds of the past, for instance.
Closed source will do squat unless you protect your binaries with some sort of secure enclave encryption scheme. AI can reverse engineer your binaries and deliver a copyright-laundered version in hours or days.
it is mostly just a math/logic contest, with the benefit that you can get the result on the fly, and maybe cheese some problems without rigourous proof
or you can look at other form of competitive programming, like heuristic contest, that would teach you how to use baseline, run tests, adapt strategies based on given data
no one consider a time limited contest (hours to maybe days) same as engineering job, they do this for the fun of it
Unfortunately you are wrong and this is what led to leetcode style interviews where times puzzles are the gate keeping factor. It has literally ruined the industry.
Leetcode was designed to collectively implement bias towards young talented people whose only obsession at that point of time is their work. So no kids, family, free time, and no financial freedom (mortgages, loans). Once you build such culture, it starts to grow and gatekeep by itself from within.
What is concerning, however, is when the competitors of these sports decide that their sport should become a filter for things adjacent to said sport.
The rationale is usually something like: "Competitive programming might not be a robust predictor for job performance, but most competitive programmers I know are also good developers, thus we must use competitive programming as a qualifying factor for hiring new developers." and weight it heavily compared to other signals.
I think competitive programming only focus on few technical aspects, like:
algorithmic thinking, familiary with various data structures, complexity-performance trade-off, etc etc.
Nothing is wrong with that. Think of it as intellectual exercise.
Fair enough, real world software development involves other factors.
Ive been doing codeforces, Rosalind, codewars and leetcode casually in my spare time to detox from heavy daily agent use.
Ive been relearning a ton that either over-reliance on llms caused me to forget, or just lost due to time.
Its been extremely fun. I really missed the feeling of thinking really hard and arriving at a solution.
I hope we dont lose this desire as a species.
>I hope we dont lose this desire as a species.
I really think the rise of LLMs has demonstrated quite well that most people don't care. Only a minority of us have ever had this desire.
Learning to program at an early age because you enjoy it has always been the differentiator.
Even if that child doesn’t have as much raw talent, the desire itself (paired with extra years of experience —- especially when the brain is at its most malleable) will drive success in a way the pursuit of money alone never can.
Guns vs Martial Arts. There are absolutely benefits to doing martial arts that are not self defense, but when you have to defend yourself in a pinch a gun is pretty helpful.
The rise of a technology that reduces cost in all forms of knowledge work demonstrates a minority of humans have a desire to learn and have hobbies?
The majority prefers playing videogames, watching tv and porn.
> I really think the rise of LLMs has demonstrated quite well that most people don't care. Only a minority of us have ever had this desire.
I think people care about the problems they have to handle. Not having to deal with a problem eliminates the incentive of training to fix the problem, because you don't waste time on problems that don't happen.
People also stopped caring about what machine code was generated by compilers. In the past people had to roll out asm to get things to work. Not anymore. With llms it's the same way.
I know people who routinely check the generated machine code of compilers to see if it is reasonable or buggy.
When it is bad they either rewrite their source code or write assembly.
A tool do a job good enough that people don't have to do the job by hand does not mean people stop caring about the quality of the job.
It’s kind of like how in early aughts everyone was telling their kids to become nurses and now we have a surplus of nurses with absolutely zero bedside manner.
Is there really a surplus of nurses? https://www.who.int/news-room/fact-sheets/detail/nursing-and...
If you look in history this is perfectly normal.
Nothing new under the sun.
Idk, basically anyone who speaks candidly about this to me says their use of LLMs over the last year has stunted them in some way.
LLMs aren't comparable to anything thats come before, in my opinion. We had much more time to adapt and integrate with original forms of computing, as well as many other technologies from centuries past.
Sure you can use llms responsible and perhaps in a rewarding way (that isnt just related to making money), but very very few people are making that effort or even know how to.
Its more likely people use them irresponsibly like we do cars. Walk half a mile... nah I'll drive. Now we have endemic diabetes.
Obesity is trending back down and will continue to do so.
Machines have removed our need to work, this stunts our body, and the solution is synthetic work (gym).
AI removes our need to work with our minds (at least partly), this stunts our mind, and the solution is synthetic mind-work.
Sure it will take some time to get used to. But we will get used to it.
>Obesity is trending back down
It's trending down because researchers found a magic pill (well, peptide) that was clinically proven enough to become over-the counter. This trending down started in 2023. 40 years of policy barely did anything (partially because it never fixed the systems, but I digress).
So are we just going to pray in 40 years someone finds a solution to brainrot?
[dead]
Antti is a wonderful teacher, he is one of my lecturers. His courses are pretty hard, since they go into very very bread and bones of CS (algorithms, memory allocation, etc), but I always feel I 10x’d my understanding after them.
Seems he has a new book out (I haven’t read it): https://link.springer.com/book/10.1007/978-3-032-07453-9
Related. Others?
Competitive Programmer's Handbook (2017) [pdf] - https://news.ycombinator.com/item?id=17605395 - July 2018 (14 comments)
Competitive Programmer's Handbook (2017) [pdf] - https://news.ycombinator.com/item?id=16952222 - April 2018 (121 comments)
A Competitive Programmer's Handbook - https://news.ycombinator.com/item?id=14115826 - April 2017 (157 comments)
Competitive programmers handbook - https://news.ycombinator.com/item?id=13762408 - March 2017 (2 comments)
1739758443 | Competitive Programmer's Handbook [pdf] | https://cses.fi/book/book.pdf | https://news.ycombinator.com/item?id=43074212 | 0 comments
1739802959 | Competitive Programmer's Handbook [pdf] | https://cses.fi/book/book.pdf | https://news.ycombinator.com/item?id=43079410 | 0 comments
1749209436 | Competitive Coder's Handbook [pdf] | https://cses.fi/book/book.pdf | https://news.ycombinator.com/item?id=44199775 | 0 comments
There is a more polished version of this book:
https://link.springer.com/book/10.1007/978-3-031-61794-2
Additionally, there is a nice set of problems that go along with the book:
https://cses.fi/problemset/
This one is quite difficult, it sacrifices some readability for cleverness and conciseness. I find Algorithmic Thinking by Zingaro much more approachable but almost as dense.
I think if you always follow the same abbreviations, they'll be readable to you.
Remember, these are throwaway programs; not something that you need to worry about someone else maintaining, or something you need to worry about opening up 5 years later.
I've been a judge at a few ICPC contests. We always double-checked first solves for any of the problems by hand.
The coding style demonstrated here is extremely common with high-level competitive teams.
This is a great share. Thanks!
I’ve been looking for some coding puzzles to make my head hurt a bit. Somehow I can’t get into Leetcode and problems from the interview prep sites. Maybe this tome will land a bit better since it has an aim other than getting a job where you probably won’t use the stuff anyway.
Thanks again.
I see this author has a published book as well "Guide to Competitive Programming" - curious if it's the same text?
This is a great book, not just for competitive programmers. It compiles a few gotchas that apply in general programming, regardless the language.
Very nice ! Thanks for sharing this. Fun to play around with algorithms during college days !
I’m a big fan of this book. It’s an equally great algorithms reference and way to prep for coding interviews. I haven’t had one in a while but doubt they’ve changed too much in the last half decade.
I read this book to prepare for coding interviews. In retrospect, it really didn't help with that goal.
I did, nevertheless, learn quite a bit from it. Would recommend to everyone. It's well written.
What actually helped?
Just lots of practice.
I guess what I meant is that if you've read stuff like Cracking The Coding Interview and taken an undergrad algorithms/data structure course - that's sufficient knowledge for Leetcode style problem.
The additional stuff in TCPH was fun to read/learn, but I never used it to solve any of those problems.
A note: In my last round of interviewing, I read Beyond Cracking the Coding Interview (the sequel), and the tips it gives for technical coding problems were great - much better than the original book. I can't say it helped getting a job, because the job I did get had its interview just before I read that book.
I used this book back in 2nd year of uni to prep for interviews. I did electrical engineering and so I didn't have a strong background on CS and primarily used this book to get over the software engineering interviews. Helped me got my internship (and probably my job now lol). Another book that I used was the OSTEP for OS and another book about networking that I don't remember. Also Harris & Harris DDCA for computer architecture & Digital Design.
In the past this book was interesting since getting good at it did somewhat help you become a better programmer. At the very least, your typing and ability to write a first implementation with fewer bugs improved as you practiced competitive programming, to some extent even your ability to problem solve and come up with good architectures improved.
That’s all out of the window now. If we are really in “do we even read the code?” territory, then this is just a hobby to do for fun, and doesn’t matter for any real world work. But even if we read the code, but most code is written by prompting and iterating with agents, I don’t know if this will be helpful at all.
People tend to underestimate to what extent pre-LLM programming experience contributes to their ability to steer LLMs in the right direction and produce decent results.
In 5 to 10 years, we'll see what kind of engineer is produced from pure LLM steering without years of hand coding experience. Even many of the more experienced ones would have some of this skill atrophied.
I see this sort of thing as a mind gym, and staying sharp will help your critical faculties as a programmer. Of course, the specific problems are nothing like the problems most of us solve day to day, but it still has many benefits.
Let's take a hypothetical where we really do all stop reading or writing code, because the models and tooling get good enough. In that scenario I would still argue for this of thing. Studying algorithms gives you a lot of insight and a powerful way of thinking. This class of problems is ultimately about how aspects of software work, so having some familiarity with famous algorithms is part of computer literacy. I'm not saying that you need to be an expert, but struggling to solve a few hard algorithm problems teaches a lot.
As a totally mundane way of looking at this, I treated leetcode the same way for years, where I'd do it for fun and because there was a strange satisfaction in solving some of the harder problems, even though it very rarely had relevance in my SWE day job. Except for very rare occasions where I had to write simple graph algorithms.
In the past few months, all of the technical interviews I had involved some form of live coding exercises. Some with hard leetcode level problems even though the positions I interview for are backend/fullstack web engineering, not some kind of high performance algorithms enhancements and implementation jobs (like HFT trading or low level libraries). I encountered this so often nowadays that I am now allocating a few hours per week for algo problem solving to keep my coding skills polished because the AI is writing my code in my day to day job also
I'm not a competitive programmer and won't be one, but this book seems to be a very practical, hands-on intro into many useful algorithms. Really good!
is leetcode still a thing in interviews. I personally want it to be. We need to start gatekeeping this profession hard ( this is a hard 180 from my stance for last 2 decades). Also regret contributing and being pro opensource.
Closedsource, credentialism and gatekeeping is my new stance.
Who exactly is it that will be doing the gatekeeping? I have a hard time imagining companies caring much about competitive coding scores, and I’ve certainly never heard of layoffs being decided based on LeetCode performance.
> layoffs being decided based on LeetCode performance.
thats not what gatekeeping is
I'm not sure if I agree with this but I find the downvotes at even the suggestion of some mechanisim to protect employment sad.
No other profession is as eager to make themselves obsolete as those who build software.
Maybe they think the world runs on meritocracy. Anyway looks like now they are seeing what happens when there are no gates at all and anyone can do what you do.
Two decades learning from others, then close the gate. Can’t ding you for inconsistency though. Your contribution to this discussion is consistent with your new ethos. Good luck with your new approach to the world.
I took his comment to mean that programming jobs should be kept for people who genuinely care about developing a deep understanding and a willingness to learn, instead of those just typing prompts and not really caring beyond that.
That's the charitable way of interpreting it. The less charitable way is that they're bitter that open-source has basically been used to train their replacement, and that they want to turn programming into effectively a guild-based profession to protect the jobs of those presently in the industry. Similar to the button-making guilds of the past, for instance.
Well there is something between 'button making guilds' and 'go to bootcamp for 2 months to be a software engineer'
Every other profession does gatekeeping. Yet we dont see any animosity towards them for doing so. Infact we condone it.
Pulling up the ladder is very common among any kind of society, profession and immigration policies. And people advocate for it all the time.
Closed source will do squat unless you protect your binaries with some sort of secure enclave encryption scheme. AI can reverse engineer your binaries and deliver a copyright-laundered version in hours or days.
You give the user access to the software over a web interface. He has never access to the binaries because they are on your servers.
You need to explain why.
We can call it Coding Canutism.
is this an excellent LARP bait or someone with these sincere views?
Why not both?
shortsighted and a bit late anyway
what?
is your favourite colour?
Blue. No, yel--
Yellow, yours ?
Wrong!
Is not a color.
Is there a similar book but in Java or Python?
Yeah , just let LLM rewrite it for you.
Competitive Programming is such an asinine concept.
It’s like competitive knitting, or competitive architecture.
This focus on the inane is what has really damaged this industries perception in engineering IMO.
Competitive programming is a fun activity with little to no relation with the actual industry.
Why would influence perception in any way being an unrelated very niche hobby?
Incorrect. It is the basis of leetcode interviews.
In that case, I would frame as it is ruining interviews.
The actual day to day of the industry, stays unnafected.
it is mostly just a math/logic contest, with the benefit that you can get the result on the fly, and maybe cheese some problems without rigourous proof
or you can look at other form of competitive programming, like heuristic contest, that would teach you how to use baseline, run tests, adapt strategies based on given data
no one consider a time limited contest (hours to maybe days) same as engineering job, they do this for the fun of it
Unfortunately you are wrong and this is what led to leetcode style interviews where times puzzles are the gate keeping factor. It has literally ruined the industry.
Leetcode was designed to collectively implement bias towards young talented people whose only obsession at that point of time is their work. So no kids, family, free time, and no financial freedom (mortgages, loans). Once you build such culture, it starts to grow and gatekeep by itself from within.
AI is the only thing that has ruined the industry
Nothing wrong with competitive things.
What is concerning, however, is when the competitors of these sports decide that their sport should become a filter for things adjacent to said sport.
The rationale is usually something like: "Competitive programming might not be a robust predictor for job performance, but most competitive programmers I know are also good developers, thus we must use competitive programming as a qualifying factor for hiring new developers." and weight it heavily compared to other signals.
I think competitive programming only focus on few technical aspects, like: algorithmic thinking, familiary with various data structures, complexity-performance trade-off, etc etc.
Nothing is wrong with that. Think of it as intellectual exercise. Fair enough, real world software development involves other factors.
more like competitive horse riding. Done for fun, but in everyday life you use a car.
Well, there is just horse riding as well, done for fun. I think this is a better analogy.