There is a way...

Hello, Habr. I've been watching IT market for a long time. But i'd never written anything. That's the first part of my first article, so please don't hate it too much.

In this series of articles i'd like to share my experience of finding, teaching and integrating interns and juniors in a product team. (Don't confuse them with freelance teams or something like that).

I'd like to point out that everything you'll be reading in my articles represents my personal opinion. Yes, it has sound foundation in years of experience. But i won't say my experience is exclusive and therefore, the only right way to do things is to do it as i say.



In this part we'll see two sides of one entity. That, in turn, will help you to determine what kind of people you want for your team.

Let's look closer on the two basic scenarios:

The programmer

In a way there are few differences between modern programmer (Hey, did you see those «We'll make you programmer in three months» advertisements too?) and account-manager. With that said, let's roll.

A modern programmer is just an implementer

For the most of them programming is just a job in our times. It's not at all surprising, considering those 3 months courses we'd all heard about. A programmer can write code, but he always can stop doing it.

He'll be developing your program features, without asking too many questions, or hell do exact opposite, bombard you with questions (but we'll talk about that kind of programmer's later).

A programmer usually doesn't concern himself with trends or innovations. He writes his code, according guru's or dev-bloger's advices.

For example, I do not understand why Facebook has such horrible, illogical and overcomplicated frontend organization. And why everyone are taking it as example.

Everyone can be programmer

The bitter truth of our time. On one hand, that's cool. Progress, development and all that implies. On the other hand, and HR specialists will understand what am I talking about, IT market is flooded by low skilled specialists. Yes, it's over-saturated. There is no more vacations for junior specialists with ?100.000 salary. At least, I didn't see them for a long time. Current lead-programmer salary is about ?250.000. That's a good indicator.

You can easily find a programmer

That's true. If you sure you need that kind of programmer. Now days an average programmer can ace a job interview. Youtube channels highlighting job interview's questions, guides for more or less esoteric themes, will be huge advantage in that. However, in the end we'll get a programmer, who'd learned in a month things that various courses teaching for a six month or more. The question of said programmer qualification stays open.

In truth, the picture we'll see looking closer won't be pretty. Developer who doen't understand the basic principles of web-development. A specialist, who writes his code exactly how he'd seen it done on youtube video. Or in documentation, for the best case scenario.

Who needs that kind of programmer?

Despite everything that was said above, those programmers has definite value. For instance:

• A big companies with well established processes and a stable stack.
• Mass producing teams, using instruments that their clients tells them to use.
• A government organizations. The processes in that kind of organizations re slow, so a programmer can gradually rise his skill while working there. No haste at all.

Engineer

As a rule, their life is devoted to self-improvement and research.

A deep analysis

An engineers will deconstruct your legacy piece by piece, they'll find a potential problems and will suggest a ways to avoid them. If an engineer has a lot of experience, he can find a team with a little help by the HR agency, or even to do it by himself.

Similarly, he doesn't need a specification for a task, because he knows that is a useless waste of time. He knows that decomposition and task distribution is better done upon researching a project requirements.

Therefore, requirements analysis comes first, then project planning, and only then a development. Time distribution is looking like that: 40/40/20.

Using powerful practices

Likewise, a difficult practices implementation is one of an engineers key features. If you ask an average developer what he knows about *DD, a likely result will be no answer at all. An engineer is different. Often, he works using TDD, planning his work flow using a set of BDD practices, product planning is done with DDD.

Consequently, the code quality of engineer is higher. Before linters and typechecerse became wildly used, no one cared how to write a code. Now the situation is different, but some things are the same. I am talking about cleanness, readableness, scalability, modularity of hired specialists code. It still leaves much to be desired.

Who needs an engineer?

• Certainly, a big companies that are planning for their future.
• International companies that have their branches in Russia. Usually they hire programmers for routine work and engineers for a more difficult tasks with a perspective for them to become a team-lead or architect.
• Private teams, which decide their work strategies for themselves, usually programmers have no place in such groups.

What's next?

The next part will be about starting depending on your choice (programmer or engineer). How does candidate searching process looks like. How to automate said process. What should you do if you've got too few or too many responses. And, the most important, what test task should you give for your future keyboard comrades.