Упрощаем написание резюме разработчика08.01.2019 12:02

Проблема

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

Для тех, кому не интересна лирика, и кто хочет сразу перейти к делу — то вперед на github. А для тех, кому важна механика и история проекта — собственно и посвящена статья.

С появлением специализированных ресурсов биржы труда, таких как LinkedIn, HeadHunter и др., казалось бы, ситуация должна была улучшиться — заполняем весь опыт в одном месте, и больше прошлое не ворошим. Но не тут-то было — заполнили в одной системе, нельзя просто по клику мышки выгрузить ее в другую. Нету единой БД, на которую можно линковать свою учетную запись. Оно и понятно — подобные компании заинтересованы вытеснить других, а не заниматься интеграцией друг с другом, а простым кандидатам в итоге становится только хуже.

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

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

В теории проблему можно было бы решить, имея 'единый центр' — если:

все площадки для размещения и отклика вакансий объединятся на уровне ресурса / единого протокола;
'как писать резюме' перестанет быть вопросом искусства и исследований, а будет единый принятый всеми стандарт;
будет единая онтология наиболее популярный вакансий, по которой можно понять характер оценки навыков/опыта/качеств кандидатов для данной вакансии;
кандидаты не будут врать и преувеличивать в своих резюме;
конкуренция кандидатов по умению продавать себя отсутствует.

В реальном мире такое вряд ли возможно, поскольку биржи труда развивается децентрализовано, а про 4–5 пункты, наверное, невозможно решить даже с единым центром.

Но все-таки что-то сделать можно, чтобы упросить жизнь кандидату, а именно — себе. И я попробую это сделать.

Идея

Так или иначе, резюме:

описывает качества кандидата;
доказывает это опытом.

Различные биржи труда дают немного разные возможности для доказательной базы, где-то есть отдельные поля для публикаций, где-то возможность детального описания проектов, и.т.д. Т.е. все целевые узлы информационной цепочки берут немного разную проекцию реального опыта и создают определенную надстройку для собственных инструментов (поиск по навыкам, автоматические рекомендации и др.). Тогда имея максимально полное описание своего опыта, можно относительно легко создавать эти проекции в зависимости от конкретных требований. В том числе для составления резюме.

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

В проекцию попадает лишь часть данных, и если в простейшем случае это простая печать под форму, то в наиболее сложных — это фильтр данных, релевантных вакансии (выделение проектов с ключевыми навыками, больше печатного места актуальному опыту и др.).

В идеале такой «журнал» должен:

только дополняться, старые записи остаются без изменений;
заполняется при появлении новой релевантной информации (окончание работы на текущем месте, новая публикация, завершенный проект) — именно так можно будет дать наиболее удачное описание;
содержать информацию, выставляющую кандидата в выгодном свете (но, помимо этого, есть смысл отмечать важные для себя моменты, даже если они негативные — в печать пойдет только то, что нужно).

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

Моя история

Начинал я как все, открывал MS Word, искал красивый шаблон, начинал писать. Искал примеры, пытался удачно скопировать. В какой-то момент перешел на LaTex, более-менее структурировал опыт. Перебрал разные визуальные формы, экспериментировал с формами. Это длилось примерно 10 лет, и, наконец, пришло время количеству перерастать в качество.

Во время последнего поиска работы я более-менее отточил форму и подачу материала, но количество опыта уже заставило серьезно думать над максимальным сжатием информации. Было введено много декораций, которые не только хорошо смотрелись, но и позволяли избегать объемного текста. Что более важно — пришло понимание ORM модели самого резюме (достижения-проект-навыки-работодатель).

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

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

Составление резюме как подача истории

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

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

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

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

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

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

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

Навыки. Требования к навыкам вполне однозначны к конкретным вакансиям. Если ищут опытного C++ для разработки драйверов, а в топе навыки JS, Ruby on Rails и Java — то дальше можно не читать.

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

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

Профессиональная активность. Помимо опыта работы, кандидаты, по-настоящему увлеченные профессией, не ограничиваются обычной работой и хобби-проектами, а также занимаются наукой, ведут блоги, делают популярные публикации, делают доклады на специализированных конференциях. Поэтому здесь даю в первую очередь, научные публикации (в приоритете — индексируемые в Scopus), затем популярные (например, как эта статья), и на последнем месте — выступление на конференциях. Этот пункт является скорее дополнением, и не является обязательным и 'точкой отсечения'.

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

Как выделять навыки

Что такое 'навыки', и какая детализация нужна при заполнении — это вопрос открытый. Например, где-то можно написать C++, где-то boost (и при этом не написать C++), а где-то C++, STL, boost. И при этом иметь в виду одно и то же.

Стоит понимать, что рекрутеры и HR-ы редко имеют техническую специальность, и тем более опыт. А значит, что для них может быть далеко не очевидно, что STL и boost включает в себя C++. Поэтому здесь нужно ориентироваться в первую очередь на вакансии, и смотреть какие там используются ключевые слова.

Для себя при заполнении журнала я решил заполнять подробней (пусть даже со смысловым дублированием), а потом я надеюсь добавить «фильтр» релевантных навыков на основании вакансии.

Опыт в виде журнала

Журнал представляет собой профиль кандидата, и может быть представлен в виде следующей схемы. Я укажу у сущностей только основные атрибуты, а для обозначения связей воспользуюсь нотацией ActiveRecord для повышения читаемости.

