Market Bytes | SOLID principles for hiring Technology talent
Updated: Mar 16
When hiring for developers, there are a number of pretty boilerplate questions the hiring manager will direct at the candidate, which are fairly straightforward to answer. However, the hiring manager might sometimes ask a non-standard question that throws off the candidate. I came across one such question during a recent interview I sat in on with a client.
The hiring manager wanted to find out just how familiar the candidate was with the SOLID principles, and how the candidate put it into practice. The candidate was not able to give a satisfactory response and it played a part in him not being put forward for the next round. In light of that, I thought I’d give a simple analogy explaining what each principle means and how candidates can provide a satisfactory answer should this question come up again in any future interviews.
S: Single Responsibility Principle: Each class should have only one purpose, and it should not try to multitask any more than it has to.
It's like saying that in a school, let the teacher be the teacher, let the janitor be the janitor and let the headmistress be the headmistress. It would be a disaster combining and dropping their duties onto just one person.
O: Open Closed Principle: When you write a class or function or library you should do it in a way that anyone else can easily build on to it, but not change it's core elements. Or in a nutshell, open for extension, closed for modification.
If you are having a barbeque and you’re bringing burger patties, always allow other people to bring extra things like potato salad, mac and cheese, disposable cutlery, alcohol etc. but never allow anyone to get rid of your burgers and replace them with hot dogs.
L: Liskov's Substitution Principle: Any time you have a sub-type of something, that subtype should always be
compatible with the original thing.
If you have a motorbike class that has "wheels” and "brakes" as properties and want to make a bicycle class, don't use "engine" as it's property. You should be able to put in a bicycle where you would normally put a motorbike and everything should work.
I: Interface Segregation Principle: Only make the user implement whichever methods they intend to use. An interface that has more functions than what the user needs is a bad one. If you only plan to use a couple of relevant functions but there are 50 other unused functions, that's 50 useless snippets that need to be added to your code. A good way of going about this is to split up the functions into relevant groups.
If you are a restaurant that only offered full seven-course meals or nothing at all, not many people would eat there. Instead you should offer an ala-carte menu, a drinks menu, a dessert menu etc.
D: Dependency Inversion Principle: Both high level and low level modules should depend on abstractions, not on each other. Also abstractions should not depend on the small details, the details should depend on the abstractions. This can be done via the use of an interface between the high and low level modules.
Suppose you are one of 50 managers working at a big company. You have a ton of employees and a ton of stuff that needs reporting. However, these employees report to the 49 other managers as well. Instead of teaching them how to write a report your way, you should give them a basic template to follow and finalize it yourself. From an employee's point of view, it’s overwhelming to memorize every manager’s preferences. As a manager, you can get lots of work done with just a simple set of instructions. The generic report is the interface.