Competitive programming is a type of programming competition where participants compete against each other to solve algorithmic and computational problems in a limited amount of time (usually a few hours). The competition typically involves a set of problems of varying difficulty levels that participants must solve within a fixed time frame. The objective is to solve as many problems as possible and score the maximum number of points.
Competitive programming is often used as a way to test and hone programming and problem-solving skills, and it is popular among students and professionals in the computer science and software engineering fields. It can also be a fun and challenging way to learn new programming concepts and techniques.
While it may look at first a good idea for an enterprise to have such programmers that are able to program fast, I'd be wary about the code quality, maintainability, or even merely its adequacy to user specifications. And yes, about run-time too.
One can argue that if a competitive programmer finds a solution quickly, he has time left on his hands to fulfill those additional goals. It's indeed the argument used eg. by Lisp programmers, where the speed of reaching a solution is helped by the quality and high-levelness of the programming language, rather than brute competitiveness of the programmer. Then time is left to optimize the program if there are parts, or algorithms that are too slow for the user. But remember than the best gain of run-time performance are obtained by choosing the right data-structure and algorithms, rather than micro-optimizing and hacking.
There are multiple dimensions and notions behind the word "performance". Recently, energy efficiency has become an important performance parameter (you may choose an algorithm because executing it consumes less energy). Of course, companies may need programmers competent in various performance optimizations. Among other competencies...
I'm not competitive at all, I'll walk away from anything that even looks like a competition. If you want to prove you're better than me, go find someone else to distract, whatever, I'll give it you you, you're so much better, here, now go pat yourself on the shoulder.
Yet, I care deeply about performance. Maybe I can't write code that's more performant that yours, I don't know, I don't care about being comparatively worse or better than someone.
But I care about writing fast code, and I enjoy cooperate with people who care, too.
If you micro-optimize every piece of software you write that will be a problem. First, it’s a tradeoff. You are going to produce code that abuses obscure methods or hard to follow semantics in order to theoretically boost performance. Why theoretically? Because your whole optimization is pointless unless your code runs as a separate application and you already profiled it on the target where it’s supposed to run.
Second, you’re wasting time for a benefit, that’s not accounted for. You are not paid to produce the fastest code known to man. You are paid to implement features. And unless the wins are huge or the optimization is a no-brainer (e.g.: string builder vs string concatenation), you’re delivering the wrong values.
So while we do care about performance (albeit a bit less than we probably should), the performance problems that we have are not solved by micro-optimizing some piece of code like it’s done in coding competitions. You need an understanding about the whole system, how parts interact and what the performance requirement is. Because even if you reduce the time it takes for your code to run by 99%, it’s of no use if the code than needs to wait for a network call anyway, making the whole effort worthless, because the overall time is the same.
So while it’s a nice exercise, it’s not what’s needed in the field. Just make sure you do the obvious optimizations and try to avoid the obvious pessimizations.
Lots of people just keep repeating and misquoting Donald Knuth on premature optimizations being evil. Then there are others that say it won't be worth their salary.
Would non-programmer managers / product / etc actually know or can tell? I've seen lots of cloud invoices that can easily be chopped in 1/2 with a click of a few buttons or code changes. In lots of instances you can upgrade to a newer OS or runtime with no compatibility issues and yet they still don't do it. Some don't even bother turning on Brotli or http2 or http3 when they use Cloudformation i.e. it's a 1 line change.
Then there are programmer managers that have drunk too much cloud kool-aid and only talk about horizontal scaling. It's another reason they don't care about performance. Just take out the wallet because the company pays.
All in all I've not seen enough to say the company doesn't care - it's the people.
I care about performance. I try to write good code and deploy good infrastructure. I try to influence others on it, but more often than not there's always push back and it's never by the business side. If you tell product you want to make it faster they'll probably be happy.
Competitive programming may help hone your skills and build a network, but probably not something employers care about.
Employers value teamwork and adding business value by solving problems. What programmers do for fun or think important may not mean much in the business context.