[lhorie]

> I don't see however why being able to think algorithmically should be more important than knowing how to glue libraries together

There's a pretty wide scale in terms of what exactly that means.

On one end, there's the status quo of what is expected of a candidate for a certain type of position. Recruiters sometimes do just spam people based on the results of some linkedin/github crawler, and having a github presence doesn't necessarily mean the candidate has coding chops (I've seen my share of people w/ portfolios consisting of hack reactor assignments). For most tech interviewers, doing the "due diligence" of evaluating a candidate might mean ensuring that the candidate can deal w/ recursion or async or other relatively mundane aspects of programming which are nonetheless algorithmic in nature. "Algorithms" doesn't necessarily always mean inverting binary trees or geeking out about sorting algorithms.

On the other end, there are roles that are very specifically NOT about writing cookie cutter React+Tailwind apps, and which do require having at least some algorithmic chops (for example, in my current job, I've had to use hashmaps/sets to deal w/ performance of recursive graph traversal routines on various occasions). Despite specializing in Javascript, my involvement w/ React might be limited to explaining to a product engineer why class properties might be throwing syntax errors or explaining WTF are stale closures in the context of useEffect or explaining what's the relationship between peerDependencies and referential equality, rather than directly writing any JSX per se. No doubt you could pick up those troubleshooting skills while building CRUD apps, but those are ostensibly not the sort of thing that you'd be expected to know for a run-off-the-mill React job. But being able to deep dive into these types of things day in and day out may be well within the scope of what's expected of a platform/devexp/productivity engineer role.