Здравствуйте. Меня зовут Николай, я работаю руководителем команды UX дизайна. В последнее время я активно занимался наймом новых дизайнеров к нам к команду, и в этой статье я хотел бы поделиться своим опытом, рассказать о тех методах и приемах, которые нам помогали вести найм более эффективно.

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

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

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

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

• Кандидат: UX дизайнер, который заинтересован в вашей вакансии.

• Тимлид: это я, руководитель команды, в которую ищется новый дизайнер.

• Дизайнеры команды: сотрудники уже работающие в компании.

• Рекрутер: кто занимается поиском кандидатов; либо сотрудник в вашей компании, занимающий наймом, либо стороннее рекрутинговое агенство.

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

• Тимлид предоставляет рекрутеру информацию о вакансии для кандидата.

• Рекрутер ищет кандидатов и предоставляет информацию о них тимлиду.

• Тимлид рассматривает кандидатов и решает давать ли тестовое задание.

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

• Если техническое собеседование успешно пройдено, то назначается финальное собеседование. 

• Если финальное собеседование успешно пройдено, то кандидат приглашается на работу.

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

Информация для кандидата

Описание вакансии

Описание моей вакансии состояло из следующих разделов:

• Кто мы: краткое описание компании, чем она занимается, что делают продукты.

• Кого мы ищем: общее название самой позиции; в моем случае это было “ищем UX дизайнера для проектирования веб интерфейсов продуктов и сервисов, разрабатываемых в компании”.

• Чем предстоит заниматься: перечисление видов дейтельности на этой позиции; у меня это включало “проектировать прототипы интерфейсов для веб приложений; проводить пользовательские исследования, usability тестирования; развивать существующую дизайн-систему”.

• Что ожидаем от вас: требования к навыкам и опыту; например, нам нужен был дизайнер выше миддла и со знанием английского языка минимум intermediate.

• Что у нас есть, что мы предлагаем: перечисление используемых в работе инструментов и продуктов; про медицинскую страховку, возможности обучения, другие реально важные аспекты (не про печеньки в офисе).

• Зарплата: указание количества денег конечно же очень важно; я давал в формате “от стольки-то”, а не “до стольки-то”, чтобы не было ощущения, что ни при каких условиях зарплата не может быть больше.

• Важно знать перед тем как откликнуться на вакансию: здесь я привел описание того кем мы не являемся и чем не предстоит заниматься, чтобы у кандидатов было более полное понимание о том, что же мы имеем в виду под UX дизайном у нас в компании. В частности, здесь было написано, что мы не ищем графического или UI дизайнера; что не надо будет дизайнить сайты, лендинги и рисовать иконки; дизайна мобильных приложений не будет; мы не дизайн-агенство, где часто новые проекты.

Появление этого последнего “Важно знать” раздела вызвано тем, что было много откликов от дизайнеров других направлений, не UX в нашем понимании. Возможно, потому что термин “UX” воспринимается по разному и есть некоторая путаница (например, в профиле на Хабр Карьере на момент написания этой статьи в профессиональных навыках “UX” приведен вместе с “UI”: “UI/UX дизайн”). 

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

Подробнее о нас

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

Привожу здесь одну из последних версий "О нас" документа (google docs). Его основные разделы:

• Приветствие: с моей фоткой; кандидат же обычно присылает резюме с фото и тимлиду незачем скрываться до собеседования.

• Что важно знать заранее: некоторые аспекты, на которых хочется особенно обратить внимание кандидата; пересекается с подобной информацией из описания вакансии.

• Компания и продукты: о компании, ее история; описание что делают наши продукты, для чего и кем они используются.

• Команда: структура всего департамента, какие в нем команды; состав UX команды, почему ищем дизайнера.

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

• Мои контакты в соцсетях, чтобы задать вопросы (или просто добавиться в linkedin, что было намного чаще).

Для создания документа я выбрал Google Docs, чтобы можно было просто и быстро вносить изменения; что я иногда делал прямо во время собеседования, когда мне задавали вопрос, и я понимал, что ответ возможно интересен не только этому кандидату. Таким образом этот документ еще и сильно экономил мне время на собеседовании (об этом ниже).

В своем фидбеке кандидаты отмечали, что документ в целом был полезен и снимал многие вопросы. “Видно, что писал не маркетинг или HR” - это для кандидатов тоже важно. Поэтому рекомендую такие материалы писать самим тимлидам, несмотря на то, что возможно будет не так красиво изложено, как бы это сделали профессионалы по написанию текстов. 

Рассмотрение информации о кандидате

Резюме и портфолио

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

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

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

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

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

