I’ll just say it plainly: Just because someone happens to know a particular MVC or OOP framework doesn’t mean they actually understand OOP. No matter what framework you use, OOP is all about design, all about understanding the relationships and interactions between objects. Go ahead and make all the objects you want. But unless you have a clear idea of how they relate and interact, then you run the risk of doing A LOT of extra coding down the line to compensate for your lack of design. Mind you, I’m not just throwing this out as a matter of opinion, I’m coming from a position of experience.
Let’s Build an Animal Kingdom
Given the following animals:
Dog, Cat, Eagle, Duck, Python, Anaconda, Iguana, Salmon, Lungfish, Frog
Build an object hierarchy that can describe this set of animals. After you’re done we’ll discuss. There isn’t necessarily a right or wrong answer to this. But we’re going to take this time to discuss your object-oriented awareness and acuity.
Here’s a possible solution to this hierarchy:
Once they’ve finished the diagram, you get into the application of the design. Note that this is not to be confused with implementation, but rather, providing a context to the design to see if there are any holes in it. But first, some questions:
- What was your reasoning behind building the hierarchy in this way?
- Would there be another way to approach this? (Another possibility would be to break it down by number of legs, but that is actually not optimal based upon the follow-up exercise of creating a world for the animals)
So the context we’ll use is this: Building a world to place the animals. So on the board, draw out an area that has a body of water, some trees, maybe a cloud to represent air, and some rocks. After you’ve drawn it out, then say that we’ll instantiate these animal objects in various places on the board. The idea is to reveal if the design will support the constraints of the environment. If they broke down the hierarchy according to number of legs, they may have missed the functional level. This is something that can be suggested and will almost immediately be revealed once you start going through instantiation.
If they did break it down by function, then chances are they will have missed the multiple inheritance. For instance, an anaconda can be created either in water or on land; same with the dog. You can lead them through this with some questions:
- Is it possible that an animal can be instantiated in different locations? (You’ll especially look to see that the duck can be instantiated as a swimmer, walker, or a flyer). That last bit was a little evil on my part. 🙂
- Given that animals can be created in a couple of possible locations, and that there constraints as to where they can be created, where would you place the method that would check for the location? The correct answer would be at the second level, so that those animals that inherit from two parents will inherit the location constraint from both.
So in this exercise, what are we trying to accomplish?
- The obvious answer is to see if they get object-oriented design at all.
- The second thing this reveals is how well the candidate can communicate and justify their ideas.
- And just as importantly as the other two, this exercise reveals if this person has the ability to work with the team.
Note that this exercise is best done with a couple of people in the room – probably no more than three – especially to address item 3 above.
Based on my experience on the receiving end, doing this exercise was literally a breath of fresh air. Personally, I wouldn’t pull this on a junior developer, but this is something that I’d definitely use for senior front-end AND back-end developers. Remember, it’s not about the code with this exercise, it’s about the design thinking. Do a separate coding interview following this.
I’ve been using this for over ten years now and it is still one of the best ways to weed out code monkeys. If a candidate can’t get through this exercise, then it’s a fairly clear indication that their code is likely going to be a mess. It just proves out that just because you code in an object-oriented language doesn’t mean you know OOAD/OOP.
This has been especially effective in evaluating front-end developers; especially those developers who claim to be senior but their experience has been strictly limited to frameworks such as React or Angular. It doesn’t necessarily mean that I will reject them entirely, but it will affect where they’ll be placed in the engineering organization.