Хабрахабр

Резюме глазами интервьюера

Когда я составляла свое первое резюме, процесс отбора на очное интервью мне казался магией. Люди, принимающие решения, представлялись «черными ящиками», которые определяют: кандидат «интересен» или «неинтересен» — по непонятным критериям.

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

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

В этой статье я хочу рассказать:

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

А главное — хочу объяснить логику, которой мы руководствуемся, чтобы процесс больше не выглядел магией.

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

image

Структура резюме

Стандартное резюме состоит из следующих блоков:

  • ФИО, контактные данные, желаемая позиция (опционально — возраст);
  • опыт работы;
  • образование;
  • дополнительная информация, которую вы хотите сообщить.

Чтобы испортить часть, касающуюся ФИО и желаемой позиции, надо здóрово постараться. Поэтому обратимся сразу ко второму блоку.

Опыт работы

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

Вариант 1. Минималистичный

image

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

Скажем, если вы работали в Google, то, в принципе, можете больше ничего не писать, на это «клюнут» многие работодатели. Хорошо, если «Рожки да ножки» — всем известная ИТ-компания. В противном случае, стоит указать больше информации.

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

Вариант 2. С указанием технологий

image

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

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

Но все же хотелось бы знать, какие конкретно задачи вы решали.

Вариант 3. С указанием обязанностей

image

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

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

Вариант 4. С указанием достижений

image

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

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

Вот несколько идей: Сомневаетесь, что считать достижениями?

  • внедрил TypeScript (ES6, юнит-тесты, код-ревью, code style и т. д.);
  • оптимизировал загрузку сайта;
  • сформировал команду, осознанно выбрал фреймворк;
  • организовал внутреннее обучение (митапы, походы на внешние конференции);
  • выступил на митапе, конференции.

Этот список можно продолжать. Но дам еще один совет. Помните притчу про три сита, через которые надо пропустить то, что хочешь сказать? Так вот, достижения стоит пропустить через сито адекватности.

А потом выясняется, что отдел состоит из вас и вашего друга Пети. Например, вы пишете, что руководите отделом фронтенд-разработки. Или приводите малозначимые факты: за время работы написал 30 тысяч строк кода, закрыл 125 тикетов, отревьювил 1500 пулл-реквестов. Выглядит так себе.

Если посмотреть на распределение последних полученных нами резюме по указанным категориям, мы увидим такую картину:
image

Как минимум 28 из 100 резюме можно было бы существенно улучшить.

Но если вы даже не стараетесь рассказать о себе — как ваши потенциальные коллеги заметят вас среди других кандидатов? Хочу заметить, что плохо подготовленное резюме не всегда означает менее подходящего кандидата, как и наоборот: автор прекрасного резюме может не пройти техническое собеседование или не сработаться с командой.

Проблемы при указании опыта

Иногда у человека достаточно лет опыта, но, читая резюме, мы все равно думаем, что это «не наш кандидат». Что может быть не так?

Частая смена работы

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

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

Опыт в нерелевантных технологиях

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

Или вы разрабатывали бэкэнд, а теперь хотите переквалифицироваться во фронтендера. Мы ищем Angular- и React-разработчиков (но часто готовы рассматривать и разработчиков с опытом в других фреймворках), а в резюме, например, только блоги на WordPress. Пройти собеседование по новой специальности может быть непросто. Я и сама была в такой ситуации несколько лет назад и понимаю, какие проблемы вас ждут: опыт разработки есть, но практического опыта в веб-разработке нет.

Поднять лапки кверху и смириться? Что делать? Конечно же нет. Продолжать делать то, что вы уже успели разлюбить? Переходим к следующему разделу.

А если мало опыта?

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

Саморазвитие

Если вам не хватает знаний смежных или более современных технологий, начните изучать их сами. Пройдите видеокурсы, сейчас их много на любой вкус (я люблю Pluralsight, но можно найти и бесплатные видео прекрасного качества). Напишите о желаемом пути развития и своих усилиях в резюме — например, в разделе «Дополнительная информация» или в сопроводительном письме. Например:

Прошел такие-то курсы. На текущем месте работы мы не используем фреймворки, но я слежу за современными технологиями и изучаю Angular (React, Vue — здесь ориентируемся на свои интересы и желаемое место работы).

