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.
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.
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.
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.
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.
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.
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.
was it actually the reason?
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.
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.
> Competitive programming is a good tool for building the programming muscle. An extreme pursuit of competitive programming is worse than useless.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
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.
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?
Oh you're using it to pick who to hire to write mostly CRUD apps? Yeah, don't do that.
