Джун-разработчик: что должен знать новичок и почему в вакансиях требуют слишком много

Хотите страшилку на ночь? Заходит разработчик на hh.ru в поисках первой работы и открывает вакансию джуна. А от него хотят: язык программирования, фреймворк, Git, базы данных, пет-проекты, английский на уровне носителя и лет пять опыта коммерческой разработки. БУУ! 

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

Содержание

Кто такой junior разработчик

Почему в вакансиях для джунов требуют так много

Что должен знать junior разработчик на старте

Что джун не обязан знать идеально

Как понять, что вы уже готовы откликаться

Как расти из джуна в сильного разработчика

Кто такой junior разработчик

Junior-разработчик — это младший специалист в IT-команде. Он ещё совсем малыш, но уже умеет писать код и решать простые коммерческие задачи. Только его надо перепроверять, так что работает джун под контролем коллег на опыте. 

Чем junior отличается от стажёра и мидла

Разница между ними в уровне самостоятельности, объёме задач и степени ответственности. Вот они, слева направо:

• Intern (стажёр). Это прям новичок-новичок. Опыта у него нет, в команде он вообще больше учится, чем реально работает. Ему доверяют второстепенные задачи — если там всё сломается, то никто особо и не заметит.
• Junior (младший специалист). Это уже боевая единица. Он делает реальные задачи и приносит пользу бизнесу. Джуниор сам пишет код для простых функций, фиксит баги и покрывает тестами готовые модули. В отличие от стажёра, у джуна есть база, так что уж рутину ему доверить точно можно. Но у него всё равно есть наставник на всякий случай.  
• Middle (мидл). Вот сначала он, а потом уже Ариана Гранде и Леди Гага.  Это полностью самостоятельный инженер. В отличие от джуниора, middle чаще сам проектирует архитектурное решение для своей задачи, выбирает инструменты и несёт больше ответственности за стабильность продукта. Ему не нужен ментор — мидлу достаточно поставить бизнес-цель, дальше он сам всё сделает. 

Почему в вакансиях для джунов требуют так много

Величайший секрет в том, что описание вакансии — не минимальный порог входа, а портрет идеального кандидата. Работодатель часто перечисляет вообще всё, что хорошо бы знать для работы. Хотя многие скиллы — на вырост. 

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

Что в вакансии обязательно, а что будет плюсом

Чтобы получить работу, надо не только шарить в разработке, но ещё и уметь читать. Как минимум, чтобы видеть разницу между железобетонными требованиями и пожеланиями. 

✍️ Обязательные навыки: «Требования», «Нужно уверенно», «Обязательно знание». Это так называемая база: язык программирования, фреймворки и Git. Без них можно даже не соваться на рынок.

Но точно стоит сунуться на курсы и прокачать навыки — Яндекс Практикум как раз повысил скидку по промокоду до 10%. Успевайте, только до 30 июля.

✍️ Дополнительные навыки: «Желательно», «Будет плюсом», «Знакомство с». Это уже роскошный максимум. Даже если вы не знаете технологию из этого списка, но базовый стек совпадает и у вас есть практика, можно и нужно откликаться. Доучитесь уже в процессе.

Когда требования правда завышены

Но иногда завышенная планка — это не поиск идеала. Это значит, что компания прибалдела, и хочет мидла по цене джуна. Если видите в вакансии такое, то «спасибо, следующий».

🚩Требуется несколько лет коммерческого опыта. У junior-специалиста по определению не может быть 3–4 лет работы в компаниях, иначе он был бы уже не джуниор.

🚩Ожидается самостоятельная разработка и архитектура. Компания отнимает хлеб у мидлов, которые, вообще-то, и должны с нуля проектировать сложные системы без помощи команды.

🚩Поддержка сложного продукта без наставника. Если в описании указано, что вы будете единственным разработчиком на проекте, у вас не будет ментора для профессионального роста. И спросить, что за ужас здесь творится, тоже будет не у кого. 

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

Что должен знать junior разработчик на старте

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

Hard skills: техническая база

• Язык программирования. Нужно уверенно писать простой код, понимать синтаксис языка, его типы данных, циклы и функции.
• Базовые структуры данных и алгоритмы. Достаточно знать, чем массив отличается от списка, как работают хэш-таблицы и как устроена простая сортировка или поиск.
• Система контроля версий Git. Вы должны уметь создавать ветки, делать коммиты, отправлять код в репозиторий и разрешать простейшие конфликты слияния.
• Работа с IDE. Стоит владеть и средой разработки, например, VS Code, PyCharm или IntelliJ IDEA, уметь пользоваться встроенным дебаггером для поиска ошибок.
• Основы баз данных. Понимать разницы между реляционными и нереляционными БД, уметь писать базовые SQL-запросы: SELECT, INSERT, JOIN.
• Базовый фреймворк. Знать основной инструмент в своей специализации. Например, React для фронтенда или Spring для Java-бэкенда на уровне создания простого приложения.

Soft skills: что часто важнее идеального знания фреймворка

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

• Самообучение. +100 к уважению, если вы можете искать инфу, читать документы и пытаетесь сами решать проблему, а не бежите сразу к старшим. 
• Умение задавать вопросы. Джуниор не должен сидеть молча часами, если он застрял на задаче. Важно уметь чётко сформулировать, что уже сделано и где возникла сложность.
• Обратная связь. Покажите, что готовы адекватно воспринимать критику на код-ревью. Ошибки в коде начинающего — это нормальный этап обучения, а не личное оскорбление.
• Командная работа. Важно понимать, что код пишется для общего продукта. И вы должны следовать принятым в команде правилам оформления кода, даже если некоторые из них действуют, потому что «так исторически сложилось».

