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

На 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 года
• [актуальное](absolute:/ru/cv} — добавил ссылку в 2021 году.

Считаю их симпатичными.

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

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

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

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

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

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

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

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