Публикация была переведена автоматически. Исходный язык: Английский
Вольный перевод оригинальной публикации Anton Zaides, под каждым словом которого лично я готов подписаться (в т.ч. и как человек, у которого прямо сейчас на проектах 2 практиканта и один стажер).
У каждой компании свои оправдания:
В маленьких стартапах — «у нас очень маленькая команда, и у нас нет времени на обучение новичков, нам нужны инженеры, которые будут результативны с первого дня».
В средних компаниях — «мы собираемся очень быстро расти, нам нужны инженеры, которые смогут управлять масштабированием и ранее сталкивались с такими проблемами».
В крупных компаниях — «у нас сложная инфраструктура, новичкам потребуется много времени, чтобы освоиться».
Это все чушь.
И я не говорю здесь о возрасте. Есть 25-летние старшие сотрудники, и есть 40-летние новички, которые сменили сферу деятельности.
Разработка программного обеспечения - это не полеты в космос
Некоторые разработчики становятся сеньорами менее чем за 3 года, некоторые даже без профильного образования. Если вы мне не верите, почитайте истории Джордана Катлера, Тайгера Аброди и Райана Питермана.
Я не говорю, что через 3 года они будут знать все — но они будут результативны и смогут решать большинство проблем корректно.
Как и со всем в жизни, могут случаться откаты. Вы будете становиться лучше со временем, но темп вашего роста замедлится. Вы можете различить разработчика с годом опыта и того, у больше 5 лет, но между теми, у кого 10 и 15 лет разницы? Вероятно, не сможете.
Есть случаи, когда вам нужен высокий уровень экспертизы, и мы к ним сейчас вернемся.