Далее рассмотрим подробнее описанные сущности с примерами, а в качестве языка реализации воспользуемся JSON-ом.

С персональными данными все достаточно тривиально, как и с контактами. Разве что владение языками помещаются сюда, т.к. в отличии от трудоустройства в России это не конкурентное преимущество, а средство общения. И если рекрутер вам звонит, то пусть он понимает сразу на каком языке начинать диалог.

В образование помещается учебное заведение, статус диплома (phd, specialist, master, etc.), название диплома, период обучения и средняя оценка. Также считаю полезным поместить специализацию для широких профилей, и название диплома.

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

В проекте, помимо продолжительности, размера команды и описания я всегда предпочитаю дать web-ссылку на представляющий его интернет-ресурс. Также я по возможности даю логотип для декорирования, поскольку лично для меня сильно упрощается навигация по резюме, и текст становится менее однородным. Проект является наиболее важной структурной единицей вашего опыта, и в качестве примера

{
  "name" : "Photoshop",
  "icon" : "photoshop_project.png",
  "period" : "01.09.2015-30.08.2016",
  "description" : "Raster graphics editor",
  "team-size" : "9",
  "web" : "https://www.adobe.com/products/photoshop.html",
  "tasks" : [
    "..."
  ]
}

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

{
  "description" : "Development of text-recognition filter from raw image",
  "period" : "01.09.2015-28.02.2016",
  "skills" : ["CI", "C++", "ML"],
  "achievements" : [
    "achievied recognition accuracy up to 85%"
  ]
}

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

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

Публикации, Конференции и черты являются тривиальными ни с чем не связанными сущностями, поэтому я не буду уделять им излишнего внимания. Публикации (как научные, так и научно-популярные) хранятся в виде bibtex файлов.

Реализация

Всю реализацию с сопутствующем описанием можно найти на github.

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

Для работы нужен docker, но если с этим проблема, то главное поставить imagemagick, latex и python.

FROM ubuntu:latest
RUN apt-get -qq update && DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends build-essential librsvg2-bin lmodern inkscape zip python3 python3-dev python3-pip libcairo2-dev apt-utils pkg-config python3-setuptools texlive-fonts-recommended texlive-latex-extra dvipng texlive-latex-recommended texlive-xetex && pip3 install --upgrade pip

Резюме собирается в PDF формат с помощью Latex-a. Для логотипов можно использовать векторные (svg) или растровые (png) изображения с альфой. Шрифт — Arial Narrow, который популярен в резюме из-за своей ширины.

Навыки

Отдельного внимания в этом проекте я уделил визуализации навыков, поскольку именно по ним идет основной фильтр кандидатов. Из того что я встречал, можно выделить следующие подходы:

группированный список с градациями (эксперт, новичок);
таблица (сетка — градация / навык);
замешивание навыков в проекты;
дополнение предыдущих пунктов опытом в годах в скобках.

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

Более того — собственная оценка своего уровня (новичок/эксперт) не несет большого конструктива. Пять лет назад я считал свой уровень C++ значительно выше, чем считаю сейчас, хотя за это время многократно вырос в этом направлении. Единственная объективная оценка, которую я могу дать своему навыку — это сколько времени я его использовал. Это и легло в основу реализации данной секции.

Но как же оценить этот временной отрезок? Я помню, что первую программу на C++ написал в 7 м классе, а последний раз что-то писал сегодня. Ведь неправильно же отнять от своего возраста 13 лет и написать результат в опыт — ведь были временные отрезки, когда я ничего не писал, и навык не рос.

Но зато я могу перечислить проекты, в которых я использовал C++, и могу отметить их продолжительность, что, собственно, уже и сделано в журнале. Причем если я работал одновременно над двумя проектами, в которых использовался C++ — то навык не растет с двойной скоростью. А это уже легко посчитать исходя из журнала и вывести статистику.

А глядя на такую статистику HR уже может быстро сориентироваться — подходите ли вы на вакансию или нет. Более того, мне и самому интересно иногда посмотреть на свою статистику — так ли я опытен, как мне казалось, и наоборот.

Как это выглядит

Все в совокупности выглядит вот так:

Для статьи специально привожу версию на A5 формате, по умолчанию же компилятор настроен на A4.

Обратная связь

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

Я также делал проект из расчета на позиции Software Engineer / Software Developer, поэтому понятия не имею, насколько мои наработки пригодны для других позиций. Но не исключаю, что это возможно.

Куда двигаться дальше

Дальнейший план развития весьма тривиален, правда включает в себя нетривиальную реализацию:

Реализовать умную компрессию. Давать минимум информации на старые проекты, максимум — на актуальные и релевантные. Сейчас это реализовано только для отсечения старых публикаций, но они и так занимают немного места. Нужно соблюдать лимиты объема и не нарушать правила жанра.
Реализовать фильтр релевантной информации. В простейшем случае создается онтология навыков с профилями (embedded, C++, fintech, front-end и др), и профиль является параметром для компилятора. В идеале — даем ссылку на вакансию (пусть это страница на linkedin), компилятор в простейшем случае ищет на ней ключевые слова или анализирует с использованием БД/ML и фильтрует релевантные навыки и проекты.

А пока, всем добра и удачи с поиском работы!