The most important skill to look for when hiring software developers is the ability to do abstractions. The ability to abstract goes hand in hand with real world software engineering problem solving.

Just to make sure that we are on the same page I want to elaborate about abstractions, as I have unfortunately discovered recently not everyone knows or has a basic understanding of the term “abstraction”. The most decent explanation that i could think of comes from a great book The Math Gene by Keith Devlin that I read a couple years ago. I will not be quoting word for word but instead I will try to explain in my own words.

Abstract thinking is the ability to operate with objects in your mind, objects that have absolutely no connection with the real world.

This sentence became my rule of thumb definition of abstract thinking for software developers and I try to build my interview questions and problems that I will challenge an interviewee with, based on this formulation.

I understand this definition of abstraction might not be what you have on your mind at the moment, and it doesn’t mean that you are wrong. Just for the sake of clarity let me elaborate a little bit, expand this definition. There are 4 levels of abstraction, each level requires a cognitive ability to operate with an object in your mind, the one we are interested in is the 4th, let’s take a look:

First level: ability to play in your mind with an object that is in your imminent environment, a physical, real world object. For example, lets take a pen on the corner of your table and using you imagination you can move this pen to a different corner of your table.

Second level: Playing with objects that are not in your imminent environment, but you have seen and touched those before. For example: I don’t have a pen on my table but i definitely know what pen is and used it many times before and i can imagine it being on my table.

Third level: You have never seen a physical object or used it, but you learned about it! Somebody told you about it or you read a fairy-tail book and you can imagine a magical object and operate with it in your mind.

Fourth level: ability to operate with objects in your mind, objects that have absolutely no connection with the real world. This is the level where mathematical, analytical thinking lives with formulas and algorithms, our logic and patterns we found.

The good news is that every single one of you, my amazing and creative human beings, is capable of all 4 levels of abstraction. The only difference for software developers with lever 4 is that it is a highly trained skill. Everyone definitely has a talent for it, but in Software Development we are only looking for those who had it practiced and developed. Like your muscles in the gym but in your brain.

If our candidate doesn’t have necessary developed skills of the 4th level of abstraction it should be a very clear and definitive sign that unfortunately you should pass on this one.

I think we all have participated in interviews with questions and problems about data structures and generic algorithms, but not all of us have thought about the reasoning behind it. We just accept it as it is. Some of the employers are still irrationally obsessed with candidates CS degrees, that piece of paper that does not guarantee any knowledge or cognition at all, and algorithmic questions provide a solid CS degree confirmation. For me the reasoning behind algorithmic challenges was the easiest and most straightforward way to test how well a candidate handles 4th level of abstraction. Many companies still stick to this cheap, old, and dry practice, but what is the down side and why it should be deprecated?

We all know that data structures and algorithms is a subject in college and people who don’t have a CS science degree most likely will not be familiar with this concrete set of knowledge and most likely will fail the interview even though their true cognitive capacity is much greater than most of the candidates with CS degree are carrying, here were are making a costly mistake by passing on the true talent. Everyone wants to hire the best. And everyone wants to work side by side with talented developers, but unfortunately current, largely standardized interviewing practice that solely focuses on CS degree produces a lot of false negatives. As interviewers and hiring managers we need to realize that we are similar to that guy with a metal detector on the beach looking for gold! And if we will not open our minds and rethink our hiring practices, we will never find that gold we are looking for.

We need to focus and redo our coding challenges in a way so we can create a very accurate evaluation of the candidates ability to abstract. Challenge our candidate’s imagination and critical thinking. Ideally all our interview problems should be built in a way that even a non-technical person with highly developed abstract thinking could answer. This is especially useful when you are hiring junior developers. You are not looking for hard practical skills, instead you are looking for the potential.

When the right candidate comes along, you will see that his previous experience is practically irrelevant. And your current technology stack is also irrelevant, the right candidate with great cognitive capacity will be able to adapt fast, pick up new things and bring new ways and ideas, breaking your team’s or company’s tunnel vision. Their fluid thinking and almost extreme ability to identify and extract patterns will exceed anything you have expected.

Since I have brushed on it a little, I want to say that I can’t stress enough that hiring based on your current technology stack or domain is extremely wrong. Never do it. Never. If the only reason you are bringing on board new developer because he has a lot of experience in your domain or with the CMS, programming language or framework that you are using, then you are making a kind of mistake it is very hard to recover from.

It troubles me deeply when we miss the right person or talent and continuing our indefinite, unfocused search. I can only imagine the ideas and solutions those candidates would have brought to us and our companies if we were more focused on true grains of gold and what software development is actually about.

But also lets keep in mind that this article is not for everyone and each organization is different, if you are only looking for oompa loompas for your feature factory, then you are on the opposite side of the spectrum where these rules and conditions do not apply.