I'm not qualified to say anything here, I'm a junior as well, but something general that I picked up:

Not everything needs to be object oriented.
Writing 5 functions and calling it a day is often much better than needing 13 classes and 4 interfaces.

Depends what you're doing.

Domain modelling, there is value in classes that represent the business domain properly. It conveys meaning as much as anything.

On the other hand I wrote a pipeline that publishes node modules. I just wrote a procedural script.

"Not everything needs to be object oriented"

Expand that to "pick the best paradigm for any given situation", and you're golden. The fact that some people come into this industry thinking that everything *does* need to be OO worries me. No fault of their own, it's just that so many higher education institutions still seem to be teaching OO the same way they were in the late 90's...

The fact is that when they teach us OOP they often highlight the fact that anything should be extendible...

As a concrete example of « the right tool for the right job »:

Game dev is better with OOP.
Classical web app is better with a more FP approach.
Microservices backend is obviously better with MOP (which is what was intended initially when OOP was coined).

@craig939393 I'm not saying that OOP doesn't have its use, a lot of software I've worked with/on is made object oriented.

OOP is a powerful tool, but as @AlmondSauce said, it's a tool not fit for every job.

And as @WeAreMany mentioned, something like game development works great with object orientation, while other things may not.