Анкета 

Анкета довольно простенькая, можно сделать хоть в Google Forms. Основные вопросы в ней были следующие:

• Оцените ваши умения/навыки по шкале от 1 (ничего не умею) до 5 (умею всё) по каждому из необходимым нам навыков:
  

  • Навыки UX дизайна интерфейсов веб-приложений.

  • Навыки проведения пользовательских исследований.

  • Навыки проведения юзабилити тестирований.

  • Знание технологий, используемых в разработке веб-сайтов, веб-приложений.

• Как вы использовали эти навыки в своей работе (на текущем или на последних местах работы).

• Оцените ваше знание английского языка по шкале от 1 (ничего не знаю) до 5 (знаю всё):
  

  • Написание

  • Устная речь

  • Чтение, перевод

• Как вы использовали английский язык в своей работе (на текущем или на последних местах работы).

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

• Ожидаемая зарплата.

• Любые комментарии/пожелания/вопросы.

Почему такие вопросы:

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

• Выставленные оценки по навыкам используются для предварительного анализа их уровня и в дальнейшем при обсуждении на собеседовании.

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

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

• Явно указываем какие именно типы работ в портфолио нас интересуют.

• Про зарплату спрашиваем, чтобы проверить, что ожидания кандидата попадают в нашу “вилку”.

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

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

Если после анализа ответов у меня появлялись сомнения, то я их явно обозначал в ответе кандидату: “мы предлагаем вам сделать тестовое задание, но я вижу риск в том-то; поэтому сами решите хотите ли вы продолжать с нами”. Примеры таких рисков:

• Невысокая самооценка по ключевому навыку и отсутствия описания опыта его применения - “возможно у вас недостаточно опыта, а нам нужен опытный дизайнер”.

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

• Ожидания по зарплате слишком высокие - “такую сумму сразу не дадим, будет меньше”.

• Любые другие, основанные на резюме и ответах в анкете - от “карьерный рост до руководителя отдела в течении года ну очень маловероятен” до “мы не будем помогать с визовыми вопросами при релокации в Японию”.

Предварительная встреча

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

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

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

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

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

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

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

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

Формулировка задания

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

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

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

• Предварительный отбор кому дать тестовое - я, тимлид.

• Решение и фидбек по результату тестового - дизайнер (большое спасибо, Стас).

• Техническое собеседование - вместе.

Чем стоит руководствоваться при формулировке тестового задания:

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

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

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

• Задание не должно быть объемным. Многие кандидаты же работают, поэтому могут заниматься тестовым только в свободное время. По вашим оценкам, на выполнение должно быть достаточно 1-2 недели, по несколько часов в день. Не стоит определять дедлайны и ограничивать по времени. Пусть кандидаты берут столько времени сколько им надо, чтобы достигнуть желаемого качества результата. Если случится ситуация “на работе был завал/ребенок болел всю неделю, а вы мне сказали, что надо прислать в понедельник, поэтому вот что успелось за ночь”, то скорей всего по такому результату вы не определите есть ли нужные навыки. 

Пример нашего задания (без указания конкретной тематики):

Спроектируйте приложение для <таких‑то людей в такой‑то ситуации>:
- опишите основные кейсы использования приложения,
- соберите прототип решения для одного‑двух основных кейсов,
- сделайте финальный дизайн для одного‑двух экранов.

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

Мы ожидаем, что в процессе выполнения задания в какой‑то мере будут применены основные необходимые на этой позиции навыки (от исследования до тестирования).

Часть презентации своей работы надо будет сделать устно на английском языке.

Оценка результата

“Скажите, правильный ли у меня получился результат вашего тестового задания?” 

Нет ответа на этот вопрос. Мы оцениваем сам подход и процесс дизайна, использованные знания, навыки и методы, а не насколько лично нам понравился итоговый дизайн. И у каждого кандидата результат свой и нельзя сказать какой более “правильный”.

Учитывая основные требования по нашей вакансии (дизайн веб интерфейсов, пользовательские исследования, юзабилити тестирование) и сформулированные ожидания в задании, для нас критерии успеха были следующие:

• Проведено пользовательское исследование.

• На его основе определены основные кейсы (или сценарии/джобы).

• Изготовлен кликабельный прототип для показа как эти основные кейсы выполняются.

• Проведено пользовательское тестирование этих кейсов.

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

• Это всё описано и приведено в удобной и понятной форме.

Если эти аспекты присутствовали в результате выполнения тестового, то приглашали на собеседование.

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

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

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

Иногда после нашего фидбека кандидаты решали что-то переделать в задании, или дополнить его.

Собеседование

Было два этапа собеседований:

1. Техническое: обсуждение навыков, хард скиллов; проводили совместно я (тимлид) и  дизайнер.

2. Финальное: общие и организационные вопросы; проводил я один.

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

Общие рекомендации

• У собеседования должен быть четкий план с таймингом. Какая тема обсуждается, в каком порядке, и сколько времени на эту тему. Если плана нет, то скорей всего получится сумбурная (возможно очень приятная, по душам) беседа, и по ее окончании сложно будет сделать вывод, принять решение и потом объяснить его кандидату.

• К каждому собеседованию надо готовиться, и предварительно составить список вопросов для обсуждения; а не читать резюме или смотреть портфолио во время собеседования в поисках “что бы еще спросить”.

• Если ведете беседу не один, то четко определите роли между собой. Чтобы не перебивать друг друга и не вмешиваться в подготовленную последовательность вопросов коллеги. В нашем плане это было прямо прописано у каждой темы (например, “Коля говорит вступительную часть, потом Стас задает все свои вопросы, а Коля свои потом”).

• Строго следить за таймингом и модерировать встречу. При необходимости мягко прерывать и давать понять о времени. Конечно во время беседы можно договориться о увеличении длительности собеседования, но это лучше делать в середине беседы, а не за 5 минут до планируемого окончания. Не должно получиться, что на самые главные вопросы у вас остаётся мало времени. Вообще больше двух часов это тяжеловато; особенно для кандидатов, как правило, они же говорят большую часть беседы.

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

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

• Все заметки и мысли важно зафиксировать сразу после беседы, но какое-то решение принимать чуть позже. Лучше немного “остыть” и попытаться спокойно все взвесить. Сразу после беседы может быть некая эйфория, что вы наконец-то нашли нужного кандидата и надо срочно сегодня брать. Особенно если вы в поисках уже не один месяц.

• По окончании встречи озвучить кандидату дальнейшие шаги: когда будет решение, что будет в случае “да” (еще одно собеседование или уже приглашение на работу), что будет в случае “нет” (объяснение отказа).

• В общем, на каждое собеседование надо приходить с определенным планом, чтобы понять подходит ли вам кандидат, и уходить с тем, что вам поможет решить это для себя. Если беседа не помогла это решить, то это было просто хорошее общение и наврядли можно назвать успешным собеседованием.

Техническое собеседование

Проводили вместе с нашим дизайнером; состояло из следующих частей и обсуждаемых тем/вопросов:

• Вступление 
  

  • Знакомство; small talk про погоду.

  • План собеседования: о чем оно (про навыки, хард скилы), из каких частей состоит

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

• Результат тестового задания (40 мин)
  

  • Фидбек от кандидата по заданию (было сложно/легко, интересно/скучно); сколько времени заняло.

  • Самооценка результата от 1 до 5; что хорошо получилось, а что стоит доработать? что помешало сделать на 5?

  • Краткая презентация (5 мин) результата устно на английском.

  • Вопросы про использованные методики: выявление и приоритизация проблем/кейсов; тестирование и проверка гипотез; понимание насколько дизайн успешен.

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

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

• Навыки (30 мин)
  

  • Обсуждение оценок по навыкам из нашей анкеты (от UX дизайна интерфейсов веб-приложений до английского языка). По каждому из навыков: почему такая оценка в анкете? чего не хватает до 5? что делаете чтобы достичь 5? что последнее делали/узнали? как навык был применен при выполнении тестового задания?

  • В процессе обсуждение оценок мы также задавали приготовленные нами вопросов по каждому навыку. Ниже приведены примеры таких вопросов.

  • UX дизайн: опыт использования или разработки дизайн-системы; три главных неудобства работы в Figma, какие еще фичи там нужны; что делать когда заказчик говорит “мне не нравится”.

  • Исследования и тестирование: какие методы когда лучше применять. 

  • Знание веб технологий: опыт создания вебсайтов; знание html.

  • Английский язык: как поддерживаете форму.

• Текущее место работы (15 мин)
  

  • Как в общем построен дизайн-процесс на текущем (или последнем) месте работы.

  • Какие команды/люди принимают участие; откуда приходят задачи, кто принимает финальное  решение по дизайну, как оно принимается.

  • Как проводится сбор и обработка обратной связи, исследования и тестирования; как часто (в месяц) этим занимаетесь; если редко, то что мешает.

  • Опыт совместной работы с другими коллегами-дизайнерами.

  • В общем оценка дизайн-процесса от 1 до 5; кто и что должен сделать, чтобы стало 5? какой был бы идеальный процесс при наличии всех необходимых ресурсов?

