Just because you have a hammer,
doesn't mean everything is a nail.
I've found that many people often confuse when to apply composition vs. inheritance when using OOP as a programming style. The example you cite from the interview question appears to be a case of this exact kind of confusion.
One thing I've learned with experience, is that while inheritance is a nice paradigm for expression "IS-A" relationships between entities in a design, it's often better to favor composition rather than inheritance.
But let's examine the crux of the interviewers question though: when is OOP a poort choice of paradigm?.
OOP works best with large-scale, multi-developer, multi-module projects. For "development in the small" - such as scripting or transformative processing, it can require a good deal of overhead without necessarily adding value. But even in these cases, unless you're writing throw-away code, I would argue that large solution often evolve from smaller ones, so establishing structure and separation of concerns early on can save you grief later.
Ultimately, OOP programming also requires a certain level of design rigor and planning, as well as an understanding of the core principles of object orientation. If you're unwilling to take the time to study and understand those principles ... well, perhaps then OOP programming is not for you.
Beyond that, certain kinds of problems also lend themselves to alternative programming styles. For example, transformative processing is quite ammendable to the functional style of programming - in which a results is computed and passed to successive transformation steps to produce a final result. Problems where you have to search or query a domain for certain matching information are ammenable to query languages (like SQL) in which you describe your intent declaratively rather than imperatively.
Being able to recognize which kind of problem you are solving goes a long way towards choosing which kind of language or tool to use. The right tools can make a job much easier ... the wrong one can make it harder - or impossible.
