Здравствуйте. Меня зовут Николай, я работаю руководителем команды UX дизайна. Ранее я опубликовал статью для нанимающих тимлидов, которые ищут дизайнеров, а здесь я хочу дать некоторые рекомендации UX дизайнерам, которые в поиске работы и общаются с нанимающей стороной.

Эти рекомендации основаны на моем последнем опыте найма и общения с кандидатами, когда в течение 2021-22 годов я рассмотрел более 120 резюме/портфолио и провел 20 собеседований. Надеюсь, вы найдете для себя что-то полезное.

Общий процесс найма

Давайте определим главных действующих лиц, участвующих в этом процессе:

Кандидат (вы): UX дизайнер, заинтересованный в нахождении нового места работы.
Тимлид (я): руководитель UX команды, который ищет себе дизайнера.
Рекрутер: кто занимается поиском кандидатов; сотрудник в компании, занимающий наймом или стороннее рекрутинговое агенство.

Процесс найма обычно состоит из следующих этапов:

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

Далее пройдемся по каждому этапу по отдельности.

Предоставление информации о себе

Резюме

Многие пишут, и я соглашусь, что резюме должно быть кратким, хорошо структурированным и содержащим описание опыта работы, который релевантен желаемой позиции. Все эти пункты очень важны. Как правило резюме сразу внимательно не читают, а быстро пробегают глазами, и если нужные ключевые слова (“релевантность”) быстро и легко не находятся (“краткость” и “структурированность”), то тут всё может и закончится.

Что мне (как тимлиду) было интересно видеть в резюме в первую очередь:

Места работы, где по каждому приведены
- должность,
- название компании,
- срок работы (месяц/год - месяц/год),
- что делали, чем занимались (очень кратко).
Образование:
- учебное заведение, специальность, год окончания.
- дополнительные курсы, тренинги.
Профессиональные навыки: перечисление хард скилов, а также используемые приложения и сервисы. Еще раз сделаю акцент про “релевантность” - важно не количество навыков, а их соответствие вакансии. Более того, чем больше указано технических навыков, которые не нужны в вакансии, чем более вероятней может возникнуть ощущение, что вы больше “везде по верхам”, а не специалист в нужной области. Например, это здорово, что вы еще можете и логотипы и сверстать лендинг, но это же не совсем про UX дизайн.
Портфолио: ссылка, где смотреть работы.

Что мне было не очень важно в резюме:

Перечисление софт скилов: не имеет большого смысла писать, что вы ответственны, коммуникабельны, стрессоустойчивы, нацелены на результат и прочее. Это и так подразумевается, по умолчанию ) И можно упустить во имя краткости резюме.
Описание “что делали, чем занимались” на местах работы, которые были когда-то давно, и если должность тогда уже слабо связана с последними. Например, в настоящее время, в 2023, я руководитель UX команды, а до 1999 года работал полиграфическим дизайнером, и точно сейчас в резюме не буду много расписывать что тогда входило в мои обязанности. Это все про “релевантность”.
Достижения: по моему мнению, их лучше приводить в портфолио (подробнее ниже).

Портфолио

Как можно сделать портфолио удобным для просмотра:

Портфолио доступно онлайн по одной ссылке, а не “по этой ссылке мои работы по UX с прошлой работы, по этой ссылке совсем старые по UI, а здесь над чем сейчас работаю, еще вот тут личный проект”. Множество ссылок очень неудобно при коммуникациях между рекрутером и тимлидом, и что-то легко утеряется. Вовсе необязательно сильно вкладываться в красивое оформление, достаточно собрать все нужное хоть в google doc или notion, желательно “сократить” ссылку и её использовать.
Опять про релевантность: за длительное время работы дизайнером может накопиться много разноплановых работ, но лучше сделать акцент именно на тех работах, которые соотносятся с желаемой позицией. Остальные можно сделать менее заметнее в разделе “еще было и такое”. Не у каждого тимлида есть время выискивать что-то по нужной специализации среди всего множества разнообразных предоставленных работ.
Работы лучше представить как скриншоты с кратким пояснением что вы делали, какой результат был достигнут. Длинные пояснения, которые объясняют всю специфику продукта (например, про веб хостинг или газовую промышленность), наврядли кто-то осилит. Я, как тимлид, больше оценивал по скриншотам насколько комплексный был проект и примерную похожесть типа работ на то, чем придется заниматься у нас.
Не стоит предоставлять работы только как ссылки на сайты, особенно если там требуется регистрация. Сайт может не работать или не открываться по множеству причин, даже может уже и поменяться после вашего ухода с проекта; а еще и регистрироваться я там точно не буду. Лучше сделать несколько наиболее показательных скриншотов.
Не стоит предоставлять работы в Figma, где нужно еще дополнительно зумить и скроллить по всем направлениям. Просмотр работ в таком формате требует дополнительных усилий и очень неудобен. Ссылка на портфолио может быть передана разным людям (например, тимлид захочет показать коллегам не-дизайнерам) и будет печально, если они не смогут посмотреть, потому что “не разбираюсь в вашей фигме”. А я довольно часто получал ссылку, где просто показывается десятки фреймов и “давай дальше разбирайся в этом сам”.
Про описание достижений. Для меня отличным достижением является показатель результата в цифрах, как изменилась какая-либо продуктовая метрика. Например, “увеличилась конверсия на 20%” или “пользователи стали менее довольны на 11%” (понимание, что дизайн не был успешен, тоже считаю достижением). Но “было сделано сотни экранов” не является такого рода достижением, это не результат в продукте.
Достижения, в которых упомянуты деньги (“как результат моего дизайна, в компании увеличилась прибыль на 30%”), скорей всего вызовут дополнительные вопросы как именно вы это посчитали, как отделили свою деятельность от других отделов (маркетинг, продажи).
Описание достижений в портфолио, а не в резюме, делает их более понятными и наглядными, ибо и сама работа приведена тут же (сделали вот это, достигли вот этого). Понятно, что по разных причинам не у каждой работы и проекта могут быть достижения в цифрах.