• Вопросы к нам (15 мин). Раньше я дополнительно тратил время (15-20 мин) на рассказ про что и как у нас устроено, какие процессы, что делают продукты, но потом это заменил “О нас” документ (см. выше), и кандидаты уже приходили с конкретными вопросами, а не послушать всё с нуля.

• Тест на знание английского (10 мин). Уровень устного был виден при презентации результата тестового, а здесь я смотрел на чтение/перевод и написание. Просил в заранее подготовленном документе прочитать вслух тест на английском и перевести вслух на русский, и потом письменно перевести текст с русского на английский (прямо вживую вводить перевод в документ).

• Заключение: спасибо за встречу, было приятно пообщаться; решение будет в такой-то срок; если после встречи возникнут вопросы, то задавайте.

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

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

Главное, на что обращали внимание: 

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

• Мы не задавали вопросы типа “объясните разницу в использовании между чекбоксом или радиобатонами” или “как в Figma работать с компонентами”, т.к. не считали это сильно важным. Если даже такого рода знаний недостаточно, то их не так сложно приобрести и развить. Важнее было убедиться в наличии навыков, которые прокачать сложнее всего: “правильное”, логическое дизайн мышление и софт скилы (которые для UX дизайнера сложно отделить от “хард”).

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

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

На основе этих отзывов тимлид принимает решение продолжать дальше с этим кандидатом или нет.

Финальное собеседование

Проводил я один; cостояло из следующих частей и обсуждаемых тем/вопросов:

• Вступление 
  

  • И снова здравствуйте, рад еще раз вас видеть.

  • План собеседования: о чем оно (общие вопросы), из каких частей состоит.

  • Что будет по его окончании и какие возможные дальнейшие варианты (“да” или “нет”).

• О нас (15 мин)
  

  • Что было самое интересное и полезное было в "О нас" документа; что не хватило и стоит добавить.

  • Рассказать что делает компания и ее продукты.

  • Впечатление от продукта по его онлайн демо (ссылка была в “О нас” документе); что понравилось, что не понятно и в первую очередь стоит улучшить; почему считаете, что этим продуктом и направлением вам интересно заниматься.

• Тестовое задание (10 min): учитывая обсуждения на техническом собеседования, расскажите что в тестовом было сделано хорошо, что не очень и стоило сделать по другому.

• Вопросы по STAR (30 мин): изначально пытался вместить в техническое собеседование, но по времени никак не влезало. 
  

  • Расскажите о ситуации, когда вам удалось добиться успешного результата, несмотря на сложности и препятствия.

  • Расскажите о ситуации, когда вам не удалось достичь нужного результата.

  • Расскажите о ситуации, когда вы инициировали изменения в работе или в продукте. К чему это в итоге привело?

  • Расскажите о ситуации, когда вам очень что-то хотелось поменять в своей работе, но по каким-то причинам это не удалось сделать.

• Общие вопросы (20 мин)
  

  • Образование; как попали в дизайн; чем привлекает эта профессия.

  • Почему меняли работу ранее, какие причины; почему меняете сейчас.

  • Как активно ищете работу; есть ли предложения на рынке.

  • Сколько времени надо на уход с текущего места; как к этому отнесется команда и руководство.

  • Какие жизненные планы; куда собираетесь расти.

  • Как происходит профессиональный рост; что именно делаете, что последнее изучено.

  • Почему есть интерес работать у нас, чем привлекает наша вакансия.

  • Требования по зарплате.

• Вопросы ко мне.

• Заключение: спасибо за встречу; когда будет решение.

Наиболее важные для меня качества, которыя я хотел проверить, были:

• Интерес к продукту; были ли приложены усилия для понимания чем мы занимаемся.

• Склонность к рефлексии; признание своих ошибок, принятие ответственность за совершенные действия, кто виноват в неудачах.

• Ориентация на результат, инициативность.

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

Тоже и про профессиональный рост: если кандидаты читают какие-то статьи/книги, то обсудите последнее, что они читали, что наиболее полезное почерпнули.

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

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

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

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

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

После финального собеседования не надо принимать решение больше чем несколько дней. Если вы в ближайшее время не решили для себя, что “да”, то скорей всего потом будете себя уговаривать пойти на уступки. Ответ кандидату лучше дать в течении недели. Я отказался от ответа “нам надо еще время подумать”, а отвечал сразу “нет”. Мне кажется, так честнее чтобы не оставлять кандидата в подвисшем состоянии долгое время. Если у вас ситуация поменяется, то всегда можно вернуться к этим кандидатам и объяснить почему.

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

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

Заключение

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