Офер — это только начало: провалы джунов, которые я видел или совершил сам

Хабр, привет! Меня зовут Андрей Пронин, я руководитель студии заказной разработки ProninTeam и наставник на курсе «Управление командой разработки» в Яндекс Практикуме. Семь лет назад я и сам был джуном, а последние пять руковожу студией и нанимаю новичков, поэтому знаю, что получить офер — малая часть пути. Сложности начинаются потом: нужно закрепиться, набрать скорость и не подвести ни себя, ни команду.

Сегодня я расскажу шесть историй провалов — своих и чужих — и что из них вынес я, а что может забрать себе новичок.

Взял офер, который был мне не по силам

На заре карьеры я хватался за любую возможность куда-то устроиться или получить опыт — иначе как ещё пробиваться. Проходил курсы, заявлялся на хакатоны, толком ещё ничего не зная. Один раз меня взяли — и я случайно попал в команду, которая победила. Моей заслуги в этом не было, только удача: просто пришёл с улицы и прибился к сильным ребятам.

Так вышло, что результат работы команды презентовал я. Видимо, поэтому именно ко мне после защиты подошёл соучредитель одной компании и предложил работу. Что характерно — PHP-разработчиком, сразу с приличной зарплатой. Я честно сказал, что PHP не знаю и не факт, что освою в скором будущем. Морально готов, но результат не гарантирую. Работодателя это не остановило, меня всё-таки взяли.

Чуда не случилось, и PHP я так и не выучил. Примерно через месяц страданий компании пришлось со мной расстаться. Мне честно объяснили, почему у нас ничего не получается, и прямо сказали, что вкладывать деньги в специалиста без базы невозможно. Это было правильно, и я до сих пор благодарен за этот шанс.

Что можно вынести новичку:

В моём случае всё было не зря: я прочувствовал атмосферу работы в IT, пообщался вживую с сильными коллегами и, самое главное, осознал, что действительно хочу быть разработчиком.

А ещё понял, что без наставничества развиваться сложно. И общаться с наставником нужно правильно. У меня было не так: наставника мне не дали, а тимлид постоянно был занят. Ретроспективно я понимаю, что вёл себя не так, как надо: дёргал тимлида в чате постоянными «Алексей, посмотрите, я сделал, что скажете?» — и в итоге просто задолбал. 

С наставником нужно договариваться, а не пинговать хаотично. Оптимально — полчаса в день, утром или вечером: приносишь всё, что накопилось, обсуждаете разом. Наставнику комфортно, потому что джун не дёргает его в течение дня, а сам джун приходит не с сырым «помогите», а с конкретным «я попробовал так и так, что не так делаю?»

В ProninTeam мы решили проблему радикально: назначаем каждому джуну ревьюера-наставника и ведём «ревьюишные» чаты по направлениям, куда любой разработчик может прийти со своей проблемой. В чатах сидят менторы, которые проводят ревью на проектах, поэтому у них есть доступ к коду и весь нужный контекст. Это позволяет джунам получать столько поддержки, сколько они смогут «унести», а дальше их рост зависит только от них самих.

Нанял человека, который не вывез

История повторилась — только я был уже с другой стороны найма. Кандидат нормально прошёл собеседование, сделал тестовое, произвёл хорошее впечатление. Но за месяц не смог выдать код промышленного уровня. Пришлось с ним расстаться. Увы, для компании разработчик, который не закрывает рабочие таски и не приносит ценности заказчику, бесполезен. Рыбка плавает, уточка крякает, разработчик — закрывает боль клиента. Такова суровая правда жизни.

Сделал вывод: не все джуны одинаково полезны, а тестовое и собеседование сами по себе не гарантируют, что человек будет писать качественный код на проекте. Нужна система наставничества и дополнительный внутренний отбор.

Что можно вынести новичку:

Попасть в компанию мало, пройти собеседование — тоже мало. Удержаться можно, только если пахать больше обычного. На испытательном сроке разумно на время забыть про восьмичасовой рабочий день. Знания даже талантливого новичка всегда меньше, чем требуется для уверенной работы, и разница закрывается только временем и усилиями.

