Резюме программиста: что в нём читают на самом деле
Резюме разработчика проходит через двух читателей подряд, и они ищут разное. Сначала рекрутер или система отбора сверяет стек и грейд с требованиями вакансии, и на этом этапе отсеивается большая часть откликов. Потом технический специалист смотрит, какие задачи вы решали и насколько самостоятельно.
Отсюда практический вывод: стек должен читаться за пять секунд, а опыт объяснять, что именно вы делали и что из этого вышло. Ниже разбор по обоим пунктам с примерами для разных направлений.
Стек: где размещать и как оформлять
Технологии должны быть в двух местах. Первое: отдельный блок сразу после заголовка с должностью, чтобы его видели при беглом просмотре. Второе: внутри описания каждого места работы, потому что там видно, где технология применялась в реальных задачах.
Разница принципиальная. «Знаю Kubernetes» ничего не говорит об уровне, а «поддерживал 14 сервисов в Kubernetes, настроил canary-деплой» отвечает сразу на несколько вопросов. Списки без контекста рекрутер пролистывает, а технический специалист по ним ничего не оценивает.
| Так не стоит | Так лучше |
|---|---|
| Python, Java, C++, JS, PHP, Go, Ruby, Rust | Уверенно: Python, FastAPI, PostgreSQL. Есть опыт: Go, Kafka |
| Знание принципов ООП и алгоритмов | Проектировал доменный слой сервиса заказов, писал алгоритм подбора слотов доставки |
| Работа с базами данных | PostgreSQL: проектирование схемы, оптимизация запросов, партиционирование таблицы на 400 млн строк |
Сервис сравнит ваш стек с требованиями и покажет, каких технологий не хватает в тексте
Проверить резюме под конкретную вакансиюОпыт: примеры по направлениям
В левой колонке привычные формулировки, в правой то же самое, но так, чтобы по тексту можно было оценить уровень. Опыт при этом не меняется, меняется только описание.
Бэкенд
Как пишут: Разработка и поддержка backend-сервисов
Как лучше: Разрабатывал backend платежного сервиса на Go: gRPC-API, PostgreSQL, Kafka. Вынес расчёт комиссий в отдельный сервис, время ответа основного API упало с 800 до 120 мс
Видны стек, зона ответственности и измеримый эффект для системы
Фронтенд
Как пишут: Верстка и разработка интерфейсов
Как лучше: Развивал личный кабинет на React и TypeScript: перевёл формы на react-hook-form, покрыл ключевые сценарии тестами, снизил количество багов в релизе с 12 до 3
Понятно, какой код писали и что изменилось в качестве
Мобильная разработка
Как пишут: Разработка мобильного приложения
Как лучше: Поддерживал Android-приложение на Kotlin (300 тыс. MAU): переписал экран каталога на Jetpack Compose, время холодного старта сократилось с 3.1 до 1.4 с
Есть масштаб аудитории, технология и результат в цифрах
Data / ML
Как пишут: Работа с данными и моделями
Как лучше: Собирал ETL-пайплайны на Airflow и Python, обучил модель оттока на CatBoost: precision вырос с 0.61 до 0.74, модель внедрена в рассылку
Метрика модели и факт внедрения важнее списка библиотек
DevOps
Как пишут: Настройка серверов и CI/CD
Как лучше: Перевёл сборку 14 сервисов на GitLab CI и Kubernetes, добавил canary-деплой: среднее время выкатки сократилось с 40 до 9 минут, откаты стали автоматическими
Названы объём, инструменты и эффект на процесс команды
Как показать грейд без слова «senior»
Уровень читается не из заголовка, а из масштаба того, что вы описали. Заявленный в шапке senior при описании задач уровня junior вызывает обратный эффект.
Junior
Выполняет поставленные задачи, работает в рамках готовой архитектуры, код проходит ревью старших.
Middle
Закрывает задачу целиком: от уточнения требований до выката, сам выбирает решение внутри своей части, ревьюит чужой код.
Senior
Отвечает за архитектуру направления, влияет на технические решения команды, разбирает инциденты и растит других разработчиков.
Поэтому вместо «senior-разработчик» в шапке работают формулировки вида «проектировал сервис нотификаций с нуля, вёл ревью команды из четырёх человек, разбирал продовые инциденты». Грейд станет очевиден без заявления.
Пет-проекты и GitHub
Чем меньше коммерческого опыта, тем важнее пет-проекты: для начинающего разработчика это единственный способ показать код. При опыте от трёх лет они уходят на второй план, но живой GitHub всё равно добавляет доверия.
Два правила. Первое: ссылка должна вести на репозитории с историей коммитов и внятным README, а не на пустой профиль с форками. Второе: описывать пет-проект стоит так же, как рабочую задачу, то есть с задачей, стеком и результатом, а не строкой «телеграм-бот на Python».
Проверка резюме под вакансию
В IT автоматический отбор встречается чаще, чем в других сферах: требования в вакансиях формализованы, и сравнивать их с резюме алгоритмом удобно. Поэтому совпадение формулировок стека с текстом вакансии влияет на то, дойдёт ли отклик до живого человека.
Resumecheck.ru сравнивает резюме с описанием вакансии и показывает процент соответствия, недостающие технологии и слабые места в описании опыта. Отдельно разобрано, как формулировать достижения в резюме, а общая структура и формат для любой профессии показаны на странице пример резюме. Проверить резюме можно бесплатно, первая проверка занимает около 30 секунд.
Часто задаваемые вопросы
Где в резюме размещать стек технологий?
Отдельным блоком в начале, сразу после заголовка с должностью, и ещё раз внутри описания каждого места работы. Первый блок нужен для быстрого сканирования и для систем отбора, второй показывает, где именно вы применяли технологию: «знаю Kubernetes» и «поддерживал 14 сервисов в Kubernetes» читаются совершенно по-разному.
Как показать грейд, если в трудовой он не указан?
Грейд читается не из названия должности, а из масштаба задач: размер сервиса, самостоятельность решений, участие в проектировании, код-ревью и наставничество. Junior выполняет задачи, middle закрывает их целиком с проектированием, senior отвечает за архитектуру и влияет на решения команды. Опишите это в опыте, а не заявляйте в заголовке.
Нужны ли пет-проекты и GitHub?
Обязательны, если опыта мало: для junior это фактически замена коммерческого опыта. При опыте от трёх лет они перестают быть решающими, но ссылка на GitHub с живыми репозиториями лишней не бывает. Пустой профиль с одним форком лучше не указывать вовсе.
Стоит ли перечислять все технологии, которых касался?
Нет. Длинный список размывает картину, а на собеседовании спросят по любому пункту. Разумно разделить на «использую уверенно» и «есть опыт», а всё, что видели один раз на курсе, убрать. Для системы отбора важнее совпадение с требованиями конкретной вакансии, чем длина перечня.
Проверяют ли резюме разработчиков автоматическими системами?
Да, и в IT чаще, чем в других сферах: требования в вакансиях формализованы, поэтому сравнивать резюме с ними алгоритмом удобно. Загрузите резюме и описание вакансии в Resumecheck.ru: сервис покажет процент соответствия и недостающие ключевые слова из стека. Первая проверка бесплатна.