The series I watched was excellent though! Highly recommended, it's a lot of the same material as his book Elements of Programming but I found it more accessible in the lecture format.
If you can understand how to use the STL properly, you're well on your way to becoming a profiicent C++ programmer.
His books are fantastic too.
Elements of Programming:
and From Mathematics to Generic Programming:
If you prefer video lectures, his second book is based off his lecture series Four (three) Algorithmic Journeys:
It's a combination of history and math/algorithms and programming (using C++). If you're just looking for a straight intro to C++ course this isn't it. But it's a ton of fun and the generic programming/STL mindset is very powerful.
Programming Conversations is another great lecture series by Alexander Stepanov:
I would also recommend searching YouTube for videos by Sean Parent. This one in particular is very enlightening:
Sean Parent is very good at getting you in the STL mindset and showing off the expressive power of using the standard STL algorithms in your code. Except in the simplest cases, you should try to use them instead of writing your own loops.
Here are some random tips if you're coming from C or Java:
"new" is not the way to create objects in C++. new and delete should almost never be used by serious programmers in C++. Never use new and delete (or malloc and free). If you want a dynamically-allocated array, use the standard vector.
It's much easier to write C++ than it is to read it. This is because you can always write using a simple clear subset of C++ that you understand. Try to pick a style that you think as many people as possible will understand. Programming languages are for humans to read. I try to write code that I think C programmers can read.
Edit -- Another tip:
Exception safety isn't about C++'s exception-handling language feature. Exceptions still happen in C. There's just not a language feature that directly expresses them.
Writing exception-safe code is nearly impossible in C. RAII and C++'s built-in exceptions make it possible. If you're careful to always use RAII by default, you can get the basic exception safety guarantee automatically without thinking about it. And you can get the strong exception safety guarantee whenever you need it.
While I don't disagree with the sentiment (quite the contrary), if writing code that C programmers can easily read is the goal, using the STL is probably not the best idea.
Personally, while I'm very biased by my usecase for C++ (compute-bound performance sensitive numerical code), I quite enjoy writing code that's essentially C with function overloading, operator overloading and a few judiciously placed templates. I don't miss the STL, OOP, smart pointers and the rest, and the language suddenly seems much more concise and convenient, not to mention compile times are virtually instant and debug builds aren't unusably slow any more. YMMV, of course, everyone should pick the subset of C++ that suits their usecase and relevant constraints.
Anyway, what are the other better books for C++ that is compact, easy to read while keeping a simple structure?
The OP wasn't asking about just online lectures, it was asking about MOOCs. The best MOOCs I've taken strike a really good balance between lectures, additional reading, and exercises that are automatically graded.
A lot of books don't have any exercises, and the vast majority of the ones that do have no method of verifying it was done correctly.
So maybe today the best C++ book is better than the best C++ MOOC today, I've no doubt that a MOOC could be designed far better than any book could ever be. And I'd bet that's exactly what the OP was trying to find.
I read text all day. Watching a video is novel and exciting, and I think I tend to pay more attention because of it. But that's just anecdotal. Grinds my gears when people suggest that "books are the best way to learn" any kind of programming language.
It cover very smoothly most of the main C++11/14 features, while explaining the pros and cons and the inner choices that has been made when those said feature were implemented
Highly recommended book by the community
The videos from Herb Sutter  will usually emphasize best practices and give great examples, although he expects the audience to have a good bit of familiarity in regards to 'modern' c++ elements (C++11 and beyond).
auto main(int argc, char* argv) -> int
Auto forces you to think about the general relationships between types. In a sense, it really brings all of the elements of the language together.
You are right about the joys of auto with regard to template types and deduction but the implicit type conversion in C++ is a big danger; far better to be explicit about what a function is returning for the most part due to your inability to constrain the implicit conversions; it also helps with maintainability as you can read through small portions of a giant codebase without having to have a holistic overview of the entire system - you can treat each section in isolation because it is explicit in what it is returning, so you can make decisions as a maintainer based on the explicit information in front of you instead of the "it might be this or it might be that" scenario that auto (as a return type) offers.
(I'm not saying auto is bad, but should be used with caution for the return type of a function as it makes the code impossible to understand without an IDE - from looking at a diff between two files, how do I know what it is doing or make a fix under pressure?)
Auto when used as a shortening of lengthy template iterator variables, then yes I heartily welcome them.
If a type name is small then being explicit about the type name can be much more clear since it can save someone having to hunt down what type each function might return.
Of course, in the case of types that are the results of other templated types e.g. T,U -> V then it makes sense and it is obviously welcomed in the syntax of lambdas (far more sensible to me than the C# syntax or C#'s Func) but the use of it everywhere seems foolish.
If it were a good idea, then we would be pushing to remove the return type being at the beginning of a function at all; please say this isn't the case!
main(int arg, char* argv) -> int
or complete stupidity that makes it impossible to read without an IDE (e.g. in a diffing tool):
auto main(auto arg, auto* argv)
When it turns into that, I'm quitting the industry.
This is not what auto as a function return type is for. Auto wasn't invented so people could put int on the right side of a function.
There are two reasons to use it. The first is similar to using auto for a long type name. You can use decltype to declare the return type to be the same as the resulting type of an expression. The second is what you mentioned, keeping in mind that you can use template types in the decltype expression.
Dealing with an extensive large and complex 5 million line C++ codebase at the moment where many of the original developers have left leaving zero documentation, design documents or specs, or even sensible comments, I truly increasingly cherish readability and understandability of any small portion of code without having to get a holistic overview;
I should be able to understand what it's doing in isolation - auto as a return type or as a deduced return type doesn't help me see what something is doing from the calling site without having to wade through reams of other function calls or step into them; I think time will not be kind to it if overused.
Honestly, I have had success with reading Stroustrup's book and doing the exercises. YMMV.
 I wish people invested more time/effort in writing good textbooks instead of videos/MOOCs.
Their C++ style has a heavy emphasis on pointers. In addition, their banning of exceptions warps their code in other ways (for example a heavy use of out parameters).
Also, they have a tendency to use their own alternatives to stuff in the standard library.
If you already know modern C++ you can discern the good advice from the bad/archaic advice, but if you are learning Modern C++, you would be best served by avoiding it.
In any case, the simple fact that the reasons are unknown speaks pretty heavily for the case that the reasons aren't universally valid, so you would be learning a dialect of C++.
Google documented pros/cons and reasons for their decisions in their style guide, which is public . Whether or not Google's final decision is applicable to you, reading the pros and cons is informative. For example, their reason for not using exceptions is specific to their existing code base , but the discussion is informative.
Maybe this is still the case?