The essential skills of a developer, and why don't we check them during an interview
A few months ago, I described a fracture which exists between the skills considered desirable during an interview and the skills which are actually valuable for an employee. I haven't explained, however, the reasons for this fracture. This is the goal of the current article.
For those of you who don't have time reading the linked article, the idea, essentially, was that communication skills, teamwork, ability to learn, and a few other characteristics of a candidate are not as valuable as the politics, the ability to focus a bit in a concentration-hostile environment, or the ability to give an impression that you do your job.
Two things need to be questioned there. First, if playing politics is more important than being able to work with a new fancy framework, why would anyone spend a hour testing the knowledge of the fancy framework and not how well are person's skills in politics? Second, if it is mostly worthless for a company to encourage workers to make it look like they are doing something useful, why is the skill so valuable?
The second question is the easiest: the lack of proper measurement of employers' productivity. Most managers assume that they somehow magically would determine who is working well, and who is not, and that based on their subjective observation, they will somehow make perfectly objective decision to fire someone, and promote someone else. Nearly all managers are completely clueless about the fact that the productivity can be measured, and most don't even care. When it comes to the developers, they optimize for what could help them to get a promotion. Therefore, if their productivity is measured, they will either optimize for higher productivity or game the system. If nothing is measured, they will optimize to appear better than they are in the management's eyes.
So why wouldn't we stop being fools and start testing for what really matters?
OK, John. Next question. Imagine you're at the meeting room. Your coworker, who tries to get the position of a team leader that you deserve is presenting a design proposal (it seems that he did a great job) for a new feature, based on a MQS. You remember a discussion with Nancy where she was telling that using MQS in the context of this project would be completely crazy, but her argument was rather shallow, and she knows that. You notice that she's fidgeting in the corner of the meeting room: she wants to say that the proposal of your colleague is unacceptable, but she is afraid that everyone would be against her. What do you do, given that your manager is in the room? What do you do if he isn't?
You can't imagine how much I would like to ask this question during an interview. You can imagine how helpful an answer to that question would be in order to evaluate a candidate, as well as his sincerity! And naturally, you can imagine why I wouldn't ask this question during an interview, and if I asked, why most candidates won't answer.
Self-deception is quite frequent when it comes to choosing something. It requires knowledge and self-awareness to understand some of the reasons of the choice, and admitting some other reasons is not that simple. Take, for instance, a choice of a new piece of clothes. What would be the reasons you would publicly acknowledge? The piece of clothes is nice? It suits you? Its color fits nicely with your other clothes? And now, what are the actual reasons that you won't admit sometimes even to yourself? That the piece of clothes is expensive, which should be able to make you look more attractive to the opposite sex? Or that it makes you look thinner? Or that you haven't bought clothes for a while, and your coworker did recently, and everybody looks at her, and you want everybody to look at you instead?
It is natural to reject the fact that the employees who are better at politics or who can cope with the horrors of the workplace are the ones who'll win. Otherwise, you'll be faced with two facts: that you have no clue about the actual value of the persons you manage, and that you have no power or skills to provide them a decent work environment. It is much easier, then, to use self-deception by pretending that teamwork, communication and overall excellence are the things that really matter. Similarly, if you start thinking about the real reasons you bought a piece of clothes, you would have to admit that you gained weight, or that other people want to be with you for your money, and not because of your numerous personal qualities.
Misinformation from a candidate is another factor which makes it difficult to test the skills that matter. In fact, if the candidate knows that you are looking for persons who can cope with noise, bad smells, terrible lighting and low-grade hardware, he can optimize his answers to make it look like he's better than he is. If I take the same example of a piece of clothes, you possibly want it to be durable, you want to iron it easily, and you want it to keep its original color no matter how many times you wash it. Now, if you ask the salesman how durable the piece of clothes is, there are chances that he will ensure you that you'll be amazed by the quality of the clothes he sells. His answer is based on the fact that he assumes that a specific answer would increase the chances of selling you the clothes, the same way a candidate during a hiring interview would give whatever answer if he believes that it increase his chances of being hired.
In order to prevent misinformation, hiring staff resort to questions for which the candidate cannot guess the good answer. Technical questions, for instance, are exactly that. If you don't know the difference between the stack and the heap or the number of generations in .NET Garbage Collector, you don't know what answer would make me want to hire you. This is one of the reasons, by the way, for the emphasis of the interviews on technical skills, and more precisely the aspects of technical skills which could be presented in a form of questions which have a single right answer. When it comes to the skills of a candidate to explain things or to learn things, techniques are presently much less straightforward. The ability to explain a subject can be tested through an exercise where the candidate actually explains you a subject that he knows, and you pretend you don't: the difficulty is that you have to take in account the stress, the unrealistic context, the time constraints, and a few other parameters. The ability to learn things can be deduced from the past experience of the person (especially the sudden shifts from one technical stack to another), but here again, the task is not simple, and you have to take in account all sorts of elements, such as the interest of the person for a given technology/language/framework, the available time in a context of personal constraints (a newborn could cost you a programming language you won't learn!), etc. Finally, things like the ability to work in horrible workplace cannot be tested in a scope of an interview, and you cannot exactly ask your candidate for objective information (you can always try to call his previous employer and ask how horrible the working environment is there, but be prepared to receive an answer you may find... impolite).