Если вы указываете 50 курсов, начиная от верстки и заканчивая оптимизацией запросов к БД, это выглядит странно (если только вы не fullstack). И снова без фанатизма! Подумайте, чем на самом деле вы хотите заниматься и чего вам сейчас не хватает.

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

Pet-project

Допустим, вы проходите или уже прошли какое-то обучение: посмотрели курсы, прочитали книгу или статьи. Вы, конечно же, понимаете, что такой «теоретической» подготовки недостаточно. Я всегда советую по мере просмотра видео или чтения книги отрабатывать новые знания на практике. Например, завести pet-проект.

В принципе, что угодно. Что это может быть?

Сделайте сайт о предстоящем чемпионате. Вы увлекаетесь футболом? Напишите приложение для повторения слов. Изучаете иностранный язык? Сделайте карту мест, где вы были. Любите путешествовать? Например, неплохой список API вы найдете в репозитории public-APIs. Есть множество открытых API, данные которых можно использовать.

Хороший код скажет о вас больше, чем тысяча слов, а в некоторых случаях избавит от тестового задания. Кроме закрепления изученного материала pet-проект дает еще одну интересную возможность: его можно выложить на GitHub и дать ссылку на ваш профиль в резюме. Но убедитесь, что ваш GitHub не свидетельствует против вас.

Ваш профиль на GitHub

Несколько раз мне попадались резюме, автор которых указал ссылку на GitHub (что само по себе очень здóрово и выделяет резюме в глазах потенциальных интервьюеров), но просмотр кода напрочь отбивал желание общаться. Вот самые простые причины, почему так может произойти:

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

И это только те code smells, которые сразу бросаются в глаза, еще до того, как я спуллю код. Кстати, очень удобно, если ваш проект где-то развернут и можно посмотреть демо, не запуская у себя. Простейший вариант — github pages.

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

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

Ресурсы для практики

Pet-проект — история про создание проекта с нуля, работу с фреймворком, с API. В общем, это нечто напоминающее реальный проект в миниатюре. Кроме работы над pet-проектом советую практиковаться в решении задач на написание кода. Это особенно важно для джуниор-разработчиков или разработчиков, меняющих специализацию (например, при переходе с C# на javascript), — так можно набить руку и привыкнуть к новым конструкциям.

Мои любимые — Codewars и LeetCode. Есть много сайтов с подходящими задачами и автоматической системой проверки.

Вообще этот совет больше касается саморазвития и подготовки к интервью, чем написания резюме.

Образование

С образованием все просто: либо оно есть, либо его нет, просто пишем правду. Если вы проходили дополнительное обучение, прямо или косвенно связанное с работой, также стоит это указать. В моем случае это, например, курс UX&UI Design, пройденный в Британской высшей школе дизайна.
Недавно меня спросили, насколько важно в принципе иметь высшее образование для работы в ИТ.

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

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

Дополнительная информация

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

  • чем интересуетесь и в какую сторону хотите развиваться (можно написать, что для вас особенно важен UX или что вам нравится менторить менее опытных коллег);
  • дать ссылку на GitHub или портфолио;
  • рассказать о ваших статьях или выступлениях;
  • объяснить, что, хоть у вас и нет опыта в определенной технологии, вы готовы ее освоить и что-то делаете для этого (см. раздел «А если мало опыта?»);
  • рассказать о любых других достижениях (в олимпиадном программировании, решении бизнес-кейсов и др.).

Вы спросите: «А что насчет стандартных формулировок „стрессоустойчив“, „легко обучаем“ и подобных определений, которые все еще можно подсмотреть в примерах резюме?» На меня они не производят никакого впечатления, и я искренне не понимаю, почему их все еще используют. В конце концов, мы не предполагаем по умолчанию, что кандидаты особенно подвержены стрессу, да и некомфортных ситуаций в команде стараемся избегать.

Выводы

В заключение приведу несколько идей, которые я хотела донести этой статьей:

  • В резюме подробно опишите свой опыт: укажите технологии, основные задачи и ваши достижения, если они есть.
  • Если опыта не хватает — учитесь сами и покажите это потенциальному работодателю.
  • Для практики заведите pet-проект.
  • Опубликуйте его на GitHub, чтобы показать пример кода, который вы пишете.
  • Если указываете GitHub в резюме, доведите код до совершенства.
Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть