OOP is not important because of itself, but because of what it takes with it.
Something that deals with the capability to abstract and isolate, group things
together end expose only the parts that are required to interact together.
This is a common engineering technique called "modularization", that allows to
create complex systems as aggregation of simpler ones, without to take care of
every single details at high level, and that require components to be replaceable,
even without them to be exactly the same.
Those "engineering concepts" have been tried to be kept into the software
development from the time software product themselves had become larger than the
"single developer capability", thus requiring a way to make developers to work
on independent pieces, and let those pieces to interact together.
That said, those principles are not necessarily found only in OOP (it the
computation theory is valid, there are infinite possible methods
to come to those results).
OOP is simply a successful attempt to put those things together,
giving to those general terms (like modules, encapsulation, substitution) more
precise definitions and elaborate conceptualization on those definitions
(patterns) that can fit into programming languages.
Think to OOP first not as a "language feature" but as a "common lexicon" that
makes software engineers approach the software design.
The fact that a given language has or not primitives that directly enforce that
lexicon ensuring -for example- that a "capsule" is not opened inadvertently by who is not
supposed to do that is a secondary aspect of OOP design.
That's why even large C project are often "managed as" OOP, even if the language
itself offers no direct support to that.
The advantage of all that is not recognizable until a project size stay into
the single developer capability in understanding and track everything he does
(in fact, in those situation it may be even seen as "overhead") or into a small
group developing something in a short period.
And that's the main reason juniors who studied OOP in term of a "language feature"
often misinterpret it producing bad designed code.
How OOP fits into languages depends on how language designers interpret
the OOP principle in their own construct.
So "encapsulation" in C++ becomes "private members" (and a "capsule" become a class),
"substitution" becomes virtual functions override or template parametrization/specialization etc,
while in D a capsule is a "module" (and substitution goes through classes etc.), thus
making certain paradigm or pattern directly available in a given language and
not in another and so on.
What recruiters seek in asking OOP question is just check your capability to
abstract and concieve software design for future large projects and development.
OOP, for them is just a "dictionary" they supposed both you and them know so that
you can talk about other more general things or concretize into a specific implementation.