Нанял человека, который натворил дел

Другой джун справлялся лучше, и я отправил его в самостоятельное плавание на несколько проектов. Получилось, что его первый код мы проверяли плотно, а потом точечно, без сплошного ревью.

Позже вскрылось, что часть написанного кода сложно масштабировать, часть — не покрыта тестами. Заказчик был доволен, ведь всё работало, но под капотом копился техдолг, о котором никто не знал. 

Сейчас мы от этого страдаем — закрываем проблемные части в коде за свой счёт. Уже потратили 60 часов на рефакторинг и потратим ещё столько же. Всего этого можно было избежать.

Для себя я сделал вывод, что без системы кросс-ревью точно не обойтись. А ещё ревью должно быть сплошным и для всех, независимо от того, доверяешь человеку или нет. Сейчас ни один pull request в ProninTeam не выходит без проверки. Да, это дольше и дороже, но зато не придётся устранять неполадки в коде в авральном режиме, когда проблема вскроется.

Что можно вынести новичку:

Для джуна вывод ещё жёстче: надо добиваться, чтобы код читали старшие разработчики, и не лениться писать тесты.

Если писать код без разбора, ошибки не исчезнут, а всплывут через несколько месяцев, когда репутация уже сложится. Лучше настоять на максимально жёстком ревью прямо сейчас, пока от новичка никто не ждёт совершенства, чем через полгода, когда он станет мидлом, объяснять, почему качество кода не соответствует ни грейду, ни окладу.

Поэтому на собеседовании стоит прямо спрашивать, как устроено наставничество: сколько длится, кто наставник, как устроен рост по грейдам. В компаниях обычно есть чёткий регламент, как вводить новичка в первые месяцы работы. А отсутствие какой-либо системы наставничества — красный флаг.

Джуны устроили бунт против ревьюеров

В ProninTeam мы ориентируемся на стандарты кода из крупных компаний — из финтеха и девелопмента с сильной инженерной культурой. Для маленькой студии это, возможно, избыточно, но у нас есть миссия — растить джунов, а растут они через дискомфорт. Как говорят качки, no pain — no gain. Без боли нет роста, и здесь всё так же.

Жёсткий код-стайл, автоматизация проверок, придирчивое ревью иногда вызывают отторжение, это нормально. Но обычно всё происходит как с пятью стадиями принятия потери: начинается с отрицания, а потом, через гнев, торг и депрессию, наступает принятие.

Иногда возникают бунты. На одном из проектов команда джунов, которых мы «наставничали» особенно плотно, потребовала сменить ревьюера, потому что «этот слишком придирается», а разработка фич, которая должна была занимать день-два, растягивается на неделю. Это можно понять, тем более заказчик оставался недоволен темпом, а сами джуны — отсутствием видимого прогресса: вместо «сделал 20 фич» — бесконечная возня в песочнице.

Бунт удалось погасить в духе бирюзовой компании: без токсичности, с уважением к позиции команды. В итоге люди согласились, что бунтуй не бунтуй, всё равно придётся делать не как хочется, а как положено. 

И в этом есть польза для джунов: писать хороший код важнее, чем уметь быстро клепать проекты. Для нас выгода тоже есть: мы стремимся к долгосрочному сотрудничеству с заказчиками — и качественный код поддерживать гораздо проще.

Что можно вынести новичку:

Сюда хорошо ложится модель ситуационного лидерства Херси — Бланшара, которую мы, кстати, разбираем на курсе «Управление командой разработки». Смысл в том, что новичка сначала нужно плотно опекать — а значит, плотно ревьюить его код и заставлять переделывать, если нужно. А по мере роста навыков стажёру можно постепенно давать больше самостоятельности.

Для джуна важно понимать: правильный старт — это D1, где опыт на нуле, но решает энтузиазм. Новичка в этой категории сильно опекают, строго проверяют, от него многого требуют, и не всегда эти требования будут казаться логичными. Но без энтузиазма и желания научиться новичок автоматически попадает в другую категорию, где с ним будут обходиться по-другому (и ему это не понравится).

Нанял человека, который бездумно сдавал код от нейросети

