Comment by lolinder
2 years ago
Don't competitions usually have completely different kinds of problems than what you typically run into in production fires? When I think of competitive programming I think of algorithms and puzzles, not network errors and data corruption.
In my experience production fires are rarely put out by rote algorithmic knowledge, the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion based on the very limited information available in the average production monitoring system.
This is my understanding as well. Rare is the day I’ve solved a production firefight by editing some algorithm - it’s almost always arcane configuration, restarting services in the right order, some network thing flapping/dos-ing the rest of the system, some service aggressively restarting and dos-ing others, actual malevolent dos, noisy neighbors, resource starvation, etc.
Yes, it's not the full equation. But that type of environment gives you a mindset that isn't present in most other types of coding. The ability to think under pressire, identity the fastest solution, and store a number of approaches in your head should you encounter dire edge cases.
.
>the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion
Yup, and that's transferable skills from competition coding. You're not juggling algorithms in your head per se, but you juggle whatever tribal knowledge needed as options to cycle through. That combined with the above mindset can lead to such skills.
It still seems a bit of a stretch to jump to the conclusion that someone who's good at fighting production fires probably has experience with competitive coding. You could maybe conclude that they would be good at competitive coding were they to try it, but competitive coding is way less popular than just... having a career in software.