Как подготовиться к презентации портфолио на уровне мировых продуктовых компаний (Facebook, Apple, Google)

Первая часть — про то, как выбрать проекты и уверенно рассказать про то, что хочет услышать нанимающая сторона. Вместо тестового задания [1] в ведущих продуктовых компаниях есть продуманный процесс собеседований, который начинается с живой презентации портфолио и рассказа об опыте работы. 9 из 10 кандидатов не проходят дальше первого этапа презентации. Этот этап сложнее, чем кажется на первый взгляд.

Этот текст ориентирован на дизайнеров с опытом больше трёх лет.

Чтобы влезть в 30 минут, нужно нарезать свои кейсы как можно мельче — вплоть до юзерсторей[2], и сначала натренироваться рассказывать про них.

Выбрать только те проекты, где вы можете ОДНИМ предложением сформулировать проблему пользователя. Это важно! Одно предложение проще понять нанимающей стороне, и вам будет проще объяснить своё решение и мыслительный процесс.

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

Ваш рассказ про дизайн должен строиться на решении проблемы пользователя. В финале нужно показать, как вы проверили что она решена — например, привести результаты А/Б-теста, было/стало, или изменения в поведении пользователей (например, после внедрения новой фичи).

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

Вручную или в Ноушене оценить свои проекты — это гемор, поэтому я сделал простой инструмент и инструкции, где удобно самостоятельно оценивать свои проекты. Я его разработал для тех, кому помогал готовиться к собеседованиям для работы в США и Европе, но принцип универсален.

Работает просто:

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

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

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

[1] — На западе в развитых продуктовых компаниях мирового уровня редко кто попросит «сделать тестовое», потому что туда обычно набирают экспертов с подтвержденным опытом работы больше трёх-пяти лет. Считается, что опытных людей тестировать на знание азов дизайна — бессмысленно, нужно посмотреть на боевой опыт работы (поэтому презентация). Плюс, много формальных/юридических нюансов, и это занимает слишком много времени с кучей неоднозначных факторов. Навык решения задач проверяется на следующих этапах — упражнениями Whiteboarding и App Critique (ссылки ведут на видео).

[2] — User story. Формат записи задачи: «Я, как [username], хочу [что хочет], чтобы [решить проблему]». Отсюда понятно — кто целевой пользователь, как должен работать дизайн, как поймем про проблема решена. Фича может состоять из пачки юзерсторей, например авторизация в приложении может состоять из входа, восстановления пароля, регистрации, подтверждения почты и т.п., это всё отдельные юзерстори.

[3] Вопросы подобраны так, чтобы сфокусировать дизайнера только на важных для собеседования вопросах. Четыре группы: 1) продуктовое мышление, 2) скиллы (не считая навыка работы в проф. программах), 3) платформы — круто, если дизайнер запускал фичи на разных платформах, и 4) готовность кейса — есть ли что показать на презентации.

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