"Hard problems" are risky business ventures. In my career, we've done a couple of things that would be considered "hard", but in each case we've leaned heavily on papers published in academia. The best example might be when the team I was on did shape recognition from hand drawn shapes to shape objects in a drawing application. I've occasionally been asked to solve some hairy caching/concurrency problems, but again I've gone straight to the literature.

My brother worked in a company that was doing circuit board design (simulating crosstalk, etc). Their work was highly theoretical, but they had electrical engineers doing the research (and were actively collaborating with a university). His job was 99% implementing code.

I feel that programming is more about handling complexity than it is about solving other problems. You sometimes dip your toes into solving problems in other domains, but the biggest value you can give as a programmer is in creating a code base that is both simple and sustainable (and keeping it that way). This is the hardest problem I've ever worked on by far. It dwarfs any of the other problems I've tried to solve. I sometimes get a bit depressed that others don't consider it a "hard" (and therefore interesting) problem.

In my experience, less than 5% are actually writing algorithms and solving harder problems. I work at a consulting firm with 100 or so developers, and most seem to do "simple" stuff most of the time.

The most complex thing I have heard of is someone who wrote a kalman filter thing for some part of a nuclear reactor. To me it seemed hard since I don't understand the math, and apparently people around him was happy with his solution.

Also here in Sweden I don't think the CS algorithms are very important at all when getting a job. I have just not seen it that much, which is sane since nobody seems to really need it anyway...

The big secret is that everything is a CRUD app. It doesn't mean that the C, R, or U steps can't involve hard problems.

I had to implement a quadtree from the ground up, because existing solutions didn't work, when working as an SAP consultant on some dashboarding tool (I also had to know what a quadtree was!)

I now work in a generic unsexy role doing release engineering. About half my job is generic software engineering, but the other half is comparatively academic. I was reading academic papers on Aho-Corasick derivatives last week and writing statistical tests in jupyter notebooks this week.

And my interview questions are generally inspired by problems I've had in my work, just normally somewhat simplified since the way I phrase them justifies the need for a specific class of solution much more clearly than whatever nonsense I encountered in the first place.

I would risk to say 95-5% Mostly researchers are creating those solutions for hard problems, and, in the industry, only a few have to bash them. The rest of us are concerned with keeping APIs responsive and getting that damn button the correct shade of blue.

Sometimes boring CRUD apps turn into interesting CS problems due to the data model and ways that the customers expect to visualize the data, while keeping the application responsive.

No idea, but based on other comments here it seems that a significant number of HN users who commented here are in the CRUD apps and/or yet another SAAS app category.