A part of his summer project was to make some api calls to a soap endpoint. We were all very busy so he tried to be as self sufficient as possible and not ask questions. After about a week, he comes to me with questions about soap xml schema and implementation details.
He did not understand it's already built into the tooling. You literally drag-n-drop a url endpoint into your project and get a proxy class for calling the soap endpoint. He was way off into the weeds trying to finish his project. A little guidance helps.
Still, I don't consider it a big failure. A lot of people go through life using technologies without really knowing how they work. He could have very well drag-n-dropped the soap endpoint and never learned a thing about soap. Now that he knows a bit about it he may alter his decisions in the future knowing the guts e.g. 'don't do that because it won't work through soap' etc.
I've had scenarios where I spent an afternoon building a little one-off application I needed for some specific debugging task only to be told a month or so later that someone already built a proper tool for that - but only one developer knew about it, and it was stored in a different repository I had no access to.
They may think the old programmer are leak of passion, just there to do their part of job, not creating things and "Change the world" like they do.
For example when you tell them to parse HTTP header with a 256 buffer, they may argue why not give me 4K buffer so they can done it more easily, "It's fine to use 4K for that, just install more memory".
I've had discussions with "industry veterans" that didn't get the fundamentals about their machines straight (a couple of them, for example, seemed to be ignorant of the fact that caching is a thing and influences your memory access delays).
Usually, that wouldn't be much of a problem, except when they claimed authority on performance and how hot-path algorithms should be implemented. The upside to those discussions is that they're usually easily settled with a couple of benchmarks and unit tests.
Similarly, I'm often puzzled whenever I encounter someone who works on a ("official") C++ project and e.g. refuses to use RAII and/or const properly. I get that you might dislike to depend on too many "external" tools, but just throwing the upsides of the language you're using away because "that's not how we did it back in the day" really bugs me. I can't avoid the impression that those people are being willingly ignorant...
I remember when I started out that I'd scour every line of code for memory leaks and optimize the hell out of it. Today we've got more memory, faster machines, and the code doesn't need to be quite as tight.
Mentorship goes both ways. I help newer devs about processes and patterns. They help me with new technology and trends. I think it works well but it requires patience on everyone's parts.