Заметки о резюме в геймдеве

На gamedev.ru пользователь AlexeyLarin создал тему с интересными вопросами о резюме программиста в геймдеве. Я ответил на форуме, а тут приведу развёрнутые версии ответов.

Я слегка поправил вопросы, чтобы соблюсти стилистику блога.

Что показывать, если делали на работе 5 лет убийцу скайрима, а он не вышел?

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

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

Если не задумывались, вы будете в состоянии написать полезную статью о решённой интересной задаче. Это может быть обзор принятых подходов к решению или пересказ конкретно вашей реализации. В идеале с демо-проектом на github. NDA такие вещи не запрещает, если это не эпичное ноу-хау; если это оно, то у вас нет проблем с резюме.

Если вы не решали сложные задачи на проекте, то несущественно насколько проект был крут. Условно говоря, без разницы где вы 5 лет xml парсили: в убийце Скайрима или в no-name движке для онлайн магазинов.

Что писать, если занимались вещами, которые не показать в портфолио: оптимизация, исправление ошибок, архитектура, тестирование? 

Главное — писать правду. 

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

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

Конечно, всегда можно нарваться на неадеквата, но зачем устраиваться в компанию с такими собеседующими :-)

Есть ли смысл писать, что знаете Unreal и С++, если хотите работать с Unity и C#?

Любые топовые библиотеки, движки, фреймворки из одной предметной области похожи. 

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

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

Нужно ли писать про знание других языков, не относящихся к вакансии?

Если это именно знание, а не «писал лабы в универе», «сделал 1.5 туториала».

Например, если вы плюсист, но для проекта писали скрипты сборки и утилиты на Python, то Python нужно писать. 

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

Также имеет смысл писать о языках и технологиях, которые не знаете, но хотите попробовать. 

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

Есть ли смысл делать портфолио из гиперказуалок, которые делаются по две недели?

Смотрите следующий ответ.

Нужны ли в портфолио гиперказуалки, если хотите делать игры под Steam?

Наличие любого законченного проекта — огромный плюс. Часто не так важен тип проекта, как его наличие. Особенно, если он выпущен, а не лежит мёртвым грузом.

Специально делать много проектов смысла нет — достаточно одного «показательного». 

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

При этом всё равно необходимо выделить один или пару проектов, которые лучше всего демонстрируют ваши способности. Тут работает вариант правила 20/80.

Есть ли смысл расписывать механики игры или достаточно ссылки на неё?

В большинстве случаев достаточно ссылки. 

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

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

Например:

  • Если я буду ссылаться на Сказку, то сделаю краткую вводную в суть геймплея, упомяну генерацию карты, текста и квестов.
  • Если же буду ссылаться на Order of War, то обойдусь ссылками на википедию и steam.

Есть ли смысл делать резюме на несколько страниц со списком всего что делали, всех технологий, которые знаете?

В резюме указывают главные карьерные вехи, основные технологии, ключевые навыки. Оно должно быть такого размера и такой структуры, чтобы с ним было удобно работать. То есть 1-3 страницы хорошо структурированного текста.

Если есть желание написать подробно, делайте сайт-визитку и там хоть войну и мир публикуйте. Как у меня :-) В резюме, соответственно, размещаете ссылку на сайт.

Частая ошибка — мешанина уровней абстракций в технологиях и ролях.

Например, если вы senior разработчик, то нет смысла отдельно упоминать JSON и XML. Ваша компетенция уже предполагает, что вы либо знаете эти штуки, либо быстро с ними разберётесь. Если вы писали на модных веб-фреймворках, то отдельно упоминать про REST смысла нет.

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

Мешанина терминов в резюме — признак непонимания уровней абстракции разработчиком.

Пример идеального резюме

Резюме бывают очень разные. Более того, идеальное резюме пишется под конкретную организацию. Поэтому универсального шаблона нет.

Но вот моё резюме от 2015 года. Считаю его симпатичным.

Можно ли требовать тестовое задание и не давать о себе другой информации, о своих навыках и опыте?

Можно всё, что угодно. Но зачем?

Сообщая информацию о себе, вы экономите и своё и чужое время. 

Экономия чужого времени — это проявление уважения. Вы же хотите проявить уважение к своим будущим коллегам?

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

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

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

Во втором случае, конечно, лучше не брать человека. Но если очень надо, то ТЗ всё покажет.