I'd disagree with this assessment. In my own experience, I've found that competitive programming is useful in teaching a few skills. However, the apparent point of competitive programming--building up a good repertoire of advanced algorithms and data structures--is pretty close to useless. In my professional career, the most complex algorithm I've ever had to code myself is ... union-find (on like two occasions), with a custom BFS/DFS being the most common algorithm I reach for. Almost everything you will ever need is already implemented in a library for you to reuse, and even reaching for that library is pretty rare.
No, the most useful impacts of competitive programming has to do with actually teaching you how to program effectively. The most important advice I got for competitive programming was walk away from the computer. The biggest trap when programming is to write code before you know how to solve a problem, as this will tend to encourage you to spend all of your time making no progress towards actually getting a solution. The tale of the Sudoku solver [1] is salutatory here.
Another useful skill is how to debug algorithms. Debugging a competitive programming problem usually amounts to taking an input that fails and trying to understand where in the algorithm (as expressed in poorly written and commented code!) the mistake is. Doing so under the time pressures of a competition also requires being able to rapidly decide if the algorithm is wrong, or it is the implementation is wrong, as well as figuring out where the most likely places for errors are likely to creep in. This kind of experience translates very usefully into professional programming, and debugging is a skill that seems to be poorly acquired by most young programmers.
When competitive programming hits the tier where you need to memorize all of the advanced data structures and algorithms to do better, that's where further improvement in the leaderboards no longer translates to better programmers IMHO. But there's still a lot of skills that need to be acquired to move up competitive leaderboards before you reach that point.
To me competitive programming doesn't make you a good software engineer.
It will teach you bad practices, like abusing of dangerous programming constructs or data structures to optimized the code or just save some typing while writing the code (like one letter variable names, macros, etc), global variables and state in the program, not using common design patterns, not using OOP, not documenting the code and in general writing code that is difficult to maintain because it's not well engineered. You would say that a person would do that only in competition, but in my experience I saw that is not true, because if you learn to program a particular way, you would do the same also in other contexts.
Also, the competences that you will acquire by doing competitive programming are next than useless: in the real life I've yet to encounter a situation in which I have to use an algorithm used in a competitive programming competition (yes, I did them with even good results). And if you need them, you don't implement them yourself, but you use a library that manages all the work. The Dijkstra implementation that most competitive programmers use is a toy implementation, not something that you would never use in any sort of enterprise software.
The fundamental skill that competitive programming doesn't teach you, that to me is the most important thing for a good software engineer, is using Google to find documentation online. Most of the errors I see by young software engineers could easily been prevented if they did a simple Google search and read the official documentation (not a random blog post)! And yet in competitive programming you are forbid to use the internet, to me it's stupid, it's like requiring to write code with a typewriter just because in the past keyboards and monitors didn't exist.
> It will teach you bad practices, like abusing of dangerous programming constructs or data structures to optimized the code
If someone can't weigh up the pros and cons before using a particular technique, they're going to be a bad software engineer anyway. The field is all about making the right tradeoffs in particular situations, and blindly following current generalised "best" practices without really understanding what they're meant to be better than is going to get you into trouble too.
Breadth of knowledge and experience is a great thing. If you follow from the start that OOP is the right and only way to do things for example, you're not going to have a feel for when it gets in the way. Actually knowing what it's like and what happens when you do something the "bad" way is very valuable experience too e.g. you're going to be a better coder if you'd had to battle with buffer overflows and memory leaks in C in the past even if now you only use Java and Python.
This kind of logic really bugged me after moving from academia into industry. In academia for example, it's usually the right choice to make quick and dirty prototypes to get the results you need for a paper and not burn time over-engineering it. This doesn't mean I don't how to clean up code. I would also say it gives me more experience on avoiding over-engineering compared to someone that tries to copy best practices all the time.
> It will teach you bad practices, like abusing of dangerous programming constructs or data structures to optimized the code or just save some typing while writing the code (like one letter variable names, macros, etc), global variables and state in the program, not using common design patterns, not using OOP, not documenting the code and in general writing code that is difficult to maintain because it's not well engineered.
These are not “bad practices”. Many of them are bad in certain common contexts, but literally none of them are bad in throw-away code used in the course of root-cause-analysis of problems in other code basis, and most are useful in many parts of proof of concept code. In working on production systems, most of the volume of code I produce isn’t production code, and has a very different set of constraints than production code.
And given history on HN, whether “not using OOP” is ever a “bad practice” is probably a whole discussion of its own.
And if the proof of concept does work, you take all the code that you written, throw it away and rewrite it? Probably not. I've seen too much "proof of concepts" go into production because they worked. Except when someone else had to actually maintain the thing and the person that wrote it leaved the company 1 year before.
There is not proof of concept code to me. Every line of code that I write professionally I write it to the higher standards. That doesn't mean over engineering it, but it means writing it in a way that is maintainable and understandable by others. I can compromise on functionality, of course in a proof of concept I implement only the things that I need, but not on code quality.
Even if I have to write a script that I know it will have to be used once and never again I will write it in a good way, you never know if you need it again, if a coworker does need to do a similar thing and you can just give to him as reference, or if you can take pieces to do other things.
Competitive programming doesn't teach you only algorithms and data structures, it teaches you to think very clearly about program flow, edge cases, debugging etc., points which you seem to just gloss over from the comment you're replying to, just to justify a conclusion you had already reached.
definitely, alot of the "algorithms" in leetcode practice look deceptively simple on the surface, but deep down, there are lots of edge cases and are good practice to think deeply about them
on the otherhand, they can also encourage messy and hard to maintain code, or super efficient implementation can be brittle which you dont want in production unless there is a really really good reason...
if "competitive coding" also judge on other criteria such as clarity, readability and maintainability, in addition to efficiency and "correctness" that would be great imo
I don't think it's reasonable to use a library for most things one implements in competitive programming, because the work of getting your problem instance in and out of the library is probably greater than the work of writing the solution yourself, in code length and in runtime. As an example, the only time I ever needed to use A* was on a state space that was larger than the main memory of any computer on Earth. I don't expect that I can download a library that does A* on abstract state spaces not fully present in RAM for me, but I can just bash out my own A* that's fused with the definition of the state space. Maybe this is so easy to do partially because I did a bunch of programming contests in which I wrote BFSes that were fused with the definitions of graphs.
> I don't expect that I can download a library that does A* on abstract state spaces not fully present in RAM for me
I'm sure this does exist! A functional library where you pass in, not a pointer to the set of all nodes, but some functions to get the node with the current lowest distance and to update the distance of a node.
Not saying it was the right thing for your use case, but don't rule it out. Even in languages that aren't strongly FP - eg it happens a lot in Go due to the lack of generics, and if you squint, the C++ STL is kind of like this.
It's not. Because then someone else has to maintain the code you written, and if he cannot see any common pattern in your code he will make 10x the effort to understand the code, that means wasting time and thus loosing money for the company.
Is this about the design patterns or the A*? Design patterns are a mix of techniques to pay complexity make code extensible that usually will not ever be extended and workarounds for the deficiencies of a specific family of languages. An example I posted about previously is that you could spend hundreds of lines across a dozen files implementing double dispatch, or you could use dramatically less if you aren't implementing it in terms of a language-provided dynamic-dispatch-on-the-first-argument-only primitive.
It is nice to write code that can be understood by the next reader. To explain what our invariants are and what we are up to, we have comments.
Agreed, everything that makes good contest code is a bad thing for production code. In a contest you just want to hack together something as quickly as possible, it only needs to work once, will never be maintained or documented.
It's all good fun as a sport, but nobody should consider it relevant to working on production code.
> Almost everything you will ever need is already implemented in a library for you to reuse, and even reaching for that library is pretty rare.
Developers who have no interest towards algorithms will not even have the skills required to identify opportunities where algorithms should be used, much less the skills required to identify which algorithm should be used. For example, I had a conversation here on HN a few weeks back where somebody said that they will not need to learn anything about sort algorithms, because they can just google bubble sort and copypaste it if they need sorting at work. And that's how you end up with 5-minute load times for GTA.
> somebody said that they will not need to learn anything about sort algorithms, because they can just google bubble sort and copypaste it if they need sorting at work
In this example, the missing skillset is not memorizing a book of algorithms as you seem to imply.
If performance isn't good for the use case, they should be profiling the code for root causes. Which will lead them to identifying the sort operation as a problem. At which point they can search for faster sorting algorithms which will quickly lead them to a better solution and libraries containing them (or even how to implement, if they're operating in a constrained environment where no libraries exist).
I don't want to hire software engineers who have memorized the algorithm book, that's not useful to me. I want to hire those who can apply discipline to the work, such as (in this example) be aware of performance and know how to analyze it and find solutions.
> In this example, the missing skillset is not memorizing a book of algorithms as you seem to imply.
No it's not. As I said in the sibling comment, competitive programming (or algorithm skills in general) isn't about memorizing algorithms, it's about developing skills that allow you to understand and create algorithms to solve problems. In this case, it would be sufficient to understand why looking up a phone number in a phone book should inherently be a O(log n) operation, not a O(n) operation.
> I don't want to hire software engineers who have memorized the algorithm book, that's not useful to me. I want to hire those who can apply discipline to the work, such as (in this example) be aware of performance and know how to analyze it and find solutions.
So we're discussing a hypothetical developer who has "no interest towards algorithms", and you're imagining that this person is going to run a profiler to troubleshoot a performance issue and subsequently optimize algorithms to fix said performance issue? This sounds like a fantasy to me. If you want skilled software engineers who have the ability to troubleshoot and optimize algorithms, you probably need someone who has some kind of interest towards algorithms.
> So we're discussing a hypothetical developer who has "no interest towards algorithms", and you're imagining that this person is going to run a profiler to troubleshoot a performance issue and subsequently optimize algorithms to fix said performance issue? This sounds like a fantasy to me.
Our experiences are vastly different then. Nothing fantasy or hypothetical about this. Every great software engineer I've worked with is like this.
Profiling and identifying hot spots is an every-week occurrence in the field, very pragmatic and valuable work. Theoretical algorithms only happen on interview whiteboards, not on the job.
Different game, different problems, but I've spent a fair amount of time looking at the source for Civ IV's core game DLL (released by Firaxis for modding).
It was fairly simple to get significant performance gains (without changing AI behavior or results) just by applying straight forward changes. Eliminating macro's hiding chained method calls. Saving the result of nested calls, e.g. save a pointer to the game map instead of making the same call repeatedly in a tight loop.
There's a huge difference between "premature optimization" and just sloppy coding. Too many take the idea too far that the (C++) optimizer is better than you'll ever be and that you should let it do it's job. Yes, the optimizer is/can be very good and can make surprising and unintuitive changes to make code faster. But, it's not a miracle worker. Optimizers work best on clear, concise, code with minimal data dependencies.
FWIW, back on my Core I2 Duo, a single late-game turn on a huge map could take upwards of 30 minutes to complete, most of that spent in AI's turns. I was able to get it down to about 5 minutes without too much effort. Along the way, RAM usage also plummeted. If I had full access to the source, I could have made even greater gains that would have broken the DLL ABI...
Sadly, I never released my changes anywhere (and I only had local SVN at the time), and they haven't survived my PC upgrades since.
No they weren't using bubble sort. When parsing JSON, they were calling sscanf (which internally was calling strlen). In addition, those parsed objects were stored in an array which was iterated through on each insert to check for duplicates.
There was an article [0] and subsequent discussion on HN [1] about reverse engineering and patching the binaries.
No? If you check your own sources, you will find that this is precisely the type of case where a developer is using an O(n^2) algorithm out of ignorance when they should have been using a faster algorithm, and that the high load time was caused by this mistake. The time complexity for bubble sort is also O(n^2), compared to O(nlogn) for reasonable sort algorithms. I don't really understand how you take all this information and then conclude "no".
The way accidental O(N²) comes about isn't "I'm intentionally using an algorithm that's O(N²)" (e.g., bubble sort), but "this method that I think is O(1) is actually O(N)" (whether because it's badly designed or just badly documented).
It's really not in the same vein as using bubblesort instead of a mergesort: failures aren't in algorithm design but in the actual mechanics of the implementation that is ancillary to the algorithm itself.
Bubble sort provides O(n^2) time complexity for a task that can be easily solved with O(nlogn) time complexity. The 5-minute load time for GTA was caused by a developer using an algorithm with O(n^2) time complexity when they could have used an algorithm with O(nlogn) time complexity. So, yes, I would say it actually was the reason (unless you are specifically asking if the bad algorithm choice was bubble sort, in which case the answer is no).
> When competitive programming hits the tier where you need to memorize all of the advanced data structures and algorithms to do better, that's where further improvement in the leaderboards no longer translates to better programmers IMHO.
I found this post [1] by the current rank 5 competitive programmer on codeforces to be an interesting take on this perspective. It's not as much about knowing the fancy algorithms, as being able to derive their ideas when needed, that makes you really move up.
> However, the apparent point of competitive programming--building up a good repertoire of advanced algorithms and data structures--is pretty close to useless.
That's not the point of competitive programming. If you talk to anybody who is good at competitive programming, they will tell you it's _not_ about memorizing algorithms and datastructures. It's about developing algorithmic problem solving skills; skills that you can leverage to design (create) algorithms, in order to solve problems.
I have seen successful competitors people do basically that. And I have seen them train how to write basic algorithms super fast again and again.
Yes, they had also algorithmic problem solving skills. But they learned huge amount of algorithms and datastructures so that they don't have to derive them each time. And they spend time literally training how to write them fast without mistake.
It was not just about problem solving skills. It was a lot about knowledge base.
There's not _that_ many algorithms or data structures you see in competitive programming, and the vast majority of them aren't advanced. You do need to memorize a good portion of them, but doing so is the easy part towards becoming good at it.
You can read one moderate length book and know all of the DSes and algorithms you'll need for 99.9% of the time. cses.fi/book is a good one with a free version if you're curious.
Ok. I'll take your anecdote at face value and shift my views slightly in that direction. I'll also note that even if some competitors do memorize algorithms & train how to write them fast without mistakes, this memorization perhaps gives them a slight edge, but it's not the core skill that separates winners from losers. A small edge, perhaps.
Necessary edge. There was tons of preparation specifically for competitions.
Not sure why would that be surprising. Same thing happen in chess, scrabble, anything competitive. Once there is enough competition, you can't go in with hope and talent alone. You have to train specifically for competition format.
Chess players don't base their play on pure problem solving either. They memorize and train specific plays.
It's surprising because I also do competitive programming, and I know many people who do it, and I haven't encountered anyone in those circles memorizing algorithms. In fact, many competitions explicitly allow you to use a pre-written library. Some IRL competitions even allow you to bring in written materials. (Not all competitions allow this, I know.)
The worst part of competitive programming is that you need to do it for job interviews. This turned a legitimately fun and deeply engaging activity into a truly tedious and draining one
I’d love a programming competition that wasn’t about speed of implementing algorithms, but rather was about speed of implementing solutions, using a provided standard library of algorithms and data structures. Competitive glue-code programming, per se, but glue code that still requires that you understand the need for specific advanced algorithms in order to pull them out of a toolbox.
Isn't this basically what competitive programming is? Maybe I'm a bit clueless, but my assumption was most people have standard libraries of common algorithms/implementations they pull from and tweak/glue as needed to fit the problem in front of them. Those libraries are not standardized, but there is for sure basically a common set of things you need to be competitive, right?
I haven't done competitive programming in years, but when I did we were allowed to use things like Boost in C++ or the standard library in Python.
I can't really recall any scenarios where a stdlib datastructure was slightly too slow, but re-implementing your own version was just fast enough to get by. The problems were typically created in a way where using any common algorithm was 1000x too slow, and you needed something like dynamic programming to make things run in a reasonable amount of time. Or they were a math problem masquerading as a programming problem.
There is a common set of algorithms that most people who do well in such a contest can implement whenever they like, but most of the effort involved in solving the problems happens before they write any code, and many (half or more?) problems can't be solved by just applying the techniques from this repertoire.
This is correct. A typical CodeForces problem is intentionally constructed as a unique snowflake that can't be solved by just calling a library function. You need to be able to design an algorithm that solves that specific unique snowflake on the spot. Perhaps your algorithm also makes some library calls to other algorithms in your comp.coding library, but those are merely building blocks for your own thing, which you have to invent.
> Almost everything you will ever need is already implemented in a library for you to reuse, and even reaching for that library is pretty rare.
This undercuts your claim a bit as someone has to be able to write the library in the first place. Yes it’s rare, but the software engineering industry is big enough that “rare” can be a “this happens all the time in domain X”.
Overall though I’d agree that it’s not useful for the majority of engineers and isn’t a good judge of programming ability just like math competitions aren’t either. They are “something” though.
Writing foundational algorithms/data-structures libraries (e.g. language-runtime stdlibs like libc) is usually treated as a sort of sacred ritual in programming—something where it’s “obvious” that it should be done slowly, carefully, and without distraction, with each change audited carefully by many peers before accepting a merge.
It’s not often that you’re writing such code “in anger”, under time-pressure to ship to fix downtime, with no time to get peer review.
This is in large part because the downstream client of an algorithms/data structures library, would almost-always prefer a robust but less-efficient option, over an alpha-quality implementation of a more-efficient option. Dataset-size scaling challenges that recommend algorithmic efficiency increases can, almost always, be temporarily put off by “throwing machines at the problem” until the more-efficient library becomes high-quality enough to be fully relied upon. Until then, the business logic will make do with the simpler/more naive algorithm.
And in most language runtimes, there’s a simpler/more naive algorithm or data structure to solve every problem already laying around in the core stdlib; so it’s not like you, as the library writer, have to implement that code “in anger” either. Your internal customers can upgrade from depending on stdlib types, to depending on your lib’s types, when using your lib becomes an unalloyed win for them; and until then, do nothing.
> Writing foundational algorithms/data-structures libraries (e.g. language-runtime stdlibs like libc) is usually treated as a sort of sacred ritual in programming—something where it’s “obvious” that it should be done slowly, carefully, and without distraction, with each change audited carefully by many peers before accepting a merge.
I'll be honest, I think you're vastly overestimating how well these things are actually developed :) I agree with what you said, I just found this part a little bit funny.
What I really meant, without the fancy language, is that stdlib programmers are crotchety greybeards who don't like change-for-change-sake and so default-deny rather than default-accept random patches. That by itself creates a very different level of stability in these projects, where things only ever change if they really need to to fix a specific bug—and even then, the change is pared down to have as little architectural effect as possible.
You most likely need strong grasp over OO, and design patterns to be a good library designer/programmer than Algorithms that you can easily look up online.
I've been looking around at jobs, and was advised to start practising on HackerRank for the technical interviews.
I've been coding professionally for 30-ish years. There is very little that I've seen on HackerRank that comes anywhere close to a "real" software problem that I've faced developing actual software.
Why is this being used to do technical interviews? What's the thinking here?
My guess is that people who can't code can't pass, but people who can code might pass. It's a kind of extreme fear of false positive. Then the firm that does the testing needs to look like they're doing something beyond fizzbuzz and you end up with crazy tests.
It never made sense to me, I always just do a technical conversation and if for some reason a muggle has gotten an offer it's easy to detect and deal with. People don't last long in coding jobs if they can't do it anyway.
Back during Y2K I was working as a contractor for a large organisation. I was hired by a recruitment company, who were hired by the customer to provide a large number of contractors. Evidently someone messed up, and we had a guy join the team who couldn't code. He'd heard about the money to be made in Y2K, had done some simple exercises, and slipped through the screening process. But once he started it was obvious he had no idea what he was doing. We pushed back at the recruitment company, but apparently they couldn't fire him because they'd have to admit to the customer that they'd hired someone who couldn't code, and politically that wasn't acceptable. We were told to cover for him. So this guy clocked in every day and did nothing, literally nothing, all day, earning really good money for it. We disabled his login, so he couldn't do anything on the PC sat in front of him. If anyone from the customer organisation came by he had to look busy somehow - it was on him if he failed to do that and the customer started asking questions about him. He couldn't even read a book at his desk in case he got caught doing it. It must have been hell for him. We ended up feeling that he deserved the money just for being able to do that day in day out for months. I would have gone crazy. In the end, I moved on before he did so I don't know how it ended. I often think of that guy when pondering how life in a stable-but-boring job would be.
LOL, I had forgotten about this, but I actually sort of lived this decades ago in college. I thought I "invented" this variable-less swap technique and used it when answering a CS class quiz question. The prof dinged me on it. I thought I was wonderfully clever and the prof just didn't get it. But of course, he was right and I was wrong.
Yeah, this. My home state's college's CS program boasted it was one of the best in the northwest. My friends that went through it constantly had to ask me to explain simple stuff to them because the professor's assignments were wrong or confusing.
Compare that to our local community college, which seemed to have a much more well-rounded course and taught the fundamentals in a way that made much more sense.
Anecdotal of course but certainly defies the "rule".
Another anecdote: I did maybe 100 interviews while I worked at Uber. If I had to guess, I'd say 30% were from university grads (or soon-to-be grads).
Of those, most couldn't hardly write a line of code. Several candidates in the same age group came from a non-college/-university background and usually outshone those who did.
The fact that so many people are getting CS degrees and yet can't even FizzBuzz is alarming.
Is it the students? How many people are going into CS because they've had a taste of programming somewhere outside of school and decided they want to be a software engineer, and how many of them just get into CS because they heard that CS grads have very good employment prospects (Low unemployment, high salaries)? Anecdotally, I can tell you that during my senior project for my CS degree, someone in my group admitted to hating coding, but was pushed into CS by family, and that he couldn't code worth a damn.
Or is it the schools? In my school, the first two years were much heavier on the code, where the latter two years were heavier on CS theory. But in both cases, the quizzes and tests were on syntax and other things that could be answered with a short answer, or they were multiple choice. The only time your coding ability was tested was in the homework, which is easily plagiarized with Google and Stack Overflow.
Cheating is really rampant in CS degree programs and it’s very difficult to do an actual test of coding skills in a reasonable timeframe rather than pure memorization.
We had a decent solution to this in my undergraduate school.
Tests were basically all theory. Practical knowledge came from labs and everyone did the majority of their homework on lab computers that had no network connection. Not everyone was a rockstar of course, but as I recall pretty much everyone was at least a passable programmer in the end. Of course that was the early 90s...
So much of this. In my CS class, I could hardly find anyone who actually had some curiosity to learn. Everyone does their homework by sharing answers on the class chat. And in team projects, either there is one person who does all the work, or they end up copying from google and stackoverflow.
> The fact that so many people are getting CS degrees and yet can't even FizzBuzz is alarming.
CS contains more disciplines than just software engineering. Some people get into CS but have no interest/knack for coding: it just doesn't "click" for them the way it does for others, and they will fallback to rote memorization/copy-pasting from StackOverflow to scrape over the line.
I did Calculus 1 & 2 as part of my CS; but today, I don't think I'd be able to solve the FizzBuzz of Calculus, Linear Algebra, (or even the finer points of OS process schedulers if I'm being completely honest). I'd be alarmed if Software Engineering graduates weren't able to solve FizzBuzz
Not to nitpick your Uber anecdote, but the "candidates in the same age group came from a non-college/-university background and usually outshone those who did" probably had to have some strong non-university background like significant practical experience in projects or work to pass the resume filter process to make their way to your interview stage. So there's probably a great deal of selection bias in that specific example.
State colleges serve the entire state, or a large portion of it (i.e., University of Kentucky, Eastern Kentucky University) are are typically universities instead of colleges.
Community colleges serve a smaller area, typically one county and its neighbors. Community colleges often have a much higher emphasis on trades and job prep. They will often offer more 2 year associate degrees, trade certifications and less 4 year degrees. They are rarely universities.
In the USA Community College can mean a private or publicly funded 2 year university, college or trade school. A state university is pubicly funded and can be a community colleges. See the New York State SUNY system for an example. There is also the New York City CUNY system which is publicly funded by the city at the local level.
I went to "Queensborough Community College", a CUNY university in NYC. So I tend to define "community college" as a publicly funded 2 year university/college.
State University: typical higher-learning university that requires application and awards degrees. Funded in part by its US state via taxes.
Community College: no application, no traditional degrees, no prior learning required. Often vocation in focus. Adult classes. Anyone can attend (dropouts, elderly, anyone). You even just sign up for individual classes. You, 8589934591, could likely sign up for an online class next semester/quarter. Some are highly regarded, Foothill College in SV for example.
Just for my understanding. Is the person who I replied to saying that even though state univ are "considered" better, their personal experience is that community college (which is considered inferior to state) students performed better?
The difference is also one of focus. A Community college will offer things like a 2 year certificate course in .Net Enterprise Development, rather than 4 year degrees in Computer Science.
If you need a junior .Net Enterprise developer to write WPF apps in C# to talk to a SQL Server using LINQ, then it is very likely that the student from the community college, who has spend 2 years focusing very practically on learning exactly those technologies, will be able to perform better out of the gate compared to the university student whose education has a broader and more theoretical base.
In theory the University student should be 'better' in the long run since they have a deeper understanding of the field as a whole and should be able to solve harder problems and more quickly transition to new technologies, but that is of course up for debate. And most companies don't need to solve many hard problems, they need a WPF app that can talk to SQL Server using LINQ.
The difference in curriculum in the Community College I went to and the "real" college I am going to right now are astounding. There are four year CS students who are going to college and don't know how to write a line of code, contrast that to the community college where the expectation is that you create real function programs from scratch. I wonder if this is the case with all colleges, and if so why are FAANG companies not recruiting from CC's by default.
Any one student may happen to be a genius at a lower tier school, but comparing population averages, it's pretty clear that smarter pupils go to MIT or Harvard than less prestigious universities and I don't see why this would be controversial. Some people are smarter than others. It doesn't make them more valuable as human beings, but there are real differences in the world.
It's controversial because that assertion assumes that entrance to MIT, Harvard etc. is primarily based on IQ (or whatever other metric of "smartness" one uses). It is apparent that admission to these universities is based on many things other than IQ, and that IQ may in fact be a lesser component than other things, such as socioeconomic status (which leads to attending schools that prepare one for applying, being able to participate in activities that pad a CV, etc).
I didn't say there weren't other factors, there clearly are, but there are real differences in smarts between schools and to consider this controversial is something I think is more of a product of our present moment than something that people really deep down believe.
And I actually think I can speak to this with some amount of personal experience. I've been at both a lower tier college and a best-in-the-country university. When I was 11 I wanted to learn how to write software so I took courses nights, weekends and summers at the near by college until I was 14. I know how smart the class was and it was no where near as smart as the engineering students at the top tier university.
But that is ok! I think we overvalue intelligence in modern society, but to pretend that there are no differences is undervaluing the truth for the sake of political correctness or ideology.
I think you're confounding competence and skill levels with "smarts". I wouldn't argue that the output of elite schools is not measurably different than that of e.g. state schools, but I think your view that the intrinsic quality (e.g. IQ) of the people is different is mistaken and not backed by any evidence.
Tangentially, I think it is lazy to say somebody who is disagreeing with you is just being "politically correct" or "a product of the present moment". I see no evidence for claims like yours, which strike me as more ideologically driven than you might believe.
Going to MIT and Harvard is more about ambition than "smarts" is my thought on it.
On average smarter, but that more has to do with population size than anything. If you limit the comparison to the top N from state schools so that you were looking at the same population size, state schools would end up out in front on the "smarts" scale but lose on the "ambition" scale.
It's hard to justify the extra 200K for MIT CS degree tuition vs many public in-state universities' CS major.
My take is, if you are interested in academic research and theory study, going to ivy leagues makes sense, or if you're into law/business/medical majors, school ranking matters a lot. For a high paid IT job at undergraduate degree level, ivy league makes absolutely no sense, the extra $200K tuition is also really just a net loss.
This is an obvious and observable fact. An MIT trained programmer is probably smarter than a CS grad from a big state school. To deny this is to deny the obvious difference between an elite CS education and a run-of-the-mill state school education.
Of course one is better than the other.
As someone who went to a state school this does not bother me at all. CS education is not locked behind some door in a secret location - its open to anyone with internet access.
What makes one programmer better than the next is the extent to which he invests in educating himself.
This is true, but most of them don't go to top tier schools. Which is not at all the same thing as saying most people who go to top tier schools aren't smarter than average. This fact is the root of a lot confusion in the area.
I don't think anyone out of college for more than a few years thinks the "tier" of college you went to is the ultimate arbiter of how competent you are and can ever achieve.
Believe it or not, _statistically_ speaking, top tier STEM schools do have way more smarter students per my experience. Prestigious Universities earned their fame for the most part.
Idk about the "Prestigious Universities earned their fame for the most part" when implying that then causes their students to become way smarter.
IMO to compete in the "college admissions race", smart/motivated students will often compete like crazy to get into the prestigious university system. So because so many very smart/motivated students compete to get into the programs, the prestigious universities get their pick of top tier students who will end up graduating who could turn out to be smart/competent programmers regardless of the actually quality of the program.
I'm not saying these top schools have crap programs, I'd imagine they do have great programs as well, but I'd guess those same students would become good/competent programmers coming out of any program.
Put a NBA genius player in a community college basketball team will be hard to reach his potential. People surrounding you can make a big difference. Birds of same feather not only flock together, they can flock better/faster together and enjoy that process too.
obviously we are talking about statistics, so of course specific examples exist that run counter to the trend. But without a doubt, I am 100% certain that on average the incoming CS class to MIT is smarter than students in the cs program at some very low ranked state school.
you can see the difference in which textbooks the school uses. It would be impossible to teach real analysis with Rudin at an average school or community college.
Or the math 55 sequence at Harvard, which basically gives students more mathematical training in a year than the average university student will get in an math entire degree.
Better prepared I would say. There are plenty of kids that don't get the opportunity to show how smart they are. They grow up in the projects, have to work nights to help their family, some have to join gangs to survive. You swap they're upbringing with someone who's parents got to spend 100k on their high school education, provide them the things like a car, so they don't have to ride the bus a hour to and from school, and they'd be a lot different. It's really easy to be a lot smarter when you have a support system that nudges you along the way. Now agreed, there are some kids that really are smarter, but mostly it's about being prepared to handle that rigor.
My opinion is that nurture affects nature, so yes if we optimize childhood development it would naturally lead to better outcomes.
However I do believe people have a “natural” ceiling based on genetics. Meaning that no matter how great your nurture environment is, you could never become a top NBA basketball player or a Nobel prize winner.
Now I’m not saying MIT is either of those things, but it’s certainly difficult to get in and not simply a by-product of your “nurture” environment but some interplay with your “nature”. Although I’m sure with a timely $20M gift from your parents your chances of getting in would increase substantially, regardless of your qualifications.
Although I wouldn't contest your opinion about "ceilings" etc, because I don't know much about it, I would contest that elite universities select from a pool that is above most people's top end. I suspect the average intelligence of Harvard, MIT, or Stanford students is higher than the national average but still within the first deviation - in other words, most people in the population who are interested in university are probably "smart enough" by nature to succeed at one of these schools.
Socioeconomic factors playing a role (even a majority role, in my opinion) in access to elite education isn't about $20 million gifts. It's about living in neighbourhoods that have good primary and secondary schools; it's about living around peers who think going to university and even elite universities is normal and achievable; it's about being able to afford "personal rounding" activities like organized sports or music lessons; it's about being rich enough to be able to afford to give volunteer hours.
This "privilege" doesn't make those people bad or invalidate how hard they worked, but we should avoid thinking their success is due to some innate, "natural" superiority like just being smarter.
while I agree, that very smart children can be victims of their childhoods, not everyone can prep their way into MIT. that is why Harvard and Yale are more prestigious, its more associated with the powerful, not purely the most academically inclined.
To be clear I grew up fairly poor myself with no support system, but not that bad with violence, just trailer park poor, you can tell smart children at a very young age, kindergarten it will be obvious if a student is mathematically gifted(for whatever that is worth, it is certainly not the end all be all indicator of future success).
my point is that MIT will have a higher percentage of mathematically gifted students, because it isn't something that can be prepped for.
I guess I would be curious on how much a difference it really is , if you could completely control for environment, but even then the difference still exists.
> my point is that MIT will have a higher percentage of mathematically gifted students, because it isn't something that can be prepped for.
What are you talking about? The requirements to get into MIT are not mathematical genius. It's above average quantitative skills. And you can prep for the standardize math requirements quite easily. All of my high school friends did, and some managed to get into MIT.
you obviously have a pretty strong bias. I didn't say its a requirement, I said they would have a higher percentage of gifted students.
Also the requirements are not "above average", a math SAT of 750 is in the 95% percentile of SAT takers, which is already below average for MIT. Even then, the "average" student isn't even taking a college readiness test. You are grossly overestimating what average is.
Although I agree that the average student at one of those schools is much better than one at a lower ranked school, I think there is a false equivalency at play here. Enrollees in Math55 are not representative of all math students at Harvard.
In my experience, the average student of a prestigious institution is just as good as an upper decile student from a decent university. That said, the top end of those at top colleges are truly world-class. At the end of the day, these universities have historically educated the elite: there is discussion to be had on legacy admissions and paper-mill research groups that pad the resumes of high school applicants with research of little merit.
don’t mean to detract from the conversation, but isn’t math 55 just elementary algebra and analysis? surely this is insufficient at the vast majority of schools to constitute a math degree
> different definitions
fair enough. certainly some bias from me, here
but, i’d still be stunned if introductory algebra, analysis at a baby/papa rudin level, and some point set topology would be sufficient enough to be called a math degree
guess who got into a teir 1 uni abroad but doesn't have enough money to be able to go and now is stuck in a teir 3 uni in their home country? me! and possibly many others. my takeaway-a. if I got in a lot of idiots like me also did and b. if I'm not an idiot a lot of other non idiots also end up at teir 3 unis so don't judge a person by their uni
Competitive programming is useless, but most things are useless! And here "useful" only means useful in the context of building and evaluating skills for industry. But my friends who do competitive programming do it because it's fun, and some of them don't even want to work in tech when they graduate!
There is a kind of pleasure in connecting the pipes and optimizing the loops and building a sick dynamic programming recurrence relation or whatever; we desire these flows. Who cares what skills they build?
Hot takes like this suck all the life (and not to mention diversity) out of our profession. Every competitive coder I've ever met does it because they think it's fun.
Competitive programming is fun. It’s amazing that some people seem to think everything is about career path optimization.
Are we not allowed to do things for fun or just to pass the time anymore without someone writing that we’re wasting our time since it isn’t boosting our career?
The article leaves out one very important skill: teamwork.
Teamwork is tested very well by contests like the ACM ICPC programming competition: teams of 3 people, one computer, and 7 or so problems to solve in 5 hours.
Speaking from first hand experience, my team won the ICPC (many years ago...) based totally on coaching on our teamwork. Essentially, we arrived in the competition city 5 days early and somehow got adopted by the coach of another country's team (which said they didn't need her help). She spent those 5 days observing us approach each phase of the contest, and gave feedback on every aspect on how we worked together: triaging the problems in the first minutes of the contest, who to allocate which problems to, optimising sharing the single computer, when to switch when stuck, helping each other debug, etc, etc. Right down to how to lay out our stationery and stack our working notes on the table.
After doing 2-3 prior competition problem sets a day for 5 days, we became an amazingly efficient machine. Not because we were individually better problem solvers (thought there was some improvement there). But because we all instinctively did the right things in the right order, there was no dead time, no miscommunication, and no stress about our performance versus others.
Thanks to Raewyn's coaching, we converted probably a 5th place into a convincing 1st place. And she'd already won 1st place with her own country's team two years earlier.
So the focus on teamwork paid off. Both in our contest, and in work situations subsequently...
I'm been following competitive programming for years and know multiple extremely successful "grads" of IOI and ACM ICPC. I have an ICPC bronze medal myself.
The HN crowd will know Adam D'Angelo (IOI Gold) - cofounder of Quora and Nikolay Durov (IOI ICPC Gold) - cofounder of Telegram. My personal examples are Singlestore (billion dollar company) which I cofounded and Near Protocol - 5Bln market cap crypto company cofoundered by Alex (ICPC Gold). There are also numerous fantastic engineers that have competitive programming under their belt working for tech primes and startups.
People who win are usually very very smart. AND they learn to work hard - you can't win without great work ethics. Skills wise you learn many algorithms and data structures cold. Plus you learn how to write small program with very few bugs from the the first try. Do they come out as complete package of a well rounded engineer - no, but there are years ahead to learn and they are trained to learn fast.
Bottom line is I can't disagree more. People familiar with the subject are often lucky to have the team and come with great network of nerd friend. Of course you will find people from this world who don't succeed, but more plenty become fantastic engineers.
A few successful competitive programmers being successful in general doesn't make it a good metric for all programmers. I'd say the same about competitive math too, despite Terry Tao being a pretty great counter example.
What actually happens at all levels below the gold medalist level is completely different. People memorize leetcode and think they're gods of CS. Ultimately, you have to agree, these competitions come down to learning a vast repo of tactics. A guy who is generally good at CS or math can't show up and do well. You have to burn a lot of midnight oil so to speak.
IMO such data structure and algo mastery is largely illusionary. It mainly depends on the trends in the game at that point in time. If you see people who do well in such competitions, they have embedded themselves in these communities and think about it all day. Why should every programmer be held to this arbitrary standard? What if I want to learn ML, compilers and programming languages or study distributed systems? They are as much CS as anything else but you don't get a cookie every time you navigate a tricky situation. There is no gamification so you have to tread your own course. That IMO takes a lot more originality than what these rat races foster.
> People memorize leetcode and think they're gods of CS
how fast you go from 'all levels below gold' to this
while probably such people do exist (never actually met someone who tried to memorize concrete solutions), they have nothing to do with competitive programming. Because you won't go far with bunch of memorized (and not understood) solutions of previous competitions. Even learning basic algorithm's implementations won't get you too high in competitions. Because you actually have to understand different approaches to actually be able to solve new problems.
> A guy who is generally good at CS or math can't show up and do wel
this is also not true. While you won't get like first places without practice, you still will be able to solve basic problems (if your cs degree has any substance behind it). And during interview it certainly shows. Nobody will give you hard problems which you can solve only by having some very specific knowledge of this particular problem. If you don't know some algorithm by hard but still can work out some approach using you background knowledge, you will pass almost any interview.
Smart and works hard is important but I'm very much not convinced that success in competitive programming (or leet-coding in interviews) is the only, or even best, way to signal those attributes to an employer.
I'll also contradict myself on how important smart and works hard actually is. I'm just a normal programmer who has had a few normal programming jobs. The vast majority of my career has been about doing relatively low-key programming and data munging. When I think back on software engineers "in the trenches" of standard corporate jobs I don't see any deep need to be particularly smart and hard working. Maybe "doggedly stubborn" about not giving up and making some progress each day instead.
This post really is a rant as the author forewarns, with barely any cohesion and no evidence to back up anything. I fear it has gotten upvotes simply because it's a popular opinion.
I don't think it's worth a detailed response so I'll just respond to the reductio ad absurdum in their tl;dr, that competitive programming has been taken to extremes (implicitly by employers).
This is plain untrue. Sure a lot of interviews I've been through ask for a coding exam, but in this day and age that's just a wise precaution and no company that I've heard of would hire based purely on that outcome.
I've met (interviewed) too many candidates who can sweet talk their way through any technical matter but barely know how to use a couple of for-loops. This isn't a surprise---the push toward driving down the cost of software engineering labor means that there's a massive volume of people churning through the bootcamp machine.
I wish it could just be blamed on the bootcamp machine, but I've interviewed enough non-junior full time candidates moving from other companies to wonder how they got into those other companies to begin with, based on their performance with my simple problem where loops aren't even needed, nor are there fancy data structures. I used to ask https://leetcode.com/problems/jump-game/description/ but stopped in part because it offered nothing more than pass-fail, in part because of too many fails. Still, it's not exactly a high level competitive programming sort of problem, and there are many ways of solving it...
yeah, for some reason it is a trend to call some basic coding interview problems as something from 'competitive programming'. While in reality it is just on of the metrics of interview - make sure you can code.
While some companies sometimes go too far with complexity of problems, even they rarely make decision purely on how fast you can solve the problem.
Makes sense as a trend. If you fail a "competitive programming question", then it's the employer that's absurd. If you fail a "basic coding problem", then it's you who is unqualified.
I find it fun to do, like chess or video games. But people on these sites grind challenges for hours a day over months purely to game interviews, which is sad but probably not pointless.
Competitive programming is just like a sport, as in every sport some people may like it, some may not. When it comes to programming interviews, companies do not try to check how good your competitive programming skills are, but they measure your will power, eg whether you were able to commit time to learn and understand DS&A in such a way that you can easily juggle them.
I like the coding challenges we have at the office.
The ones who want come to solve a few riddles (this is a nation-wide competition), food and drinks are provided, we have the opportunity to chat a bit and I can claim my last place, live every year.
This allows people who like these kind of things to get together in a relaxed environment.
Yes, this is an event we have once a year. The number of seats is limited but we usually hover at 30-40 people (it is held after work hours, we are dependent on the start time, which is the same for everyone in the country)
hmm. how so? before we rationalize this statement, ask yourself. what is your current skill level in competitive programming? how good is your C++/Python/Java/etc. and understanding of DS/Algo? If all the answers to these two questions are great then congrats, you're great! otherwise... just think about that question, ever felt passionate or enthusiastic about something? competitive programming can be a passion, competition, both of them. if you think it is useless, then passion is useless, solving is useless, problems are useless... competition is a way to keep improving ourselves! improvement sure isn't useless at all isn't it?
> Competitive programming is a good tool for building the programming muscle. An extreme pursuit of competitive programming is worse than useless. Unfortunately, companies and students are both headed in that direction at the moment instead
So if both companies and students are heading in that direction then it's not that useless, isn't it?
This is a low effort anti programming interview difficulty inflation rant.
But anyway, competitive programming is one thing, tech interviews are another thing if you want to get technical about it. Mostly different set of skills are cultivated by each.
Finally, saying competitive programming is useless is equivalent to saying golf is useless (for example). Some people really enjoy competitive programming.
Time to start asking more about security and OOP on interviews
OOP is kind of topic that everybody is expected to know, yet for some reasons there are huge gaps between people when it comes to proficency at it, at modeling systems and domains correctly.
Precisely because huge gaps exist, asking about OOP leads to disappointment. I don't suggest doing it -- or if you do, first try it out on coworkers (even just knowing what SOLID principles are, never mind any nuance about them), and if you're finding that it's filtering them, you don't work at an org where it makes sense to filter new hires the same way.
I think competitive programming is useful as an interview style if you want to learn a language and gain that development intuition of stop, think, clarify, design, code and test. But do I think people are taking it too far? Definitely.
A typical comment or interview experience on Leetcode is that they take 3 months to prepare and do algorithms questions for FAANG interviews to pass the interview. In the process, some individuals skip class or other things. I don't think that is right personally.
There needs to be science on this. Some way to quantitatively measure the performance of programmers who do competitive programming and to measure ones that don't.
Until then everyone will agree or disagree but some science will prove a definitive answer. It is very much worth doing such science given the prevalence of testing a programmer for such competitive skills and the fact that many consider such skills useless against the actual daily tasks of a programmer.
Competitive programming is fun and trains quick and accurate problem solving. You can critique the fact that modern programming interviews seem to be too focused on short leetcode problems, but that is an entirely different field than competitive programming.
"Mathematical textbook problems are useless, because scribbling mathematics in a notebook is not best practice! Real mathematicians exclusively spend their time writing academic papers."
From my point of view, the correlation is definitely not 1, but while competitive code is not good code, and therefore the skills and discipline differ, there is a strong correlation between good competitive programmer and good programmers. Just like sprinters and marathonians, sure best sprinters are not necessarily the best runners for long distance, but they are definitely better than me.
This is a classic example of Berkson's paradox [1]. If the job applications you receive have a positive correlation between on-the-job performance and competitive programming performance, and you use competitive programming performance to select who you hire, then you can very easily end up with a negative correlation among the people you actually end up hiring.
When you don't include the people you rejected in the statistic, the correlation is useless.
nicklaf, I somehow came across your comment from 9months ago about TOS and PoTs. I have been struggling with some issue for the last 4 months and doctors aren’t telling me a thing.
Would you please get in touch with me via Instagram @jesse.brill or Snapchat jessebrill55 or Facebook (search for Jesse Brill in Atlanta, GA) or via email Jesse.brill@gmail.com
I would appreciate talking to you and maybe you can help me.
I did competitive programming. I believe you need to push yourself to your limits to understand what your limits are and why you may have some. It helps with self-understanding. One can then figure out how to go further, faster.
On a side node, it was in competitive coding that I first ran into students using Ritalin for performance enhancement. Until then I had never run into it before.
Years ago I managed to clear super competitive algo/DS rounds for a big firm and then failed spectacularly at the job, because I had no idea what they were talking about half the time the projects were being discussed.
I wish they had just asked more pertinent questions and saved everyone some time and me the humiliation.
Just a tiny bit offtopic, but for a different kind of competitive programming, I made https://yare.io (1v1 StarCraft-like RTS, but you control units by writing javascript).
I never get offended by any news. But this one is on the limit. On my case I wish I would have started before with competitive programming. I learnt skills that almost no one has and I think is one of the skills that makes me unique.
Obviously it’s not useless if people find it useful such as the people who compete. By some metric you care about it may be “useless”, but who made you the arbiter of metrics? Competitive programming may or may not correlate with success at say software engineering, but that isn’t grounds to say it’s useless. An Olympic archer may or may not be a terrible bow hunter in the wilderness but they still have a clear skill that is useful by metrics such as people want to watch it, practice it, and compete in it. Dualist thinking like this where things are strictly good/bad, useful/useless, etc. is a really limiting thought pattern. How about instead of “is this thing useful OR useless?” we ask “in what ways is this thing useful? In what ways is this thing not useful? How can we best leverage these properties?”
EDIT: TLDR: There are bigger issues at play at the country's economic level that students take up skills (CP) to get the best paying job possible. This in turn drives companies to make interviews harder to separate rote memorizers from the crowd. I don't see this going away anytime soon and although I agree that leetcode questions aren't the best measure, there is no better alternative as an interviewer to quickly filter out candidates.
---
> As a response, college students now pursue competitive programming obsessively to stay on top. In this weird arms race against prospective hires, companies keep asking harder and harder questions in a misguided attempt to raise the bar.
You should understand that more students pick it up because of the higher salary offered in the tech industry in your country (India) and this is one of the best bets to lift themselves and their families economically. To be fair, I don't blame them, majority would pick up ~CP~ <job/skill> because it has the highest returns for the effort put in. It's a fault in the system, not the students.
Personally I would be wary of anyone who says only competitive programming excites them. I feel that testing algorithms and data structures in some slightly realistic situation is the only way to weed out the pretenders.
Anecdotally, I have interviewed screening rounds from junior to senior. The juniors who pretend to like programming are usually filtered out when I change the application of the data structure slightly as compared to a leetcode/geeksforgeeks question. Something as simple as "reverse a paragraph/sentence" as opposed to "reverse a string".
Mid level candidates are the most difficult to filter out and this is exactly where the leetcode type questions come into the picture. They are able to talk about their projects as if they designed the entire stack. I have seen them draw the system design diagrams, tell me pros and cons of the stack/tech chosen, but they would usually fail in easy/medium level leetcode questions.
Seniors are the easiest to filter. We give them the easiest question possible and ask them to solve it. This is done with a huge disclaimer that this is a screening round and that the intention is to see you can actually write code and answer questions about it in real time. Questions are easy array/string leetcode setting them up for success. The good ones just finish it up in hardly 10 mins and move on the the design round following immediately. The bad ones just beat around the bush saying they wont code despite the disclaimer. The really bad ones are ones who cite N yoe so they shouldn't be tested on coding (this is when the senior dev steps in and recommends not to proceed with the interview anymore).
Coming back to the article, unless you have candidates/people who are actually interested in building software, and only when other jobs around you on avg pay a decent amount of salary for the place you live in, I am positive people will do everything they can to get the best ROI to become more sustainable in life. This is evident in > 5 yoe hires when people are in a more stable posn in tech economically and as interviewees they realise what they like/dislike and as interviewers you can discern whether they can actually do the job properly.
I understand the rant but I would like to hire someone who are good at solving problems (of any kind) and can detect the edge cases very well and without deep math or competitive programming knowledge, it's not possible at all these days.
However, I am an undergrad myself and sometimes I take pride in being a generalist, spent my fair share of time on every abstraction layers of CS possible. Now that I'm in my final year, I'm concentrating to know more about *nix system internals, doing a thesis on Computer File Systems and occasionally doing Competitive Programming to be a better problem solver.
“ but I would like to hire someone who are good at solving problems (of any kind) and can detect the edge cases very well and without deep math or competitive programming knowledge, it's not possible at all these days.”
You shouldn’t be so opinionated before you’ve entered the work place. If you find, after a few years of experience, that this is true then fine.
My point is competitive programming or math competitions isn't a field specific skill. It teaches you various ways to solve various (life) problems in general. Brute forcing, divide and conquer, backtracking, recursion/Induction can be applied to anything.
I'm not opinionated. If there is any other way of proving that someone is good at these tactics, I'd love to work with them.
I think I read too much into deep. Certainly I'd expect any non-junior dev I work with to understand those concepts! But I wouldn't assume someone who published several papers on knot theory is any better at development that someone who hacked together a couple startup side-businesses, except in very very specific domains.
people spent their bachelors degree solving problems of some kind. turns out problems of different kind requires different bachelor degrees. for porkin sake, people need to grow up and accept that the state of the art measurement models of human raw intelligence have flaws so much that they can be rendered useless.
> "turns out problems of different kind requires different bachelor degrees."
Aren't we talking about CS here. I understand your point ofc. As a CS undergrad, what other options you have to prove that you are capable and know different strategies and tactics (brute forcing, divide and conquer etc) to handle and maybe solve a problem?
There's a lot of complaining about algorithms/data structures interview questions. But at the end of the day it is up to the hiring companies how they want to triage and select candidates. Rather than complaining, what would be more compelling is evidence that companies using these sorts of interviews are actually damaging themselves. At the moment, the most successful tech companies in human history are using those sorts of interviews, so the burden of proof seems to fall on the complainers.
here's the thing, it all comes to attitude. most people who like to solve problems would think otherwise. i think it's healthier in the long term to be more optimistic about this field rather than be realistic.
No, the most useful impacts of competitive programming has to do with actually teaching you how to program effectively. The most important advice I got for competitive programming was walk away from the computer. The biggest trap when programming is to write code before you know how to solve a problem, as this will tend to encourage you to spend all of your time making no progress towards actually getting a solution. The tale of the Sudoku solver [1] is salutatory here.
Another useful skill is how to debug algorithms. Debugging a competitive programming problem usually amounts to taking an input that fails and trying to understand where in the algorithm (as expressed in poorly written and commented code!) the mistake is. Doing so under the time pressures of a competition also requires being able to rapidly decide if the algorithm is wrong, or it is the implementation is wrong, as well as figuring out where the most likely places for errors are likely to creep in. This kind of experience translates very usefully into professional programming, and debugging is a skill that seems to be poorly acquired by most young programmers.
When competitive programming hits the tier where you need to memorize all of the advanced data structures and algorithms to do better, that's where further improvement in the leaderboards no longer translates to better programmers IMHO. But there's still a lot of skills that need to be acquired to move up competitive leaderboards before you reach that point.
[1] https://ravimohan.blogspot.com/2007/04/learning-from-sudoku-...