What’s the objective of object orientation, recruiters?

What’s the objective of object orientation, recruiters?

IT Recruiters find themselves drowning in technical terms, bogged down by buzz words that are painful to pronounce, let alone understand. They may never become engineers, but there is no reason a recruiter shouldn’t have a basic understanding of some of these expressions or concepts.

Object orientation is a great example of one of those nebulously complex domains that is easier to grasp than you may think.

Software systems can be very complex. Making changes to the commands they execute can be very messy, made even more painful when a change to one part of a system breaks another part of the system. Imagine if a car was a single integrated pile of engineering and making a change to the engine changed the way the transmission worked. Maintenance would be a nightmare.

Software design has evolved in a way that promotes re-use and object orientation is a perfect illustration of that. So, what is OO anyway?

Object Orientation is an approach that lets you define parameters – both physical characteristics and actions – very generically at a high level and re-use a set of instructions that have a more specific set of parameters in another location. Look at the diagram at the top of this post, which illustrates the concept Polymorphism. You have an object called Animal that has a generic description of how to move its extremities to get around. You have three different animals that all want to move, so each of them will re-use the method Motion, which lets a horse gallop, a bird fly and a fish swim.

Inheritance, Abstraction, Encapsulation and Polymorphism are the primary concepts of Object Orientation, which are detailed below:

Inheritance: This is the way for one object  to acquire the properties or characteristics from another object. It supports the idea of creating a hierarchy. Let’s take a common construct like a vehicle, which comes in many different varieties  but have generic attributes common to all vehicles: They have space and seats to carry riders, they have doors to let you go in and out and have features that you control speed and direction, etc. You get the idea. One type of vehicle is a pick-up truck and a very specific kind of pickup is a Toyota Tundra. If you want to end up with a Tundra, you would inherit the highly generic properties of a vehicle object and the more specific – but still somewhat generic – properties of the pick-up truck object and you have a very specific object with all the parameters of a Tundra.

Abstraction: This is an approach where you show only the relevant data of an object to a user to help them in using that object. Let’s say you want to record a TV show. There is all kind of complex engineering inside the remote and the cable box that need to execute tasks in a precise order, but you have no need to understand any of this complexity to record a show. Abstraction would have us simply present a small button with a red circle when you want to record a show, effectively hiding all the painful details except for the little button with the red circle.

Encapsulation: This is often referred to as “data hiding”, because you are hiding complex details of an object to keep the the user from getting confused about details they don’t need to know. There is sometimes confusion between Encapsulation and Abstraction, because both talk about “hiding data”, but here is the difference: Encapsulation is about hiding internal complexity and Abstraction is about expressing external simplicity. An example of Encapsulation would be connecting to the Internet. You don’t need to understand how TCP/IP lets one machine connect to another and how HTTP sends you a web page. You just need to click the network icon in the lower right corner of your desktop.

Polymorphism: This is the subject of the illustration at the top of this post. This lets you re-use generic functionality with different results depending on the functionality of a specific object. In the graphic, you start with an object called Animal and it has a set of instructions to describe movement in a method called Motion. If you want to create different animals and don’t want to define unique ways for how each specific animal moves, you would use Polymorphism to borrow the generic Motion method to implement a horse galloping, a bird flying and a fish swimming.

Including questions about these concepts would provide numerous benefits. For openers, they are great topics to qualify a candidate because it is a subject that is language and OS-agnostic. You can get a better idea as to how they will handle and present technical explanations in general. You will begin developing your own understanding of the topics as you ask 5, 6 … 10+ candidates give their version of the answers. You will begin to develop rapport and credibility because they are not expecting this line of inquiry.

So few recruiters ask detailed technical questions of developers, the possibility of getting referrals goes up  considerably if you can incorporate questions like these into your interviews. You will seem overwhelmed if you decide to ask one of these questions, but it will be interesting to hear how different candidates give their version of an answer to the same topics. Don’t be intimidated by the subject or the candidates; they are just people.

Most of them will appreciate the fact that you are putting in the effort and showing some intellectual curiosity and leaving your comfort zone. You are working on your professional brand in every conversation you have, so you should care about the content you generate in conversation. Incorporating Object Oriented topics will definitely make you stand apart from the recruiters with whom they are accustomed to dealing.

Isn’t that a good enough of a reason to give it a try?


TechScreen Team
No Comments

Post a Comment