(ВАЖНО!) Резюме и портфолио являются показателем как кандидат умеет структурировать и предоставлять информацию (входит в основные навыки UX дизайнера). По сути, это тоже дизайнерская работа, по которой оценивают в самую первую очередь, до рассмотрения других работ. Первое впечатление очень важно; и если резюме и портфолио будут плохо понятными и их не удобно смотреть, то можно сразу подумать, что общий уровень кандидата, как UX дизайнера, не высок.

Стоит также учитывать, что первыми (до тимлида) на резюме/портфолио обычно смотрят рекрутеры, у которых глаз не всегда настолько тренирован, чтобы сходу разобраться есть ли нужные навыки, если много не очень понятного текста и используются термины, отличные от заданных в вакансии. А если рекрутеры будут предоставлять на рассмотрение “нерелевантных вакансии” кандидатов, то это считается, что они плохо делают свою работу; им это скажут и они перестанут давать такие “сомнительные” резюме на рассмотрение.

Общение с рекрутером

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

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

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

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

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

Ес��и получен отказ на этом этапе, то важно понимания причины отказа. Хотя бы для того, чтобы исключить ситуацию, когда информация о вас не была получена полностью или не была правильно понята. Например, если в формулировке отказа написано “не увидели таких-то навыков или опыта”, а они на самом деле у вас есть и описаны в предоставленных документах, то возможно где-то произошел сбой в коммуникациях, или эта иформация у вас была недостаточно явно отражена.

Тестовое задание

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

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

Про опасения, что “мою работу из тестового задания потом просто переиспользуют, а меня кинут”. Я не очень представляю как это возможно в UX дизайне. Обычно после изготовления начального варианта дизайна только начинается самое интересное (обсуждение, правки и прочее), и никто не возьмет в разработку что-то “сырое”, сделанное сторонним человеком вечерами после работы. Даже если задание будет “изучи нашу предметную область и наш продукт, возьми нашу дизайн-систему, сделай дизайн такой-то фичи по таким-то требованиям, протестируй на наших пользователях, предоставь описание поведения и детальную спецификацию”.

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

(!) Представление результата задания очень важно. Если его не удобно смотреть, то будет ощущение, что скорей всего и дизайн там сделан “не удобный”.

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

Собеседование с тимлидом

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

Что рекомендую сделать до собеседования:

Почитать про компанию, что она делает, какие продукты выпускает; тем самым вы покажете заинтересованность в работе в этой компании и тимлиду не придется рассказывать всё с нуля (облегчите ему немного жизнь).
Подготовить список вопросов; меня очень печалило, когда я слышал “ну в принципе все понятно, вопросов вроде нет”; не понимаю как их может не быть.
Подготовить истории успеха (как вы круто порешали какую проблему) и неудачи (как все получилось не так как хотелось); что-то подобное могут спросить, и долго думать и в итоге сказать “не могу ничего вспомнить/вроде не было такого” не является лучшим вариантом ответа.

Возможные вопросы, которые можно задать тимлиду (или дизайнерам компании, если они присутствуют на встрече):

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

Помимо наличие нужных технических навыков (хард скилы) на собеседованиях смотрят еще и на софт скилы, потому что они тоже очень важны (а для UX дизайнера где-то и сливаются с хард). И кандидату наврядли явно скажут “а сейчас переходим к проверке ваших софт скилов”, а скорее всего это будет неявно происходить во время всего собеседования. У каждого тимлида могут быть свое понимание какие софт скилы важны в первую очередь. Одни из аспектов, на которые я обращал внимание:

Спокойное отношение к обратной связи/критике; стремление ее понять, а не стараться всеми силами защищать свою работу (“да, возможно здесь можно было сделать по другому, надо подумать”, “упс, тут мой косяк”).
Понимание, что есть куда развиваться (“‘это я не очень хорошо знаю”, “в этом не было опыта”), и как развиваться (совершение каких-то действий).
Нацеленность на результат и чувство ответственности (“так получилось из-за моих (без-)действий, в следующий раз буду делать по другому”).
Четкость изложения мысли.
Желание задавать вопросы и получать ответы.

Принятие решения

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

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

Заключение

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

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

Найм UX дизайнера: советы дизайнеру от нанимающего тимлида