How to get theoretical knowledge in order to be able to describe what I put into practice?

Question

IT education

And so, the problem is the following: I implement some functionality, programs and understand what I am doing and why, how it works, but I have absolutely no theoretical knowledge about what I did. Let's say, reading about design patterns, let's say, reading about design patterns, I understand - in that functional I implemented a factory method, in another template method, and in the third "state" pattern, but at the moment when I write the code - I absolutely don't think about this, in OOP I absolutely don’t think about the fact that I have encapsulation there, and inheritance there - this is implemented by itself. But, for example, at interviews, when uncles or aunts-hr ask about the structure, about architecture - I subconsciously understand that they want to hear exactly this theory, that there I used this and that, and there that.
How to be?

Answer 1

So,

which ones are worth reading

1. McConnell, "Perfect Code". A voluminous but not particularly complicated book, you can read it not very much in more time than the same book from fiction literature.
2. Robert Martin, The Ideal Programmer. There is also "Pragmatic Programmer", it seems, too, about something similar. The book is small, in principle, you can read Uncle Bob's arguments about the work of a programmer in a couple of weeks.
3 Robert Martin, Clean Code. A very good book, very broadly covers the topic of writing maintainable code. It is important - especially in this book, but also in any other - do not get hung up on dogmas a la "3 lines per function", do not deify SOLID, but consider what problems the proposed solutions solve. In each case, I advise you to think about
4. Robert Martin, Clean Architecture is a relatively new book about how everything new is well forgotten old. Perhaps things are described a little superficially, however, in any case, you need to go deep yourself. The book is good, explains SOLID better, touches on other principles, touches on paradigms, design principles, architecture, explains why what many unfortunate developers now call OOP is not. I think this book can even be moved to the first place.
Further according to the situation - patterns GoF, PoEAA, Fowler's Refactoring, Kent Beck about testing, etc.

subconsciously, I keep choosing exactly the "right" approaches,

I'm afraid that you're just using the approaches you know, and not choosing based on the requirements and the situation.
If only because there are no “correct” approaches, there are those that are suitable in a given situation, and those that are ill-suited, compromising and frankly harmful.

inheritance - this is implemented by itself.

This phrase clearly makes it clear that you have problems in the design. Inheritance is a very dangerous thing, and doing it just because it seemed convenient, without thinking about LSPs, contracts and invariants.. Ahem.. Bad.
I will mention one point: articles on the Internet and even (oh gods) on our favorite hub or toaster, like any other sources of information, books and reports of our favorite authors represent the author’s exclusively subjective opinion, and only his understanding of the topic described, formed due to usually unknown circumstances. They can carry hidden complexity, are absolutely not suitable in situations other than the author's situation, and should never be taken for the only true truth. Rather, for food for thought and alternative approaches to any business.