How to deal with developers who need too much hand-holding and basically seem to want to go back to waterfall (100% of the design and analysis done up front by others)?

We have a couple of team members who are semi-experienced developers (i.e. not straight out of school, but 3-4 years of experience) who I simply don't know how to deal with anymore. They should be developing some amount of independence and problem-solving skills, but there is just… no progress, at all.

TL;DR: Does anyone have any resources (books, videos, etc) less about programming and more about how to work as a software developer, with everything that entails?

So, long version. Some example problems:

  • If there is something in a user story that they are unsure about, instead of asking questions to the product owner – who is literally right there six feet away from us – they will complain that things aren't 100% clear before they start, including what pieces of code to change. Which brings us to the next problem:
  • They expect user stories to be an implementation guide, not a functional description of what is needed. We have tried to suggest they come up with a suggestion for how they would solve it and discuss with us before implementation, but it's like they don't even know what that means. And if, for example, something they're developing requires a new app setting (which they will never figure out on their own, but have to be told by someone else after hard-coding it initially), they will complain that the user story didn't specify the need for this new app setting, and ask if this should be a new story.
  • Their brains just work in a way I don't understand, which overcomplicates everything, and I don't know how to help them think differently. As an example, we had a (technical) user story stating that when sending messages to topics on Kafka, a specific field of the message should contain the name of the topic the message was being produced to (don't ask why…). Instead of thinking that maybe, just maybe, whenever we produce this message and place it on a topic, we have the topic name available as a setting, their implementation was to hardcode the topic name on every type of message, and solve the issue of the topic names being different in dev, test and prod by making a shared, generic EnvironmentHelpers.GetEnvironment function that was not generic at all, but instead returned the naming convention for Kafka topics in the different environments (which for production was nothing, so if you happened to use EnvironmentHelpers.GetEnvironment() in a different feature in production, you'd get an empty string)
  • One of them was extremely confused when we talked about the vertical-slice architecture. Not just because he'd never seen it before, but because he didn't understand the concept that there were multiple ways of structuring applications and that one isn't necessarily right or wrong, but that you have to make choices when you design programs. Which explains why he will ask others every time where to place his files, but like… "normal" developers would look at the existing structure of the app, and combined with some documentation and perhaps a few discussions, understand and follow the existing architecture after a little while?
  • You can never assign them any user story that requires any amount of research before implementation, because they will complain that they don't know where to start even if you've given them a link to the relevant documentation, and when you tell them that they will have to read up on it and see what the recommended way of doing it is, we're back at the previous problem where they just want the user stories to be an implementation guide.

Basically they need constant hand-holding and none of us have time for that. We do try to pair them up with other developers, but this slows down the entire team and it's now been well over a year of us trying to do this, and absolutely nothing has changed. I've worked as a developer for 10+ years and while I've come across lots of different problems with team members, this one has stumped me because I don't know how to teach them when our usual methods of how to get new people up to speed have failed. It's like they need to learn how to think as a developer, and also how to work in software development. Which I and most other people I've worked with learned the basics of in uni but then properly once we started working, by just… doing the thing, absorbing the culture and how things were done. Other people on the team have done this without issues, so I don't think the team is the problem.

They have expressed an interest in learning more, but their focus seems to be on following YouTube tutorials for fun little projects, not in actually how to function as a developer and working with functional requirements, other team members and being more independent.

Does anyone have any suggestions on things we could do to help this situation? Any resources that could be helpful that are about more how to think as a developer, other than how to implement fun little hobby projects? I could hand them a book on the fundamentals of software architecture, but it feels like the problems are bigger than that. I'm a consultant, so I don't really have much of a say as far as the composition of the team goes.