Что джун не обязан знать идеально

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

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

А если умеете, то что вы вообще забыли в вакансиях для джунов?

Ошибки для джуна нормальны, если он умеет с ними работать

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

Адекватный руководитель смотрит не на сам факт ошибки, а на то, как вы к нему относитесь. 

Как вести себя, чтобы вас уволили ещё на испытательном сроке:

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

Где проходит граница ответственности junior-разработчика

Типичный день junior-разработчика: «Всё нормуль, планов нуль. Обычное утро, вчера такое же было». У него работа проходит почти без приколов: джун отвечает за простые задачи, создание изолированных фич, исправление мелких багов и написание автотестов.

А вот где начинаются глобальные технические решения, его полномочия всё, окончены. Тут проходит граница с мидлом и сеньором. 

• Архитектура проекта. Джун пишет код внутри уже созданной структуры, но не определяет, как модули приложения будут глобально взаимодействовать друг с другом.
• Продакшен. У него не должно быть единоличного доступа к выпуску кода на «живой» сервер без предварительного ревью от старших коллег.
• Бизнес-риски. Если код джуниора сломал систему, это в первую очередь ответственность его наставника или тимлида, которые утвердили эту задачу и пропустили ошибку на этапе проверки.

Как понять, что вы уже готовы откликаться

«Вот щас выучу фреймворк, ещё одну библиотеку проштудирую и вот тогда как откликнусь!» — так можно до бесконечности просиживать штаны. Вам не нужно быть идеальным разработчиком — на первом этапе достаточно иметь базу и уметь учиться.

Вот чек-лист готовности. Хватит терять время и ждать подходящего момента, если вы:

Что должно быть в портфолио джуна

Если в резюме похвастаться особо нечем, хвастайтесь хотя бы портфолио. Лучше для этого зарегаться на GitHub. 

В основе портфолио обычно пет-проект — собственный учебный проект. Он нужен, чтобы тимлид оценил:

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

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

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

Как читать вакансии и не отсеивать себя раньше времени

Часто процесс поиска выглядит так: вы открыли страницу, увидели километровый список требований, закрыли страницу.  Но вообще-то золотое правило ИТ-рекрутинга звучит так: если резюме совпадает хотя бы с 60-70% ключевых требований, то полный газ. 

И ещё пара советов, как хотя бы начать:

• Не ждите идеального момента. Он не настанет. И вы никогда не будете соответствовать вакансии на все 100%. Идеальный кандидат, который знает каждую строчку из описания, скорее всего, уже стоит х2. Ему позиция джуна вообще не сдалась.
• Игнорируйте второстепенные требования. Если вы уверенно владеете основным языком программирования, но в требованиях указана незнакомая вам библиотека со сноской «желательно» — смело отправляйте резюме. Потом разберётесь, что это. 
• Относитесь к отказам как к опыту. Да-да-да, банальщина. Но что делать — отказов будет много, лучше использовать их хотя бы как тренировку.  Каждый отклик и каждый собес  — это бесплатный аудит ваших знаний. Вы на практике поймёте, какие вопросы задаёт рынок, и сможете подтянуть слабые места.

Как расти из джуна в сильного разработчика

Мидл отличается от джуна не только тем, что знает больше фреймворков или быстрее пишет код. Сильный junior developer растёт, когда начинает глубже понимать бизнес-логику задач, пишет понятный для коллег код и постепенно забирает себе больше ответственности. Чем меньше контроля со стороны вам требуется для работы, тем ближе вы к следующей ступени развития. 

Что прокачивать в первые месяцы работы

Если вы прошли голодные игры, наконец устроились и расслабились, то рано. Надо ещё испытательный срок пройти, в карьере развиваться и вот это вот всё. На первых этапах сфокусируйтесь на этом:

• Разбор замечаний на код-ревью. Не просто исправляйте строчки кода, на которые указал ментор. Разбирайтесь в первопричине: почему предложенный им вариант эффективнее, безопаснее или легче читается.
• Активное чтение чужого кода. Проект, в который вы пришли, писали десятки людей до вас. Изучите кодовую базу компании — это лучший учебник по архитектуре и стандартам внутри вашей команды.
• Качественная коммуникация. Учитесь задавать точные вопросы. Прежде чем прийти к старшему коллеге с проблемой, сформулируйте её по схеме: «Я делаю задачу Х, столкнулся с ошибкой Y, попробовал решения А и Б, но они не сработали. Подскажи, куда копать?»
• Ведение базы знаний. Записывайте все внутренние процессы, команды для настройки окружения и особенности архитектуры в личные заметки. Джун, который спрашивает об одном и том же нюансе дважды, только тратит время команды. И нервирует лидов. 
• Оценка сроков. Учитесь дробить крупные задачи на мелкие подзадачи и замерять, сколько времени уходит на их реализацию. Понимание своей скорости работы — важнейший навык самостоятельного инженера.
• Понимание бизнес-смысла. Перед написанием кода всегда задавайте себе вопрос: «Какую проблему пользователя или бизнеса решает эта фича?» Разработчик, понимающий пользу своего труда, создаёт гораздо меньше багов и логических ошибок.

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