Ошибки джунов начинаются не на собеседовании, а сразу после офера: за первый месяц новичок может либо встроиться в команду, либо быстро доказать, что тестовое задание было лучшей его работой. Руководитель ProninTeam Андрей Пронин разобрал шесть таких провалов — от неподъёмной первой работы до бездумной сдачи кода от ИИ. Для разработчиков, тимлидов и HR в IT это полезное напоминание: найм джуна не заканчивается подписью в офере.
Материал опубликован 14 сентября в блоге Яндекс Практикума, сообщает Habr / Карьера. Пронин пишет не с позиции карьерного теоретика: семь лет назад он сам был джуном, последние пять лет руководит студией заказной разработки и нанимает новичков. Его главный тезис простой и неприятный: офер — это входной билет, а не доказательство профессиональной пригодности.
Первая история — про слишком ранний рывок. Пронин вспоминает, как после хакатона получил предложение стать PHP-разработчиком, хотя честно предупредил работодателя: PHP не знает. Компания всё равно дала шанс, но через месяц сотрудничество закончилось. Для джуна урок не в том, что нельзя брать сложные оферы. Можно. Но без базы, наставника и понятного ритма обратной связи новичок быстро превращается в источник тревоги для тимлида и расходов для бизнеса.
Отдельно Пронин разбирает хаотичное общение с наставником. Типичная ошибка новичка — дёргать старшего разработчика десятками сообщений в течение дня: «посмотри, я сделал», «а так нормально?», «а теперь?». Работает лучше другой формат: фиксированное окно, например 30 минут утром или вечером, куда джун приносит накопившиеся вопросы и показывает, что уже попробовал сам. Это снижает шум для команды и учит новичка формулировать проблему, а не просто передавать тревогу наверх.
Вторая группа провалов касается найма. Кандидат может нормально пройти собеседование, сделать тестовое и произвести адекватное впечатление, но не выдать промышленный код на реальном проекте. По словам Пронина, один такой разработчик продержался около месяца. Вывод для компаний жёсткий: интервью и тестовое проверяют только часть картины. Нужны испытательный срок с реальными задачами, наставничество и внутренний фильтр качества. Вывод для джуна ещё проще: после офера придётся работать интенсивнее, чем в учебном режиме, потому что разницу между «я знаю синтаксис» и «мой код можно отдавать заказчику» закрывают только практика и ревью.
Самая дорогая история — про код, который работал, но копил технический долг. Один новичок выглядел достаточно уверенно, поэтому его отпустили в более самостоятельную работу на несколько проектов. Первые изменения проверяли внимательно, затем ревью стало выборочным. Позже выяснилось, что часть кода плохо масштабируется, а часть не покрыта тестами. Заказчик был доволен, пока всё запускалось, но студия уже потратила 60 часов на рефакторинг и ожидает сопоставимый объём работ впереди. Это тот случай, где ошибки джунов становятся счётом для работодателя.
Из этой истории рождается практическое правило: pull request джуна должен проходить сплошное ревью, даже если новичку уже доверяют. Пронин пишет, что в ProninTeam теперь ни один pull request не выходит без проверки. Для бизнеса это дороже на старте, зато дешевле, чем разгребать архитектурные решения, принятые человеком без опыта. Для новичка жёсткое ревью тоже выгодно: лучше получить пачку замечаний сейчас, когда от него ещё не ждут уровня мидла, чем через полгода объяснять, почему код не соответствует грейду.
Отдельная боль 2026 года — ИИ-агенты в руках начинающих разработчиков. Пронин описывает джуна, который активно генерировал код и приносил pull request’ы на 2000–2500 строк. Формально задача закрывалась, но вычитать такой объём сложно, а сам разработчик не всегда мог гарантировать, что понимает каждую часть результата. В студии после этого ограничили размер коммитов автоматической проверкой: слишком большой объём возвращается на переделку ещё до ревью. Плюс новичка просят объяснять, как работает конкретный участок кода. ИИ здесь не запрещают, но превращают из «магической кнопки» в инструмент, за который всё равно отвечает человек.
Есть и управленческая сторона. Жёсткий код-стайл, автоматические проверки и придирчивое ревью могут раздражать джунов: кажется, что фича на один-два дня растягивается на неделю, прогресса не видно, заказчик недоволен темпом. В одной из команд новички даже потребовали заменить ревьюера. Конфликт погасили разговором, но позиция осталась прежней: быстрый код без качества не помогает ни студии, ни самому разработчику. Тут полезна модель ситуационного лидерства Херси — Бланшара: новичку на старте нужен высокий уровень контроля, а самостоятельность приходит позже, вместе с навыком.
Финальный пункт — переработки и бесплатные стажировки. Пронин признаёт: задача, которую мидл делает за час, у джуна может занять четыре. Поэтому первые месяцы часто требуют большего вложения времени. Но постоянный аврал быстро заканчивается выгоранием. Если стажировка неоплачиваемая или испытательный срок размыт, условия лучше зафиксировать заранее: какие задачи нужно закрыть, за какой срок, по каким критериям новичка переведут дальше. Иначе ошибки джунов легко маскируются под «надо ещё немного потерпеть», а это плохая стратегия и для карьеры, и для команды.
Главный вывод из этих историй неудобен обеим сторонам: провал джуна почти всегда частично провал работодателя. Новичок отвечает за усилия, вопросы, тесты и понимание собственного кода. Компания отвечает за наставника, ревью, критерии роста и право новичка ошибаться без разрушения проекта. На рынке, где junior-позиции и так достаются тяжело, выиграют не те, кто громче обещает «быстрый вход в IT», а те, кто честно проектирует первые месяцы работы как инженерный процесс.