From year to year I keep hearing arguments about the right strategy to assess and select new hires. Needless to say the opinions are widely and wildly varying but seemingly never finding a consensus. Ideas I've heard so far:
- Administering an extensive technical test because nothing except hard skills matters
- Giving brain-teasing puzzles, riddles and gotchas to select only the smartest
- Digging into algorithms and data structures to see if the candidate still remembers the details of the CS courses he took 15 years ago because it is impossible to code anything without deep scientific background
- Basing hire decision on extensive personality and intelligence tests and the feedback of the inhouse psychologist
- Relying fully on references and letters of recommendations and trusting nothing else
- Giving the candidate a test task to execute and submit for consideration
- Requiring a solid university degree preferably with the high grades
- Choosing only from those who contribute to OpenSource
- Considering only those who possess "at least X years experience with the technology Y"
- The infamous "smart and gets things done" approach
- Looking for good communication and writing skills like the developers who write blogs
- Choosing the candidates with the best presentation skills and how nice they look in a suit with a tie
- Other rather preposterous and superstitious approaches based on zodiac sign, first name, gender, nationality, not being poisoned by Windows and other Microsoft technologies, using "correct" secret wording in the application etc.
Some days I laugh reading those stories, the other days I almost weep. I inevitably come to a sad conclusion that while some people got it right the majority just don't have a clue. This makes me wonder how it is possible. The software industry has long matured, has tried every approach and should have by now a pretty clear picture of what works and what doesn't. It would seem we have another case of write-only communication on our hands. That is, the knowledge which is painfully obtained and generously shared by a minority is ignored or simply discarded by the majority believing they know better. Sigh. Their loss.
Many people will confirm that these criteria just don't work with any predictable pattern. No matter what test from the options listed above you use, there is rarely a stable result and repeatable experience. Whether the candidate will become a good and successful complement to the team would seem to be a random function. Don't get me wrong, when you do the hiring you should screen people, to find the ones you can work with. But you need to do it wisely. Otherwise it's a wasted effort and a lost opportunity. For all you know you can just flip a coin and save yourself some interviewing effort. Better however to reflect on the things and then come up with something that will work.
Let me present to you that something. I call it the technocultural fit.
The simple idea of it is that you look for people who exhibit certain character traits close to some ideal point in a multidimensional space. That point represents the ideal personality and mentality for a software engineer for him to excel at what he does and reach his potential. You and your team should strive to arrive at that point too. A team which can be described as a group of points occupying a particular narrow region in that multidimensional space would perform at its best and show the maximum efficiency. The farther away from that region you team is or the more dispersed through the space your team members are, the more disrupted, conflicted and the less potent, coherent, united and harmonic team you have.
The technocultural fit should not be confused with the classical "cultural fit" which has become an almost useless expression as everybody gives it a different meaning. Often it would simply mean the current team members or the boss personally like the new guy and that's it. However more commonly the cultural fit would indicate a person matching closely the mindset of the current team or alternatively sharing a set of "corporate values". This quietly leaves out the question of whether that baseline mentality is an optimal one for a software team or a software company. As you can guess more often than not this particular established culture is far away from a dream environment that a talented engineer would seek out.
The technocultural fit does not imply in any way the team should be assembled from the people of the same nationality or from a group of preferred nationalities with the common set of values and cultural heritage. Nothing of the kind. There is no guarantee that two random Americans or two random Canadians would see eye to eye. And it's just as equally possible that a Chinese and a Brazilian would form a team made in heaven. There is simply no telling. Every person is unique and the criteria of the technocultural fit cannot be expected to closely match the natural culture of the said individual. In fact, multicultural teams have huge benefits and beat monocultural teams hands down. The linguistic agility is not a showstopper either, people of different cultures could communicate in half-broken English and still be very productive and extremely efficient.
And let us now proceed to those criteria idem dimensions. They are simple and intuitively known to every good software developer. I'll word them to indicate the desired value on their respective scale.
Enthusiast. An essential quality which ensures the person is eager to learn, grow, develop personally and not lag behind the times. This also brings curiosity to the play which is essential to learning, discovering new things and ideas and finding out why and how things tick under the hood. And it is the foundation of progress.
Open-minded. Assures the person listens to external input and stays recipient to new ideas and feedback. The person accepts the possibility of a mistake, of being in error and therefore stays open for correction. It keeps the quality of arrogance and excessive self-confidence under control. It is also the foundation of respect, respect towards colleagues with different opinions, respect for people of a different background and respect for the users with their different ways of doing things which is often the reason why they experience difficulties with the software we create for them.
Creative. Practical software development is all about creating solutions for the problems. There is never a silver bullet or a manual for solving any problem we encounter. Often the problem itself is not clearly defined. Which is why it calls for an imaginative and a creative mind to see the things for what they really are and not for what they appear to be. Often in order to come up with a solution we need to move to a different level of abstraction or perhaps introduce a small artificial problem to successfully deal with a larger problem at hand. And there is rarely an algorithm for doing so, what works is to be creative and inventive.
Generalist. A necessary quality to be able to abstract away from a local problem and see a bigger picture. Diversified knowledge and experience helps us to see the ramifications of our actions on a larger scale. That could give us a solution which doesn't exist on the given abstraction level. Sometimes the solution lies with changing our ways, adjusting the processes, or shifting the problem to a different component of the puzzle. Being able to see that requires a generalist mind and the wide point of view.
Pragmatist. A pragmatic person knows every solution is a compromise. He knows to separate the important and immediate from the preferred and secondary. A pragmatist is result-oriented and knows to watch the clock in order not to sink in the ocean of theoretic purity or be gone on the never ending quest for perfection.
Entrepreneurial. Gives a person the courage to make a leap, a resolve to make a decision and act on it. Software development is a very practical discipline. Even if it is helped much by science and research, it knows that very often it just needs to take a step and see what happens. This is an entrepreneurial quality. The lack of it, the fear of change, conservatism and sticking to old habits and authoritative opinions is not a basis for big advances and great discoveries. In fact, much of CS has been inspired and brought to existence by practical experience, we need to remember that.
Humble. Humility is a wonderful quality. It keeps the person's ego in grip, does not allow arrogance and self-confidence to grow high to cloud the sun and block the daylight. A humble person respects different people, takes seriously other opinions. He doesn't show a disrespectful demeanor towards colleagues or towards users of his software. He won't consider it unworthy to speak to the people lower in the hierarchy or help colleagues when they are in need. He won't keep the important information to himself, to assure his advantageous position. A humble person will aim at a larger good, instead of taking credit he will share it. He will refrain from assigning blame but focus on solving the problem. A humble attitude will prevent the atmosphere of competition from establishing itself in a collective. Instead of promoting the disruptive culture of conflict and winning at the cost of others, you will enjoy the atmosphere of cooperation and mutual assistance. How much more efficient and productive that can be, you will see for yourself.
Emotionally-mature. Programming software is hard. You have to deal with a computer, a precise machine which does not tolerate mistakes. Often it is a slow and a painful process to understand how things tick to get your code up and running. Sometimes you encounter dozens of obstacles where you didn't expect a single stone on your road. It takes a certain level of control over your emotions not to get depressed and demotivated over the lack of immediate progress. You need to be able to suppress your emotions, to be persistent and to continue cracking until you get it right. A set of useful tips for working on programming projects can help you here. Very much the same uncertainty awaits you when you get your software out. Perhaps it will have success, perhaps not at first. You need to be able to take a cold shower of the user feedback, not get mad at them for not valuing your creation, but instead adjust your software to the needs of the users and the demands of the market. Quite possibly you will redesign your software completely in the process. You need to be able to react positively to feedback and constructive critics. It is also a valuable quality for working in a team where smarter and wiser colleagues can teach you a lot. It would be unwise to refuse valuable knowledge delivered right into your hands. Emotional maturity comes after one has curbed his young and categorical mind and has learned not to pass on immediate judgment based on one's narrow vision. The understanding that you might be in delusion even when the hard facts seem to support your position is invaluable in preventing you from doing critical mistakes.
Lack of these personal traits can and most likely will result in the development of bad qualities in a programmer. Sometimes it is possible to keep certain developments under control, but we're talking about a personality change and it is usually a hard thing to do, especially after the young age.
Achievement of the technocultural fit is crucial for building a modern and a potent team. Lack of such will result in a group clocking at a much lower speed than it potentially could. People will quit because of a lack of the technocultural fit. In fact, it is the reason number one for quitting, being seconded by the lack of personal and career growth. I've seen people leave within days, weeks or at most months because they realized they ticked differently from the rest of the team. I've done it myself. I rejected offers in instances I could see the technocultural misfit even before the start. And as such I suggest making it a priority activity for hiring, to identify the technocultural fit because it is the basis for everything in a software team.
It must also be understood that the atmosphere in the company should equally match these criteria and allow people to unveil these personal qualities. They should be encouraged to exercise their vital powers, not be punished for doing so. If that's not the case, then fixing and upgrading the company processes is in order, before we even begin to seriously talk about the technocultural fit, because we can't build a house on a broken foundation.