Competitive programming is useless
kislayverma.com
kislayverma.com
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-...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
https://github.com/kth-competitive-programming/kactl may also be of interest, it contains a good amount of the algorithms/DSes you'd ever need on a few printable pages (20ish).
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.
was it actually the reason?
There was an article [0] and subsequent discussion on HN [1] about reverse engineering and patching the binaries.
[0] https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
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.
Strongly disagree. The GTA developer basically designed an algorithm which loops items in an array, and for each iteration in the loop, they parse the entire JSON that contains all items, and they do lookups for duplicates from an array instead of from a set. This is like a quintessential example of an algorithm design failure, so it seems weird to me that you're not attributing it to a failure in algorithm design, but instead you pass the buck to creators of the library that the developer was using. Sure, the library methods could have been documented better, or implemented differently, or whatever, but that seems like an entirely unrelated discussion.
> "this method that I think is O(1) is actually O(N)"
I'm fairly certain the developer in question does not understand / care what big-O notation means. Therefore, this almost certainly is not the thought process that lead to the slow load times in GTA. More likely the developer was just mashing things together until "it works".
tl:dr; O(n^2) string parsing and O(n^2) duplicate removal
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.
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.
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.
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.
I am saying that being able to regurgitate an implementation of quicksort (to keep on the sorting example) onto a whiteboard is not a useful skill. There will never be a need to do this in a real life job.
The truly useful skill is being able (and interested!) in using a profiler to find bottlenecks, identify what is being done there (let's say, sorting) and being able to find a better replacement algorithm in the literature and change to code to use a well-optimized implementation (which exists already in just about every ecosystem, no need to reimplement it from memory).
In that case I'm not sure why you're arguing against me, because I've repeatedly expressed my dislike towards algorithm memorization. I don't believe memorizing algorithms is useful at all. It might give a very small edge in competitive programming, but it's not what competitive programming is about either. The best competitors have amazing skills at creating algorithms to solve problems ("create" as opposed to "memorize").
If you look up the parent thread, you started arguing against me when I said "Developers who have no interest towards algorithms will not [be good at some things]".
> Competitive programming is a good tool for building the programming muscle. An extreme pursuit of competitive programming is worse than useless.
Interviewer: How do you swap two variables without using a temporary variable?
Candidate: x = x + y; y = x - y; x = x - y!
Interviewer: You're hired!
... two months later ...
Boss: What the hell is this code you wrote?
Programmer: I swapped two variables without using a temporary variable!
Boss: You're fired!
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?
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.
Let’s discuss it now: they are NOT ‘less smart.’
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.
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.
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.
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.
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.
Uber's hiring pipeline was a mess.
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.
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...
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
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.
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.
Which is it, statistical or anecdotal?
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.
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.
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.
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.
I attended a top school. I can assure you my classmates weren't on the whole more intelligent. They did have more drive, better study habits, more external forces (parents) pushing them. Some were extraordinary, but not the average. I would have trouble saying as a body they were more intelligent than say those that went to large state schools.
I attended a small state school for undergrad, and a top school for grad school. There were no extraordinary students at the small state school. I was top of the class. When I went to grad school I was quickly humbled as very much average in that selected group. Everyone studied/research all day long in grad school, it wasn't really a matter of who was more driven, everyone was driven.
All my point is and has been, is that extraordinary people self select to go to good schools. That brings up the average overall compared to low rank state schools.
>Once scholars control for all these factors as best they can, they find that coaching has a positive but small effect: Perhaps 10 or 20 points in total on the SAT, mostly on the math section, according to careful work by Derek Briggs of the University of Colorado Boulder and Ben Domingue of Stanford University.
[1] https://slate.com/technology/2019/04/sat-prep-courses-do-the...
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.
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.
Maybe we have different definitions of average, which seems to be a hacker news bias, schools in the top 40 are not average by definition
, but many many schools offering math degrees don't even offer classes beyond that level.
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
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.
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.
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.
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.
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.
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.
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.
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?
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?
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...
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
"Mathematical textbook problems are useless, because scribbling mathematics in a notebook is not best practice! Real mathematicians exclusively spend their time writing academic papers."
When you don't include the people you rejected in the statistic, the correlation is useless.
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.
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.
I wish they had just asked more pertinent questions and saved everyone some time and me the humiliation.
---
> 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.
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.
I understand the rant.
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?
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.
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.
Oh you're using it to pick who to hire to write mostly CRUD apps? Yeah, don't do that.