$\begingroup$

No, not by a long shot, although Harvard's CS50x is an excellent introduction which provides around 10 hours of lectures then problem sets which support approximately 100 hours of practice at programming by solving Computer Science problems (not quite the same as software engineering problems).

Most typical entry-level software engineers (regardless of their background) will likely have spent several thousand hours learning their craft by the time they start their first job (Something roughly equivalent to the amount of time a typical graduate may have had after 3 years at university).

This obviously includes programming and core computer science concepts, but most importantly it involves having hands-on exposure to building some working software (Which is about far more than just writing code -- actually, writing code is only a small part of the total amount of work which goes into building working software).

While it's certainly true that Software Engineering is rooted in Computer Science, and computational thinking skills are an essential prerequisite, that capability is nowhere near enough on its own.

Generally speaking, most software engineering problems also have a degree of subjectivity built on top of that - i.e. they go beyond just needing to find solutions based on logic; most of the problems faced by software engineers are more about humanity - meaning that the vast majority of issues involved in building software can't be solved just by writing an algorithm.

Just to provide a few examples - this list is neither complete nor comprehensive, but hopefully illustrates the kinds of things that are learned through hands-on experience of working on software projects (even spare-time hobby projects and open-source software):

Requirements gathering and analysis

Software design principles and approaches to software design (e.g. consideration towards interfaces, modularity, and automated testing)

Pragmatism and consideration towards real-world constraints (e.g. people's time, or their willingness to accept change, etc.)

Communication, knowledge-sharing and collaboration with other developers (e.g. peer reviews, pairing)

UI/UX Design

Communication with users and stakeholders, including managing their expectations and seeking their feedback.

Teamwork and being able to function within processes and procedures that allow many people to contribute to the same project/codebase.

On top of that, there's also the fact that software engineering often tends not to be about using code to solve every problem but to include a lot of effort reusing other people's existing/working/tested solutions to avoid re-inventing the wheel (For example, "devops" tools, app frameworks, cloud services, 3rd-party libraries, O/S capabilities etc.)

This often includes trying out tools/libraries/frameworks to check their capabilities, then figuring out how to integrate your code with those things (e.g. through programmatic APIs, configuration management, build/integration/deployment processes, automation/scripting, etc.)

This is not to say you need to be any kind of expert in these things for an entry-level Software Engineering position, however once you're confident in the core skills of computer science, programming and computational thinking, it'll be important to focus learning around building software - at which point a lot of issues around tools/APIs/libraries/frameworks start to crop up, and so should the issues around understanding software design, testing, pragmatism, and (ideally) a lot of interaction with other programmers.