Почему вакансии для джунов требуют мид-уровень и как пройти этот фильтр

Вакансия с приставкой «junior» читается как описание мид-позиции: Java, Spring Boot, Docker, облако, микросервисы, тесты, CI/CD, английский — и где-то на фоне «опыт от двух лет». С этим сталкиваются не только выпускники. Студенты CS-программ, люди после курсов, самоучки — все видят один и тот же список и приходят к одному выводу: меня не возьмут.

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

Откуда в «джунах» стек уровня сеньора

• Стек в команде один. Разработчиков не разводят по грейдам в проекте: тот же сервис, тот же пайплайн, тот же контейнер. В вакансию пишут то, с чем придётся соприкасаться, а не то, что вы обязаны знать до первого рабочего дня.
• Откликов много, фильтр грубый. Резюме сортируют по совпадению ключевых слов. Чем длиннее список в объявлении, тем проще отсеивать автоматически.
• Шаблон. Объявление часто копируют с прошлого найма и правят пару строк, оставляя весь стек нетронутым.
• Страховка от провала. Написать «достаточно основ» — риск получить поток людей без основ. Проще написать максимум и отсеять на интервью.

Ни один из этих пунктов не говорит, что от вас ждут реального опыта с микросервисами. Он говорит, что текст вакансии писали не для вас.

Что проверяют на входе

Разговор почти всегда про одно: умеете ли вы думать кодом. Прочитать чужой файл и понять, что он делает. Найти, где ломается. Объяснить, почему взяли словарь, а не список. Сказать, что произойдёт с базой при двух одновременных записях. Выбор между Python и Java здесь вторичен — спрашивают не про язык, а про способ мышления.

«Иногда кажется, что роль "джуна" ближе к позиции мид-уровня» — так описывает свои поиски студент CS, который учит Python, структуры данных и базы, а теперь берётся за экосистему Spring.

Наблюдение честное. Но за строчкой про Docker обычно стоит не «построй мне кластер», а «не растеряйся, когда я покажу тебе наш пайплайн».

Что в объявлении и что за этим стоит

В каком порядке это осваивать

Учебный план и вакансия идут в разном порядке. В объявлении инфраструктура стоит первой, потому что в команде она уже есть. Учиться приходится снизу вверх.

1. Язык и структуры данных — до уровня, когда выбор коллекции вы объясняете без подготовки.
2. Базы: SQL, индексы, транзакции и один ORM. Без этого разговор про Spring вырождается в пересказ туториала.
3. Один фреймворк. Spring Boot или Django, но не оба сразу: нужна граница между вашим кодом и тем, что делает за вас фреймворк.
4. Обвязка: Docker, переменные окружения, логи. Хватит умения упаковать проект и поднять его с базой одной командой.
5. Тесты и CI/CD — минимальные: пара тестов на критичную логику и пайплайн, который их прогоняет.
6. Английский — уровня, на котором вы читаете документацию и пишете понятный комментарий в трекере.

Пункты 4–6 не нужно доводить до профессионального уровня до первого оффера. Их достаточно попробовать руками, чтобы на интервью не молчать.

Отклики — отдельная работа

• Делите требования на обязательные и «будет плюсом». Если обязательных у вас нет половины, вечер на сопроводительное лучше не тратить.
• Подгоняйте резюме под конкретную вакансию, но только теми словами, которые у вас правда есть. Ключевые слова работают, вранье вскрывается на первом же техническом вопросе.
• Сопроводительное — два-три предложения о вашем проекте и о том, почему вам интересна именно эта команда. Шаблонное «очень заинтересован в вашей компании» не читают.
• Добавляйте в проекты то, чего нет в туториалах: авторизация, внешний API, обработка ошибок, миграции базы.
• Просите фидбек после отказа. Отвечают немногие, но такой ответ стоит дороже курса.

Когда прямой вход не работает

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

Ошибки, которые видно с первого взгляда

• Пять технологий на уровне «проходил курс». Один язык, в котором вы сами находите свои баги, весит больше.
• Портфолио из клонов туториалов. Проект без единого вашего решения смотрят секунд десять.
• Ожидание «вот доучусь и начну откликаться». Год уходит, требования не смягчаются.
• Игнорирование английского, хотя он в требованиях не для красоты: документация, issue и обсуждения живут на нём.
• Молчание после отказа вместо вопроса «чего не хватило».

Что из этого следует

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

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