All the programming tutorials and courses out there are for absolute beginners. I can't bear watching a 15 min video that explains what scope is to get that 30 sec specific to c++ language.
I learned C by writing a video game using it (so far in the past that it was the only real option for games).
I learned VB by taking a job at a shop that used it, then C# when that shop migrated to .NET.
I learned Ruby because that was the best maintained AWS library back in 2006, and my stuff was failing due to things their C# libs couldn't yet fix.
I learned Python by taking a job building a site with Google AppEngine back when Django was its framework of choice.
I recently (re-)learned Java by taking a contract gig at a java shop.
It helps if there is some code already written, so that you can see what things are supposed to look like and get a feel for how things work in that language. I find that I can drop in to a new codebase in an unfamiliar language and make meaningful contributions on day one, if there are bugs that need fixing or simple features that need tacking on.
Talking with other devs, it sounds like my experience is pretty typical. A straw poll showed that nearly half the devs on that Java gig were C# guys who either had never used the language or hadn't touched it in years. We all got bit by (myString == "whatever") never returning true at least once, but for the most part it's just computer programming. Once you know how to do that, the language itself isn't too important.
If you want a good course go for the courses that have 35+ hours of content and go through everything. Remember you are a beginner in the new language so skipping anything is not advised as you might miss out on something important that the experienced engineer is laying down in the course. They normally learn the material they build from the courses from the big books and take bits and pieces of what the books have to condense them down into something a little more light weight.
As when you are sitting at the day job and have over 1 million lines of C and C++ code to go through you really have to have a good grasp on the basics and hard parts of the language to be really effective. Being a junior engineer on the most important project a company has requires some serious reading and implementation time on and off the clock to understand what is going on.
The best part is if the more you dive into the big books the faster you will be able to read them and apply what you learn and profit from that new knowledge. Things really come together when you are able to use knowledge of the base languages (C, C++, Rust, Go, etc.) to help troubleshoot problems in the higher level languages that may pop up as engine errors (PHP, Perl, Ruby, Python, Java, C#, etc.)
Just remember there is no shortcut to becoming a truly experienced engineer. Some point you will have to pick up the big books and dive deep and implement what you learn. Those that do not do it normally reach a plateau in their growth until they take the plunge into the big books, code/developer documentation, etc. and to understand it you have to also implement it and work with it on a daily basis.
For C++, I'd download a working draft of the standard, that + examples on stackoverflow will teach you more than a 6 foot stacks of the latest books on the subject.
Read a quick tutorial
Start writing code and googling the things I get stuck on
You can often find X for Y Programmers, e.g. C++ for Python Programmers that might be a good fit, though I can't say I really used any. I asked my coworkers some dumb questions when I got started about compile errors I couldn't figure out which helped.
I definitely wouldn't watch videos, as you say, it's really hard to find the bits that you need to know in video.
C++ is kind of an unusual case -- it's part of that rare class of languages that are so bloated that they can't be 'learned' per-se, because nobody can keep the entire core language in their heads. Luckily, it's a mish-mash of languages most developers already know: it's C with java-like "object orientation", minus the constraints against multiple inheritance, with a grab-bag of strange implementations of familiar features provided by the STL. So, it's possible to limp along writing almost-C or almost-Java and then consult documentation when you run into a difference.
I would recommend against tutorials. The best tutorials take you on an illuminating tour of the philosophy of the language with a handful of illustrations in the form of real code; a normal tutorial covers the domains the author thinks are interesting while totally ignoring everything necessary to solve the kinds of problem the reader needs to solve (which the author is totally unaware of); a bad tutorial is wrong or misleading because it's written by somebody who also doesn't know the language. The more popular a language is, the more likely any given tutorial for it falls into the 'bad' category. Courses have the same basic problems as tutorials, but are substantially longer. Push comes to shove, if you need code in context & there's somehow no code already on your machine in that language (which may be true of APL or Julia but is very unlikely to be true for C++), look the language on X in Y Minutes or Rosetta Code.
Once you are comfortable, its better to hit the ground by building a small POC or a small project.
In my case, I learned languages and frameworks including React in a similar way. While creating a project in React, I came across advanced topics like Redux, GraphQL. I hit pause button and spend few hours looking in google on Redux and GraphQL. That's how I utilized my time in learning new languages or concepts.
2. For me, it helps to have an actual problem that I want to solve with the new language.