[pscanf]

> you're actually able to think algorithmically or are just gluing libraries together

Going a bit off-topic, I don't see however why being able to think algorithmically should be more important than knowing how to glue libraries together (not saying you were implying it, just wanted to share a thought).

I feel like 99% of my job as a developer doesn't go beyond the complexity level of "take a list of things, do something with each". On the other hand, a very important part of my job is to figure out how to glue things together so that they fit well and I'll be able to glue even more things in the future. Admittedly I do pretty run-of-the-mill web stuff, but - looking at job boards - it feels like the vast majority of jobs are like mine. So - for those jobs - I'd think that having a good gluer is more important than having a good algorithm-er.

[taylodl]

My team refers to at it as "plumbing" - we are modern data plumbers. We "glue" the pipes together to make the data flow. Ever see spaghetti plumbing? Some application architectures look like that. It's just easier to hide because normal people can't see what a wreck it is. Anyway, there's no shame in being a data plumber.

[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.

[toast0]

Algorithmic thinking and gluing things together well are both important. Algorithmic thinking is easier to test, I think, and also harder to teach.

I don't think you really need to spend 4 interview slots on it though. Two slots should give you enough signal there, IMHO, or you're not giving the right problems; possibly three if you get solid maybes from the first two, but then you're missing out on whatever your other slot was.