Вовлечение только что выпущенного студента в существующую кодовую базу и обучение его так, чтобы он стал продуктивным, не так уж и сложно — и займет всего за пару недель.
Неопытные разработчики могут добиться великих успехов:
- Эван Спигель и Бобби Мёрфи основали Snapchat в 2011 году, когда им было 21 и 23 года, они были студентами.
- Цукербергу было 20 лет, когда он начал Facebook.
- Дрю Хьюстон был студентом в 24 года, когда основал Dropbox.
- Ларри Пейдж и Сергей Брин разработали первую версию Google в 24 года, также будучи студентами.
- Билл Гейтс основал Microsoft в 20 лет (а Джобс был всего на год старше, когда начал Apple).
Если студенты могут создавать успешные компании, я уверен, они справятся с созданием нового экрана или микросервиса. Да, я знаю, что большинство из них были вундеркиндами в программировании, которые начали писать код еще в средней школе.
Но вот в чем дело — амбиция, характер и ум имеют мало отношения к опыту.
Почему стоит нанять младшего разработчика на следующую открытую позицию
Вы — руководитель команды, и вам нужно нанять еще одного разработчика для вашей команды.
Я был на вашем месте. За последние 2 года я нанял 5 разработчиков — двух сеньоров и трех джунов. Все джуны до сих пор в моей команде, и они определенно уже не джуны.
5 причин, почему найм отличного младшего - правильная ставка для вас:
- У вас больше кандидатов, и вы можете получить лучших. Когда вы ищете full-stack разработчика с опытом работы от 5 лет на Python и от 3 лет на React, у вас будет меньше вариантов, и в конечном итоге вы вынуждены будете пойти на компромисс.
- Джуны приносят свежую энергию в команду — им хочется учиться, и у них есть стремление доказать себя и добиться успеха. Их мотивация может быть заразительной!
- Опытные члены вашей команды будут рады работать с умными и мотивированными разработчиками. Это даст им возможность наставлять и обучать, чего им может не хватать, если в команде только сеньоры.
- Джуны не ограничены тем, что знают — они не будут пытаться повторно использовать технологии из предыдущих компаний или воссоздавать те «клёвые» шаблоны проектирования, которые были полезны только в конкретном контексте.
- Джуны более открыты к работе с новыми технологиями и менее придирчивы к задачам, которые им нужно выполнять. Это не значит, что их нужно заставлять исправлять неприятные ошибки весь день, но это дает вам больше гибкости в команде.
- Хорошие джуны быстро учатся и ищут обратную связь, поэтому ими легче руководить. Они хотят расти и хотят знать, что вы думаете о их работе.
И самая большая причина:
У джунов есть стажировки и студенческие позиции
Каждый из трех джунов, которых я нанял в свою команду, начинал с позиций студентов/стажеров. Это значит, что я мог оценить их навыки перед предложением полной занятости.
Это преимущество, которого у вас никогда не бывает с сеньорами — и часто обе стороны страдают из-за этого. Разработчики остаются в средних компаниях дольше, чем необходимо для резюме, а менеджеры будут мириться с средними исполнителями из-за страха увольнения людей.
Идеальное сочетание
Иногда вам нужно нанять сеньора с очень специфическими знаниями, особенно в крупных организациях. Если вы хотите создать версию приложения для IOS, я бы не брал кого-то, кто никогда не работал со Swift. Или если ваша производительность ухудшается по мере масштабирования, и вы хотите, чтобы кто-то справился с этим, опытный инженер — лучший выбор.
Но для большинства команд, работающих над SaaS-продуктом, соотношение джунов/сеньоров может быть довольно высоким. В то время как джунам нужен кто-то, от кого можно учиться, многие из них не требуют много времени и внимания в формате 1:1. Вот замечательная аналогия, которая мне нравится:
Представьте свою команду не как озеро, а как реку. Озеро застаивается. В нем нет энергии или побуждения к изменениям. То же самое верно и для групп, которые застаиваются. Они выращивают посредственность и удовлетворенность; они не любят риск. Река всегда текущая и меняющаяся с множеством потрясающей энергии. Вы хотите реку.
Река зависит от потока воды, и ваша команда зависит от потока людей и информации. Вы можете представить людей разделенными на три группы: новая кровь, новые лидеры и старейшины, готовые к новому вызову. Вот как эти группы должны сбалансироваться и течь:
→ Самая большая группа должна быть новой кровью.
→ Для течения вы хотите стабильный поток новой крови, становящейся вашими новыми лидерами, и новых лидеров, становящихся старейшинами.
→ Ключ к потоку — в поступлении новой крови и уходе старейшин. Чтобы это работало, вы хотите, чтобы ваши старейшины переходили, прежде чем они забьют поток и нарушат поток возможностей для других. Если вы вообще не нанимаете младших, ваша команда застаивается.
Около года в моей команде было 2 сеньора и 3 джуном. Полгода назад, мы вместе с моим ведущим разработчиком-девушкой решили, что для нее пришло время перейти в другую команду, где она могла бы расти лучше (я возглавляю команду full-stack, а ей хотелось глубоко погрузиться во фронтенд).
При этом, мы выжили и до сих пор продуктивны.
Джун не означает эксплуатацию
Весь смысл найма джунов состоит не в том, чтобы иметь «бесплатную рабочую силу», а в создании продуктивной и лояльной команды. Это возможно тогда, когда вы платите им то, что они заслуживают.
Платить джунам чуть меньше (даже если они чрезвычайно талантливы) имеет смысл — вы вкладываете много времени и энергии в их обучение, и потребуется некоторое время, прежде чем они станут эффективными.
Но если предположить, что вы нанимаете отличных джуном — это не займет больше года. После этого вы должны платить им в соответствии с их навыками, а не годами опыта. В противном случае — они просто получат должности среднего/старшего уровня в других местах, и будут правы.
Anton Zaides (перевод: Павел Федотов)
A free translation of the original publication by Anton Zaides, under every word of which I personally am ready to subscribe (including as a person who right now has 2 interns and one intern on projects).
Each company has its own excuses:
In small startups, "we have a very small team, and we don't have time to train newcomers, we need engineers who will be effective from day one."
In medium—sized companies, "we are going to grow very fast, we need engineers who can manage scaling and have previously faced such problems."
In large companies, "we have a complex infrastructure, it will take a long time for beginners to get used to it."
It's all nonsense.
And I'm not talking about age here. There are 25-year-old senior employees, and there are 40-year-old newcomers who have changed their field of activity.
Software development is not about flying into space
Some developers become seniors in less than 3 years, some even without specialized education. If you don't believe me, read the stories of Jordan Cutler, Tiger Abrodi and Ryan Peterman.
I'm not saying that in 3 years they will know everything — but they will be effective and will be able to solve most problems correctly.
As with everything in life, kickbacks can happen. You will get better over time, but your growth rate will slow down. Can you distinguish between a developer with a year of experience and one with more than 5 years, but between those with 10 and 15 years of difference? You probably won't be able to.
There are cases when you need a high level of expertise, and we will return to them now.

