It's very unhealthy.

I found in previous years I gave up a few puzzles in, so I need some community to keep the interest up. But I have zero interest in the competitive aspect.

Admittedly I did used to spend a lot more time commenting and posting here when it existed, and have since slipped way down :-)

The leaderboard is not important.

I don't think I've ever been quick enough to figure on the leaderboard. I'm not a competitive person so that aspect of it doesn't really appeal to me and I've been able to totally ignore it every year without it really intruding on me or causing me any stress related problems.

You're imaging a scenario which doesn't really exist with this "ignorant recruiter" situation. Why not just worry about that if / when it really does become a problem...?

We can look at a myriad of potential stress factors that come out of the design of so many every day items. We'd be overrun with worries if let them dominate our mind.

Just chill out and try to ignore the competitive aspect, its not that difficult

Talk about dismissive and unnecessarily condescending. Consider arguing against ideas, not tone.

Since only the first 100 get points, it's really easy to ignore the leaderboard. Odds are against you when (at least in the early days) 30-50k people are competing.

I generally agree with the sentiment and the leaderboards themselves feel very silly.

Advent of Code for me has always been about creativity, learning new languages, some fun with co-workers. Occasionally after finding the simplest solution, I'll try and work out algorithms with better performance, or even read papers on the underlying fundamental computer science problem involved. But I try to write the code as I would in the day job, and so I always use the example inputs to write unit tests and I always try to refactor stuff to be readable. I'd much rather see code I could imagine working with in real life on someone's GitHub profile than something absurdly terse.

All that said, the puzzles this year have been pretty simple and do seem slightly more optimised to people on speedruns than some years previously, so it's not been that stimulating so far.

- When to use CFG versus regex for parsing. Many inputs could be parsed with regexes if you made certain assumptions and got lucky. But CFGs were much easier for some.

- Shunting-yard algorithm. This came up, I think, in 2018.

- Using fast/slow to detect cycles and cycle length (one step at a time versus two, when they collide you can determine that there is a cycle and then determine how long the cycle is). Most used a hash table/map but this was not effective (due to RAM requirements) for some very large inputs. This actually comes up a few times. Variants of game of life, or just numeric processes.

- Multi-threading. It was very useful to implement the intcode VM using threads in 2019. Everyone who tried to juggle state and run multiple VMs at a time struggled when we later had to have a large number of VMs communicating with each other.

- Maybe not CS proper, but typically covered as part of a CS curriculum in a discrete math course. Several times problems related to modular arithmetic and permutations came up. If you understood them, the problem was tractable. If not, you struggled and maybe solved it but it wasn't efficient.

- Various graph and search algorithms. Particularly A* and Dijkstra's. Looking back, it seems there were a couple maze ones in 2019 and several more maze/path finding ones in 2018.

- Sorting/ordering of graph nodes, specifically topological sort. If you know what it is, it makes several of the problems much simpler over the years. I think it was specifically used in 2018.