Бэкендер на Go: почему «ключевые навыки» никому не нужны и как уместить весь опыт на одной страничке

Мы много разговариваем про найм, и решили запустить новую рубрику — разбор резюме. В ней наши профессиональные HR, которые регулярно просматривают сотни резюме, будут смотреть на присланные CV специалистов и советовать, что в них можно улучшить. Делать мы это будем именно с точки зрения HR-специалистов: они расскажут, что именно их бы оттолкнуло, а что — привлекло. Начнем с резюме бэкендера и дальше пойдем по другим профессиям.

Здесь нам прислали сразу два резюме: одно совсем старое, и обновленное, с которым человека недавно взяли на работу. Разберем оба, потому что и во втором есть что улучшить.

Сразу покажем резюме и посмотрим, что с ним не так:

Здесь заблюрены имя и фамилия для анонимности. Ниже указана должность, но она слишком бледная и тонкая, хотя по идее должна сразу бросаться в глаза. Если выделить ее ярче, будет гораздо удобнее. Кроме того, должность написана несколько абстрактно. Просто «Back-end Developer» — недостаточная информация для HR. Лучше сразу указать технологию, например, «Back-end Developer Go».

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

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

Пользы от этого блока в таком виде нет никакой: HRы не обращают внимания на эти общие слова. Плюс «ключевыми» для разработчика все-таки считаются другие навыки — а это скорее софт-скилы, которые в общем-то обязательны для всех.

Если очень хочется перечислить здесь что-то вне знания технологий, можно упомянуть:

Все это будет куда полезнее, чем абстрактные слова о творческом мышлении и коммуникабельности.

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

Хорошо, что они лежат на серой плашке и выделяются на общем фоне.

На самом деле рекрутеры смотрят в первую очередь не на них, а на опыт работы. Потому что написать сюда можно что угодно, и знания свои каждый оценивает сам по неясным критериям. Кто-то посмотрел видео на ютубе по Docker — и пишет, что он в нем разбирается. А кто-то два года работал с Kubernetes и все еще его не упоминает, потому что не уверен в своих силах.

В профессиональных навыках стоит указывать какие-то действительно важные вещи. Например, опыт работы в системе Git — это, конечно, навык, но практически обязательный, упоминать который не нужно. То же касается ООП и структур данных — такое стоит указывать, только если навыков в списке пока мало и вы новичок. Тут лучше больше писать о конкретных языках, технологиях и библиотеках.

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

Коммерческому опыту работы в таких местах лучше отдавать приоритет. Если опыта совсем мало и вы претендуете на должность джуна, можно вписать фриланс и собственные проекты. Но если это уже джун+, и тем более мидл — фриланс можно вообще не упоминать. Компании в первую очередь интересует именно ваша работа в других компаниях, в команде, с корпоративными требованиями и совместным написанием кода — и для них важно только это.

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

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

В опыте работы лучше сразу в подзаголовке указывать язык, на котором вы работали. Это позволит сразу понять, насколько опыт релевантный. А вот фраза «highload back-end» звучит довольно абстрактно: непонятно, насколько он высоконагруженный и кто его так обозначил. Лучше ниже упомянуть, какие именно были нагрузки и в чем заключался этот самый highload.

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

Еще до нашего вмешательства разработчик сам исправил свое резюме и привел его вот к такому виду:

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

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

Уже даже такие незначительные корректировки помогли с этим резюме получить в итоге работу. Если исправить еще больше: скорректировать список профессиональных навыков, заменить абстрактные ключевые навыки софт-скилами и сделать упор на бизнес-пользу в опыте — это сделает резюме намного более привлекательным в глазах рекрутера.