Hi.
It is first time I write on topic of management and recruitment. Question is about one way of classifying your programmers, who work with you now or will come in a future. My main thesis is: all developers, roughly speaking, are divided into 4 large types and each of these types has its own application area.
Attempting to send the wrong type to solve inappropriate tasks leads to a failure ( inefficient work, or the employee leaves the team ). If you want to know why, you are welcome. Get ready, we have a lot of information. Basicallly what I say is my perception of world of programmers.
It is important to understand that there are no "bad" types. If any of the types you think is bad, then you just do not know how to use it. Remember: for each task should be a suitable tool. I will talk about all 4 types in the form of cards, giving a brief description, indicating the background, goals and motivations, as well as talking about strong qualities and weaknesses.
Especially it is necessary to pay attention to the background, as specific type of people grows out of their background. We begin with something what is easier.

Linear programmer

The main ingredient of IT industry. On such people, as it is said, the world holds. He's a ``hamster``. He is also a “rower on the gallery”, but I prefer to avoid such shortcuts, so simply “linear programmer”. He cannot do something outstanding, does not write his compilers and DBMS. Well, the maximum – he will make a couple of tools to make life easier for himself, otherwise - just solves working tasks. He rarely changes jobs, persistent. His attitude to his work is realistic and without much enthusiasm. He is moderately lazy, disciplined (but there are exceptions), however, without proper management quickly becoming "too relaxed" and loses focus. You can manage such people by standard methods - described for example in the book of J. Rainwater - ``How to graze cats``. Qualifications can vary and are determined solely by experience and the number of projects in which the linear programmer has participated. Sometimes qualified linear programmers take a low rank managerial position - they are named `` team lead`` and this is a situation, where the above mentioned book becomes for them useful. But the most important feature of a linear programmer is a very frequent lack of desire to develop and to experiment. He will perfectly solve even a very tedious task that you will offer him, if it is not too complicated. He will choose the quickest and most straightforward tool he knows. Personal development for these people is sporadic in nature and basically goes not forward but `` to the sides``: to explore a new framework or a new tool that will help to solve everyday work tasks better. Or "the customer came, who uses such a thing - well, never mind, we will sort it out." It is noteworthy, that the knowledge, obtained as a result of the sporadic development of individual linear programmers is precisely the experience of an outsourcing company. But, a linear programmer mostly often does not have an intention ``to move mountains`` and deeply explore the world. For example, he is simply not interested in learning a new, HYIP programming language. He will learn only if the new language helps in solving everyday tasks. If to take more serious step - to develop your own language – no way. And this is normal. The most bad thing is when linear programmers becoming ``frozen`` in their development when they stay in one place for a long period of time. For example, if you have a person who has been consistently engaged in conceptually the same projects for 3-5 years, then it is very unlikely that he will change the type and will develop professionally. But taking into consideration the background before this empirical term, everything is possible.
Background: different. People can become "linear programmers" when they have completed online courses, university graduates, some participants of competitions, former technical scientists, and even people from conceptually different professions ( there are cases when truck drivers became PHP developers ). It is important to understand that a linear programmer is a background by itself and step for a jump to another type. But! Whether a person jumps or not, depends primarily on his personal desires, and not on his skills. The presence of one or another background determines only the direction of a potential jump, but not its probability! But the probability of a jump over time decreases rapidly. However, if you need a faithful employee for a long-term contract - learn to identify those, who want to "jump" in advance. If he will run away from the project - it will be unpleasant.
Attitudes: stability, average but 2-times-a-month-stable wages, peace and personal relationships in a team, fixed normal working hours, office bonuses such as a billiard room, fruits on weekends, travel expenses or the gym, medical insurance and (perhaps tedious, but) not hard work.
Strong qualities: perseverance, responsibility, interpersonal skills (fifty-fifty), complete controllability, calm behavior in stressful for a project situations.
Weak qualities: complex and / or non-standard tasks, abstractions, behavior in stressful for the company situations, again- bad quality code.
Interview: important to pay attention to such qualities: perseverance, discipline, communication skills, aspirations, that's all. It also makes sense to talk about previous experience and to look at CV. Give him a standard test task such as: "write chat on web sockets" and look at the deadlines, accuracy of the task and the adequacy of selected tools. It is good to give technical questions on the knowledge of languages, protocols, patterns and standard libraries. If the applicant already has experience specifically with your set of frameworks, it’s a plus, but if not, it doesn't matter. If everything else is in order – he will manage. It’s his job.
What you shouldn’t ask: don’t ask why hatches are round (don’t ask it anybody at all), don’t ask him to slew round a red and black tree on a board, using a marker, estimate the complexity of the algorithm, perform topological sorting or design a high-load system. A linear programmer does not feel good with such things, rather wants to run away.
Rock star (Software Scientist)
