I am a self taught developer in my first real job doing it. There seems to be two types of programming: magic algorithm programming, and API programming.
Most job prep seems to focus on algorithms. The algorithms are easy to test, because there are clean metrics (does it work or not, efficiency, etc). Also they make people feel clever. Finding the most efficient way to transverse a bidirectional, weighted graph seems more important than finding the right function. This is amplified when implemention in some esoteric language like lisp or Haskell (sorry fanboys, its esoteric when its less than 1% on TIOBE). But most programs/apps/services may only implement one of these at their core. If you are building a database or search engine, you will run into these more often, but its limited for most people. CS seems to focus much more on this side of programming.
The second form of programming is API programming, and I use this every day. This includes both finding the right function to use (or close enough) or creating API functions with sane parameters and results. This is much less glamorous, and is theoretically covered by "read the manual." But it is much more nuanced than that. Parameters may not be named the same thing or have the same form between APIs. Handling sync for async function calls are important. Hell, even defining the problem before finding a function for it can be difficult. APIs are the meat of programming. Designing and using them is definitely a required skill.
Being self taught, I learned much more about APIs than algorithms. I am not bad at Math, got a minor in it, but some of the algorithms blow my mind. But I am glad I learned APIs, as I use them every day. If I need to deep copy a map, I use a function.
There is also a third type - "find what this code does (sorry no documentation or comments), then fix this specific bug (or make this specific change), without breaking anything else" programming. A lot of people who work in well established product/websites etc do this type of work most of the time. Few lucky ones get to build something from scratch, which would fall under API programming I suppose.
Scaringly accurate description of my job. On occasion I get to write code myself to solve a problem - but most of the time it is "go dig through 1,500 lines of mostly undocumented Javascript and see if you can make it do [this] instead of [that] without breaking anything".
What little documentation there is typically `TODO: FIX THIS` or `This was the only way this will work and I don't know why.`
Then you realize how much of the world's code is like this and wonder how anything ever works at all. I absolutely love this story [0] for explaining it in a way anyone can understand.
You're treating CS like its composed of two different divides ("algorithm programming" and "API programming"), when in fact I think you're forgetting that algorithms can be used as the proper foundation for API programming. Handeling asynchronous calls in the proper manner (as per your example) is extremely similar to the consesus algorithm I learned in my distributed computing class. I doubt I'll explicitly be asked to implement a meldable priority queue like my professor assigned in algorithms class, but is the process of designing an algorithm and its implementation to conform to a specific requirement any different from "defining the problem before finding a function"?
I heard a while back that Facebook's mobile apps contain some ludicrously large number of classes when decompiled. And their interview process has the same philosophy you've outlined here, which I think provides the obvious explanation: since algorithms are so foundational, every developer who works on one of the apps is required to first write their own from-scratch reimplementations of all the data structures and core algorithms, and add them to the app.
The two sides can both fall under the the "problem solving" category. An expanded definition of algorithms could include designing APIs. But in my example I was referring to algorithms as rigorously mathematical problems with a proof based solution. Choosing if I need a synchronous or asynchronous file read function does not fall into this category.
> Finding the most efficient way to transverse a bidirectional, weighted graph seems more important than finding the right function. This is amplified when implemention in some esoteric language like lisp or Haskell
Actually I'd say Lisp and Haskell programmers are much more likely to be "find the right function" programmers.
Most job prep seems to focus on algorithms. The algorithms are easy to test, because there are clean metrics (does it work or not, efficiency, etc). Also they make people feel clever. Finding the most efficient way to transverse a bidirectional, weighted graph seems more important than finding the right function. This is amplified when implemention in some esoteric language like lisp or Haskell (sorry fanboys, its esoteric when its less than 1% on TIOBE). But most programs/apps/services may only implement one of these at their core. If you are building a database or search engine, you will run into these more often, but its limited for most people. CS seems to focus much more on this side of programming.
The second form of programming is API programming, and I use this every day. This includes both finding the right function to use (or close enough) or creating API functions with sane parameters and results. This is much less glamorous, and is theoretically covered by "read the manual." But it is much more nuanced than that. Parameters may not be named the same thing or have the same form between APIs. Handling sync for async function calls are important. Hell, even defining the problem before finding a function for it can be difficult. APIs are the meat of programming. Designing and using them is definitely a required skill.
Being self taught, I learned much more about APIs than algorithms. I am not bad at Math, got a minor in it, but some of the algorithms blow my mind. But I am glad I learned APIs, as I use them every day. If I need to deep copy a map, I use a function.