Getting a newly graduated student into an existing codebase and training him so that he becomes productive is not that difficult — and will take only a couple of weeks.
Inexperienced developers can achieve great success:
- Evan Spiegel and Bobby Murphy founded Snapchat in 2011, when they were 21 and 23 years old, they were students.
- Zuckerberg was 20 years old when he started Facebook.
- Drew Houston was a student at 24 when he founded Dropbox.
- Larry Page and Sergey Brin developed the first version of Google at the age of 24, also as students.
- Bill Gates founded Microsoft at the age of 20 (and Jobs was only a year older when he started Apple).
If students can create successful companies, I am sure they will be able to create a new screen or microservice. Yes, I know that most of them were programming geeks who started writing code in high school.
But here's the thing—ambition, character and intelligence have little to do with experience.
Why it's worth hiring a junior developer for the next open position
You are a team leader and you need to hire another developer for your team.
I was in your place. Over the past 2 years, I have hired 5 developers — two seniors and three juniors. All the Junes are still on my team, and they're definitely not Junes anymore.
5 Reasons Why Hiring a Great Junior Is The Right Bet For You:
- You have more candidates and you can get the best ones. When you are looking for a full-stack developer with at least 5 years of experience in Python and at least 3 years in React, you will have fewer options, and eventually you will have to compromise.
- Junes bring fresh energy to the team — they want to learn, and they have a desire to prove themselves and succeed. Their motivation can be contagious!
- Experienced members of your team will be happy to work with smart and motivated developers. This will give them the opportunity to mentor and teach, which they may lack if there are only seniors in the team.
- Junes are not limited by what they know — they will not try to reuse technologies from previous companies or recreate those "cool" design patterns that were useful only in a specific context.
- Junes are more open to working with new technologies and less picky about the tasks they need to complete. This does not mean that they need to be forced to fix unpleasant mistakes all day, but it gives you more flexibility in the team.
- Good juniors learn quickly and seek feedback, so they are easier to lead. They want to grow and want to know what you think about their work.
And the biggest reason is:
Junes have internships and student positions
Each of the three junos I hired to my team started out as students/interns. This means that I could evaluate their skills before offering full-time employment.
This is an advantage that you never have with seniors — and often both sides suffer because of it. Developers stay in medium-sized companies longer than necessary for a resume, and managers will put up with average performers for fear of firing people.
The perfect combination
Sometimes you need to hire a senior with very specific knowledge, especially in large organizations. If you want to create an iOS version of the app, I wouldn't take someone who has never worked with Swift. Or if your performance deteriorates as you scale and you want someone to handle it, an experienced engineer is the best choice.
But for most teams working on a SaaS product, the ratio of juniors/seniors can be quite high. While junes need someone to learn from, many of them don't require a lot of time and attention in format 1:1. Here's a great analogy that I like:
Imagine your team not as a lake, but as a river. The lake is stagnating. There is no energy or motivation for change in him. The same is true for groups that stagnate. They cultivate mediocrity and contentment; they don't like risk. The river is always flowing and changing with a lot of amazing energy. You want a river.
The river depends on the flow of water, and your team depends on the flow of people and information. You can imagine people divided into three groups: new blood, new leaders, and elders ready for a new challenge. That's how these groups should balance and flow:
→ The largest group should be new blood.
→ For the flow, you want a steady flow of new blood becoming your new leaders and new leaders becoming elders.
→ The key to the flow is in the arrival of new blood and the departure of the elders. For this to work, you want your elders to move on before they clog the flow and disrupt the flow of opportunities for others. If you don't hire juniors at all, your team stagnates.
For about a year, my team had 2 seniors and 3 juniors. Six months ago, my lead developer, a girl, and I decided that it was time for her to move to another team where she could grow better (I lead the full-stack team, and she wanted to dive deep into the frontend).
At the same time, we survived and are still productive.
June does not mean exploitation
The whole point of hiring Junes is not to have "free labor", but to create a productive and loyal team. This is possible when you pay them what they deserve.
Paying Junes a little less (even if they are extremely talented) makes sense — you invest a lot of time and energy in their training, and it will take some time before they become effective.
But assuming that you hire excellent juniors, it won't take more than a year. After that, you should pay them according to their skills, not years of experience. Otherwise, they will just get middle/senior level positions in other places, and they will be right.
Anton Zaides (translated by Pavel Fedotov)