В компанию пришёл разработчик, который активно пользовался ИИ-агентами. Эту активность можно было измерить — его pull request’ы доходили до 2 000–2 500 строк. Вычитать такой объём нереально: формально задача закрыта, но зачем тогда разработчик-человек, если агент может сделать то же самое напрямую? Да и ошибок при такой работе не избежать — разработчик с небольшим опытом вряд ли будет ручаться за такое количество кода.

Мы сделали выводы: провели профилактическую беседу и автоматизировали коммиты — ограничили количество строк. Если кода много, он просто не проходит автоматическую проверку и возвращается на переделку, не доходя до ревьюера. Кроме того, на каждой итерации мы спрашиваем джуна, как работает та или иная секция. Всё как на разборе тестового задания: мало сдать код и закрыть задачу — нужно объяснить, что происходит внутри.

Что можно вынести новичку:

ИИ — рабочий инструмент, которым можно и нужно пользоваться. Но это не отменяет других правил: сгенерированный код должен проходить ревью, попадать в код-стайл и быть таким же осознанным, как код, написанный вручную.

Перерабатывал сам — и видел, как перерабатывают другие

У джуна без опыта задача, которую мидл закроет за час, часто занимает четыре — это нормально и со временем выравнивается. К сожалению, многие работодатели не готовы переплачивать за лишние часы, поэтому переработки на старте и бесплатные стажировки — это обычная практика. И не из-за того, что работодатель хочет нажиться на бедном джуне, а просто потому, что юнит-экономика иначе не сойдётся.

Кстати, у студентов Практикума похожий опыт: заявленные 10–15 часов обучения в неделю легко превращаются в 20–30 у тех, кто хочет разобраться быстрее и глубже, чем предусмотрено программой.

Но провал начинается там, где переработки становятся неконтролируемыми и совсем без перерывов на отдых. С этим стоит быть аккуратным: тянуть в авральном режиме долго не выйдет — когда джуны забывают про work-life balance, они просто сгорают.

Что можно вынести новичку:

Первое время будет нагруженным, но надо уметь искать пространство для отдыха. Например, если работаете в проекте, а не полный день, спрашивать у работодателя: «У меня горит дедлайн и я справлюсь, но после — можно два дня без задач?»

Соглашаться на неоплачиваемую стажировку или нет — решение каждого. К сожалению, в текущих рыночных условиях спорить с этим особого смысла нет, всё-таки это тоже неплохая возможность для старта.

Но если заходит разговор о бесплатном труде, разумно сразу зафиксировать условия окончания этого периода. То есть установить чёткие критерии — что именно нужно показать, какие задачи и с какой оценкой по времени, чтобы понимать, когда переход состоится, — а не полагаться на расплывчатое «когда почувствуем, что готов».

Провал джуна — это всегда (хотя бы немного) провал работодателя

В некоторых историях в статье проваливались джуны, где-то неправильно вели себя работодатели. Но на деле это две стороны одной медали: джун косячит там, где ему позволяют это сделать, — без обратной связи, без наставничества, без ревью, без чётких правил игры.

Я тоже продолжаю делать выводы и учиться. Не стоит представлять IT-индустрию как место, где вокруг сплошные гении, которые не ошибаются. Тут работают обычные люди, и большинство из них относится к чужим ошибкам вполне спокойно — потому что помнит свои.

Резюмируем:

• Договаривайтесь с наставником о регулярном ритме обратной связи — фиксированное время лучше хаотичных пингов.

• Будьте готовы первое время работать больше восьми часов в день. Так вы быстрее войдёте в ожидаемые сроки по проекту и вырастете. Но без крайностей: без отдыха можно выгореть.

• Не прячьте проблемы за отсутствием тестов. Это вскроется, и цена такой ошибки станет выше.

• Требуйте жёсткого код-ревью, даже когда никто не настаивает. Лучше получить всю критику сразу и вырасти, пока к вам снисходительны.

• Если пользуетесь ИИ-агентами, будьте готовы объяснить, что сгенерировали. Просто сдать код от нейросети недостаточно.

• Уточняйте условия и критерии окончания испытательного срока или стажировки заранее, а не постфактум.