Ranting about the quality of developers

I am in the happy position that I work for a company who is steadily growing. As a consequence we were and are hiring new developers. I had and have the “pleasure” to be part of this hiring process. I put the word “pleasure” in double quotes since often times it was more a sad than a pleasant experience.

First of all I have to admit that we failed completely when searching candidates ourselves by announcing open positions in blog post, on our company’s web site or when placing ads in various well known lists. Not only did we get low quality applications, no, we got near to zero response. Thus we hired some head hunters; not only one, but four of them. Finally we got some CVs from potential candidates. With the candidates that had interesting enough resumeés we arranged phone interviews. During these phone calls we give the candidates the opportunity to tell us where they think they are best at and what they are looking for. Although we do not ask very specific and certainly not very difficult questions, a lot of candidates have big troubles in coming up with some “meaningful” or “relevant” answers. Most of the candidates just fail on this first hurdle. Some interesting sample questions and answers:

• We might ask the candidate something like: “Please tell us what principles or practices you use in your daily work to create robust, maintainable and/or extendable code.” One candidate, after asking us to repeat the question, said: “I am sorry, I cannot answer this question, but can you give me an answer?” Our answer then was rather clear: “I am sorry, but we are looking for candidates who know an answer to this question…”
• To another candidate we said: “On a scale of 1 to 10, where would position yourself regarding your skills in C#?”. The candidate answered without hesitating: “I think I would give myself a 9.5.” Ha, you can imagine how we felt goaded and our next question was “Please tell us about some of the more advanced things you did with C# and .NET.”. The answer this time was rather disappointing and the things mentioned by the candidate where nowhere near bleeding edge.
• Yet another developer, when asked what he did and where he is good at, did not talk about development or things a developer does and is proud of, but he rather started to talk about processes along and around development in general. It remained a “blah-blah” even when we insisted on hearing more “technical details”.

If what a candidate tells us at the phone sounds interesting we arrange a face-to-face meeting. Sometimes we give the candidates some “home work” to do, to be prepared for the interview. Most often the topic of this home work are the S.O.L.I.D. principles. We just tell the candidates that this topic will be one of our discussion points during the interview.

During the face-to-face interview we do an exercise with the candidate. It is basically coding in Notepad. We are typing since the candidate might get too nervous if he had to type. (We all know that it is difficult to type when somebody watches you over your shoulders, do we?). The goal of this exercise is not that the candidate finds “the” correct answer (there might not be such a thing…) but we want to find out, how a candidate approaches a problem, how he is thinking and how he is refining his approach to a possible solution. The outcome of this exercise completely depends on the candidate and how he approaches things. While trying to find a solution we might discuss such topics as: programming against abstractions (using interfaces or dependency inversion principle), encapsulation, tell don’t ask principle, single responsibility principle, interface segregation principle, the usage of strategy patterns, etc. We do not expect that the candidate knows all this principles and patterns by name nor that he knows when and how to apply them but some of them might just naturally exhibit themselves during the exercise.

This exercise really separates candidates of good quality from those of mediocre or low quality. We had some candidates that did an excellent job although it was the first time they ever heard of all those principles and/or patterns and certainly have never applied them consciously before. Others that knew all patterns and principles by heart and could rephrase their definitions failed miserably when asked where those principles and patterns could be applied in the sample at hand.

Sadly developers of low quality are far more common than the ones of decent or high quality.

Even more sad is the fact that developers having a (very) limited skill set are most often not aware of this fact and consider themselves to be “seniors”.

Am I expecting too much? I don’t think so. Developers have I high responsibility. They produce software to automate business or mission critical processes. One should expect this software to be of high quality. To write high quality software we need good developers!