Меня зовут Екатерина Рычкова, я CEO HR-агентства и рекрутёр с 15-летним опытом.
Сегодня разбираю резюме кандидата из IT-индустрии с хорошим опытом, сильной технической базой и понятной целью: переход в Go-разработку.
Самое приятное, что в IT-сфере оформление резюме — не самое ключевое. Главное, на что смотрит рекрутер:
опыт работы
языки программирования
фреймворки и базы данных, с которыми вы работаете
Итак, смотрим резюме.
Первое, что бросается в глаза, это длительный и стабильный опыт работы с embedded-системами C/C++ уровня.
При этом запрос на позицию Go-разработчика. Хотелось бы больше связанности между этими этапами. Нам нужно сделать акцент: “Почему вы сильны именно для Go-разработки”.
Здесь появляются первые внутренние вопросы у рекрутера:
Почему именно Go? Почему этот кандидат сильный именно для этой роли?
Ответ в резюме есть, но он не выделяется. А рекрутер, к сожалению, не будет додумывать за кандидата.
Как описывать опыт, чтобы вас понимали
В целом стиль описания опыта в резюме хороший. Но его можно усилить.
Я всегда рекомендую использовать метод STAR:
Situation — контекст задачи
Task — что нужно было сделать
Action — что делали именно вы
Result — к чему это привело
Что можно улучшить
1. Технологический стек
Если вы пишете в навыках Go/GoLink, он должен фигурировать и в описании задач.
Не все рекрутеры глубоко разбираются в специфике проектов. Многие ищут по ключевым словам, необходимо делать акцент на профессиональных терминах, навыках, чтобы они были заметны и понятны для всех.
То, что для вас очевидно, для рекрутера может быть неочевидно вообще.
2. Достижения
Формулировки “участвовал в разработке”, “реализовывал функциональность” — звучат размыто.
Показывайте свой личный вклад, отвечая на вопросы:
что именно сделали вы?
за какую часть отвечали?
какой эффект это дало?
3. Цифры и измеримый результат
Не просто “сократилось время обработки инцидентов”, а “сократилось время обработки инцидентов на 30%” — отвечаем на вопрос “что именно изменилось?”.
Даже примерные проценты работают лучше, чем их отсутствие.
Опыт в предыдущей компании
Сильная сторона резюме, в компании из предыдущего опыта как раз есть измеримые достижения, и это большой плюс.
Что можно сделать ещё лучше: показать преемственность навыков с Go-разработкой.
Навыки
Это карта вашей экспертизы. Что здесь можно улучшить?
1. Категоризация
Разделите навыки на группы:
языки программирования
базы данных
фреймворки
инструменты
2. Уровень владения
Если вы где-то работали «один раз», а где-то каждый день, это важно указать.
Рекрутеру нужно быстро понять, где вы сильнее других.
GitHub
Наличие GitHub — это всегда хорошо.
Но важно:
проверить кликабельность ссылок
открыт доступ к проектам
Рекрутеры это действительно смотрят.
Образование и курсы
Обратите внимание на даты обучения. Чтобы логика роста была понятна, не было конфликта в датах обучения и повышении позиции.
Коротко: что стоит доработать в первую очередь
Показать логику перехода в Go-разработку
Усилить опыт через личный вклад и результаты
Добавить цифры там, где это возможно
Структурировать навыки и указать уровень
Проверить GitHub и хронологию обучения
Итог
Это хорошее, устойчивое резюме. Оно уже подходит для рынка.
Но несколько точечных доработок могут:
повысить откликаемость
сократить время поиска
привести к более интересным предложениям
Задача резюме — продать вас без вас. А всё остальное вы уже сделаете на собеседовании.
Если вам тоже нужен взгляд рекрутёра и разбор, что усилить — присылайте резюме в комментарии. Даже небольшие изменения иногда дают неожиданный результат.
UPD: после обновления резюме кандидата пригласили на позицию junior go-разработчика в Сбер. Зарплатные ожидания сошлись, человек успешно вышел на работу и сейчас заканчивает испытательный срок. Очень люблю такой результат нашей работы!
Комментарии (4)
mesvobodnye
22.12.2025 12:15Без контекста все эти циферки ничего не значат.
Нас в отделе год назад было пятеро, двое админов ушло и остаток персонала (все трое - техподдержка, не админы) держат "на зубах" ИТ-инфраструктуру электростанции на плаву - героически ликвидируя аварии и превозмогая массовые инциденты. Здесь не сокращение времени надо считать, а удивляться что всё вообще как-то работает. Это раз.
Второе: кто мне даст показатели времени решения заявок/инцидентов? Аналитик в исполаппарате в Москве? На каком основании спросит он и отошлёт моё письмо безопасникам. Оно мне это надо? Значит цифру -24% я придумаю сам, сам впишу её в резюме. Но правильно ли это?
Беда НР в неправильном целеполагании - надо искать персонал, а не идеальные с вашей точки зрения резюме. "Как?" спросите вы - вопрос не по зарплате - вы этим занимаетесь, вы и думайте.
Итого: глупая статья. Неправильная.
TMTH
22.12.2025 12:15сократилось время обработки инцидентов на 30%
Тут два момента:
Во-первых, разработчики этих цифр обычно не знают (ну т.е. технические метрики может быть и знают, а процессные скорее всего нет; связаны они не напрямую и даже не всегда коррелируют). Поэтому человек, который это пишет в резюме, скорее всего, врёт. И врёт он не потому, что хочет, а потому что вы (конечно же, не Вы конкретно) заставили его врать.
Во-вторых. Заставляя людей врать, что само по себе проблема, вы заставляете их врать плохо и непрофессионально, и это гораздо большая проблема. Сама формулировка - "сократилось время обработки инцидентов на 30%" - как это в реальности выглядит? Все инциденты обрабатывались за 10 минут, а стали за 7 минут? Такого же не бывает. У нас была какая-то текущая статистика, текущее распределение времени обработки. Мы что-то сделали, распределение изменилось. 30% - это что? Среднее? Медиана? P95? А если среднее время уменьшилось на 30%, а P95 увеличилось в 10 раз это достижение или полный провал? А разработчик сам себе задачу ставил (ну, чтобы контекст и основные трейдоффы он мог описать)? Пусть даже и сам, и пусть даже всё получилось, он сделал что хотел и стало действительно лучше, и даже может всё это представить с цифрами (такого почти никогда не бывает, но вдруг). Вы готовы по каждому пункту STAR читать два-три абзаца текста? Сколько таких кейсов можно описать в резюме, просто исходя из объёма? Кто эту ерунду придумал вообще?
kla2005
22.12.2025 12:15Когда руководители компаний начнут осознавать, что главная проблема в найме - это их же рекрутеры, ожидающие захватывающего сюжета в сопроводительном письме, найм начёт эволюционировать от базара к рынку.
Areso
Прохожу курс project management'a, который построен на базе PMBoK.
И вот там есть интересная вещь, которая хорошо подходит к
> Не просто “сократилось время обработки инцидентов”, а “сократилось время обработки инцидентов на 30%” — отвечаем на вопрос “что именно изменилось?”.
таким вот заявлениям. Уменьшилось на 30% - это сырые данные, а информация - это данные обработанные с наличием контекста.
Так вот, контекст. Было 50 часов, стало 35 часов. Снижение на 30%, но мы видим, что было плохо, да и сейчас плохо.
Второе, вот пилит некий разработчик некую систему самопомощи. И да, с этой системой время обработки инцидентов сократилось (наверное). Но вот со скольки и до скольки - откуда разработчику известно? Обычно неизвестно, потому что таких данных (и доступа к этим данным) у разработчика нет, и не может быть. К этим данным может быть доступ у продуктового аналитика, но поделиться ли он ими с разработчиком - это вопрос.
Но все продолжают натягивать на STAR все роли подряд, не понимая, что у "кодеров" работа тасочки двигать с определенным KPI, а разработчиков нынче мало, стоят они дорого, и проще заменить одного разраба на команду. И бас фактор ниже, и цена на штатную единицу ниже, и работодателю проще заменить человека в системе, потому что вместо богатого набора компетенций нужна одна конкретная.