Any tips on nailing OOP design interview questions? This is a black hole, weak area for me, and I get absolutely no feedback on what I'm doing wrong.

I feel like most of it is because I *nothing* about what I'm asked to design.

And yes, I ask clarifying questions, list out use cases and constraints, identify nouns/verbs and map them to objects/methods - but these don't help with the overall *design* when you can't even grasp what the components are, nor which parts need extensibility.

Imagine you've *never* been inside a car, let alone even understand there's components to a car (you don't even know that cars have engines, or that they take fuel). Now imagine you're asked to design a car. It's just, silly.

Is designing a house an alternative choice you could ask for?

@asgs that is brilliant. Can I just ask for another design question?

@irene OOP is simple then. You just have objects, they have properties and methods. You make the interface as simple as possible to demonstrate encapsulation. You polymorph into abstract cat in order to inherit the job offer.

I would rate my interviewing skills:
* Algorithms: 8/10
* Behavioral: 9/10
* OOP design: 1/10

If I have a technical screen or on-site with a design round, I get rejected, 100%. No exceptions so far.

On the flip side, if they forget about the OOP design portion, and just have algo and behavioral rounds, they end up with an overinflated view of me, and I move on to the next round or get an offer.

Wasn't that the shit with getters and setters for like everything? Mostly OOP should be spelled OhOhPee imho

@toriyuno Favor composition, or more correctly delegation, over inheritance. OOP is not only about properties and methods, it's about responsibilities. What object is responsible for what? Keep things cohesive when deciding where to put responsibilities, design with the 'one rule, one place' principle in mind. Unfortunately, most oop, ooa ood courses teach analysis and design from an implementation perspective, teaching you about inheritance. However, more advanced courses teach you to avoid inheritance and favor composition or delegation because that provides for much more flexibility. For example, suppose you have a cat and a dog. They both make sound. One could define a (abstract) base class animal that you could derive cat and dog from, in each of them implementing the makeSound() method. You can also take that out into a SoundBehavior. Then, you could make a cat bark like a dog! Just assign the bark behavior to the cat and delegate its makeSound method to use that behavior etc.

@CodeMasterAlex I can design just fine if given all the methods, properties, etc.

These interviews are flawed, since the interviewer is completely oblivious to their assumptions on what is common knowledge.

Did you even read/think about my car example?

@toriyuno I know what you mean 😊 had it too in the past when I applied for a job in the workspace virtualization sector... Guy interviewing me was so full of buzzwords (also ones from their own suite products) it really confused the shit out of me... Like wtf planet is this guy from???

In the end landed the job, was a bad one in the end, as most the stuff we did there was buzzword lingo bingo

@toriyuno of course! Just sharing my thoughts.

@toriyuno you could give a try. It depends if the interviewer is willing to give you a chance or trap you into doing something which you explicitly mentioned as not knowing

Actually, OOP is overhyped crap anyways that only does well in simulations and GUI programming. Oh and for some elementary data types where data and behaviour are closely coupled, like lists and stacks.

That's because it has nothing to do with what Alan Kay originally had in mind, with actors passing messages around between each other.

@irene functional ftw

@irene TeX was procedural (Pascal) and still blows all office programs out of the water when it comes to layout - not to mention the ugly shit we got in browsers. Chrome/desktop can't even do auto hyphentation because they havn't figured out the dictionary issue, something that TeX already solved 40 fucking years ago.

So yeah, I guess the dream is that some new cool shiny method will finally make dev competence obsolete. OOP, then UML based code generators, and now functional is in for the hype.

That is, when they can be bothered to do real world problems, and then even trivial achievements are spectacular, like the Super Mario port in Haskell.

There is not a mood--

Explains a lot bout cats