Log of Alprog

AssetLine У меня есть давний интернет-знакомый движкописатель zenkovich (который, в отличие от меня свой движок сделал). В эпоху нейронок он, естественно, тоже не стал использовать существующие инструменты, а стал городить себе свой "движок" по оркестрации нейронок. Это эдакий нодовый редактор, в котором ты выстраиваешь себе пайплайн от промта до готовых ассетов. Ближайший референс ComfyUI, но проще в настройке и заточено под геймдев. То есть из коробки есть ноды для вытаскивания спрайтов, удаления фона и тому подобной базы. Тут пачка примеров и пресетов, можно в них пощупать редактор, посмотреть что assetsline.app умеет: https://assetsline.app/examples Честно, я сам пока ещё глубоко не тыкался: все мои пет-проекты как обычно на паузе сейчас. Но это и не реклама в классическом смысле: пишу пост, потому что знаю чела и он делает нормальные вещи. Если вы инди-девелопер, то сходите хотя бы посмотреть: со старта дается довольно много токенов, хватит чтобы поразбираться и даже сгенерировать ассеты для небольшой игрушки-прототипа. В дальнейшем есть возможность покупать токены на самом сайте, либо прикрутить ключи от собственных ии-подписок.

У меня сейчас в голове борятся две концепции для Crunch House. Общее это то, что у нас есть RimWorld-подобный геймплей, где ты управляешь студией из нескольких человек с разными скиллами. У нас есть мир офиса, где дэвчики обедают и ходят на планёрки, но как только они садятся за комп, они попадают в мир репозитория. Там кодеры физически обрабатывают шестерёночные поля кода, ловят баги; артисты физически в мастерских делают ассеты. А также есть мир игры, куда левел-дизайнеры носят ассеты, строят локации, а тестеры по ним ходят. Не буду сейчас вдаваться в остальные нюансы. Сосредоточимся на различиях. В изначальной концепции мир репозитория представляет собой визуализацию работы системы. Между зданиями проложены дороги, по котором ездят машинки (job system) и перевозят ресурсы. Такой Anno-стайл менеджмент производственных цепочек. Плюс ещё есть река по которой проплывают кадры-корабли. Каждый кадр мы должны загрузить треугольниками, после чего он отправляется вниз по GPU Stream. Нагруженный кадр плывёт дольше. Опционально он ещё по пути должен перевернуть все треугольники в турбулентных потоках от вертексной мельницы и покрасить их вблизи пиксельной красильни. Так или иначе у нас корабли символизируют общий FPS системы, мы видим что тормозит: CPU или GPU, если корабли где-то накапливаются. Но в этой концепции загрузка кораблей становится центральным элементом геймплея. Причём FPS и нагрузка становятся общими для всех тестеров. Либо надо как-то чередовать корабли кадров, или делать какие-то оверлеи (и тогда всё становится запутанным и визуально перегруженным). Во второй концепции я подумал, а что если локации — это здания-павильоны в том же пространстве? Тестеры и кодеры ходят рядом, больше экшена происходит в одном месте. Оверлей тоже можно сделать, но который наоборот скрывает, а не добавляет: репозиторий заменяется на море, а всё что мы видим — это игра в виде островов (чисто на случай если хотим полюбоваться самой игрой). В этой метафоре как будто возникает больше пространственных конфликтов размещения (сама игра vs технические помещения и коммуникация вокруг). И больше упор на людей, которые кранчат, а не на машинки и симуляцию программы. Что думаете? Главная дизайн-проблема у меня сейчас это то, как придать каждой игре уникальность. Чтобы игра была нечто большее, чем просто сумма локаций и ассетов. Есть идея как-то превратить это в пространственный пазл, но не до конца оформленно в голове.

Только что осознал, что прошлый раз, когда я серьёзно озадачивался вопросом создания тайловых текстур, был БОЛЕЕ 20 ЛЕТ назад. Вот эти файлики с тех времён. Когда я сам руками заделывал швы в каком-то примитивном редакторе. И вот мы снова здесь. Всю ночь изучал, чего новенького с тех пор появилось в этой области: читал пейперы, пробовал либы всякие. Нейронки — это, конечно, хорошо; гигантские тулзы для художников — тоже. Но всё-таки хочется удобную тулзу с минималистичным GUI, заточенным под плитку wang'а и API для массовой обработки. Похоже, придётся самому писать.

Я влюбился в геометрическую алгебру 2026 год начался во многом с подтягивания математики. То ли на фоне наступления ИИ-шки меня потянуло на фундаментальные знания, то ли в преддверии моего скорого перехода на движок*, но так или иначе уже пару месяцев как очередное обострение. Они у меня случаются периодически, но в основном я долблюсь в какую-нибудь из балдёжных физик (кванты, космология, СТО/ОТО), ни одной из которых у меня не было в универе, но разобраться очень хочется. В случае с квантами долблюсь обычно не очень успешно, потому что местами не хватает математической подготовки. Один из очевидных пробелов — абстрактная алгебра, который я стал закрывать книгой Чарльза Пинтера. Я, конечно, пока не добрался до алгебр Ли, но дико кайфанул от первой половины книги: теории групп и немножко колец. Интересно, что я учусь вместе с чатомЖПТ, задавая ему вопросы по непоняткам. На типовые вопросы он отвечает прям хорошо: таблицы Кэли рисует, находит подгруппы, факторизует. На более экзотических структурах (лупы, моноиды) люто галлюцинирует, но по основному материалу с таким помощником учиться одно удовольствие. Хз, как будет выглядеть высшее образование через 10 лет, потому что уже даже для тупых вопросов препод-человек не особо нужен. *** Но хватит уже про абстрактную алгебру. Она классная, но не главная в этом посте. Этот пост — признание в любви геометрической алгебре. Моё первое знакомство с ней началось с интерактивной статьи про роторы: Let's remove Quaternions from every 3D Engine. И я не перестаю пиарить её при каждом удобном случае. Серьёзно, почитайте, если ещё не видели — это прям eye-opening. Во многом эта статья вдохновила меня на написание моей статьи про матрицы. Я её, кажется, так и не показывал здесь? Несмотря на то, что я потратил кучу времени на интерактивные иллюстрации и даже выступил с этим докладам на внутренней конфе парадокса, я так и не доделал текстовую версию. Но презентация доступна. Посмотрите что ли. Зря что ли делал? Но в этом году я решил более серьёзно разобраться с геометрической алгеброй по книжке МакДональда. И сказать, что я очарован, это ничего не сказать: она не только сводит dot и cross к одной операции, не только объясняет повороты без привлечения 4D, но и обобщает в целом комплексные числа и кватернионы. Совершенно казалось бы разные вещи из разных разделов математики внезапно сводятся к одному и тому же и выводятся буквально из одной операции. Просто катарсис. Геометрическая алгебра — ты моя Валентинка ❤️ Многие спросят, если она такая крутая, то чё её никто не использует? Почему ни в одном движке её нет? А дело в том, что классическую линейную алгебру тупо знает больше народа. Она появилась гораздо раньше и входит в стандартный университетский курс. Линейная алгебра давно и прочно занимает одно из самых центральных мест в математике (наряду с матанализом), на её языке работает половина науки от квантовой физики до экономики. Геометрическая алгебра, напротив, появилась сравнительно недавно, и это по сути другой язык. И на нём не так уж много материалов для начинающих. Обычно статьи с применением геометрической алгебры уже предполагают, что вы знаете предмет в терминах линейки. Но как же всё становится проще и осмысленнее в геоме. Одним словом, КРАСОТИЩА. И да, я знаю, что это всего лишь алгребра Клифорда, и очарование потом у многих проходит. Но, чёрт возьми, дайте насладиться влюблённостью, я в своей геометрической фазе. *** Разумеется, я ещё по мелочи затыкал более мелкие дыры всякими ютуб-плейлистами на разные темы. Из наиболее существенного: я наконец-то разобрался с дуальным пространством (для этого пришлось немного залезть в тензоры). А ещё было приятно найти видос у 3Brown1Blue, объясняющую формулу эйлера ровно тем же способом, как я её себе объяснял в древнем посте. * — ну и да, если в апреле сдадим крупный майлстоун, то я на годик по обмену схожу в команду движка. А там дальше видно будет.

Ребята из "Пилим, Трём" сняли мини-фильм памяти Кранка. Туда же в качестве бонуса вошло и моё интервью с Андреем 2013 года, которое я упоминал в прошлом подкасте. Кранк был важным человеком в моей жизни. Я пришёл к нему в студию уже опытным разработчиком, но всё равно воспринимал его как своего "геймдев-папу". Посмотрите. Душевное. https://www.youtube.com/watch?v=7Ea9NfH73Ss

DevGAMM Гданьск 2023 Казалось бы, совсем недавно я выступал на DevGAMM в Минске, а на самом деле уже целых 3 года прошло. Ужас просто, как время ускоряется. Так или иначе, мне на днях компания апрувнула билеты, так что в этом году я снова лечу на эту конференцию. На этот раз выступать не буду, в этот раз я обычный посетитель, но вы всё так же можете ловить меня. На этот раз в Гданьске 1-2 марта.

DevGAMM Гданьск 2023 Казалось бы, совсем недавно я выступал на DevGAMM в Минске, а на самом деле уже целых 3 года прошло. Ужас просто, как время ускоряется. Так или иначе, мне на днях компания апрувнула билеты, так что в этом году я снова лечу на эту конференцию. На этот раз выступать не буду, в этот раз я обычный посетитель, но вы всё так же можете ловить меня. На этот раз в Гданьске 1-2 марта.

Приходите слушать подкаст про С++ со мной 12 января Поговорим про прошлое, настоящее и будущее крестов в геймдеве. Согласен, постановка вопроса звучит странно, как будто бы это не дефолтный язык в геймдеве, а какая-то экзотическая штука. Но в такие времена живём. Впрочем, и про это тоже поговорим. По ссылке есть форма, куда можно прислать вопросы для подкаста. https://www.youtube.com/watch?v=pIUymOJtE-E

Когда мы приехали домой, остальные участники уже отстрелялись и ждали результатов, а меня ждали два часа полного унижения. Даже если бы я вышел в интернет (который тогда был, кстати, по карточкам dial-up), мне бы это не помогло. Потому что на листочке с заданиями, который нам дали, были настоящие олимпиадные задачи, и я не имел ни малейшего представления, как к ним подступиться. В итоге я получил только 1 балл за наполовину решённую первую задачу и предпоследнее место в общем зачёте. Это был мощнейший удар по моему эго, когда я узнал, что на самом деле мои навыки программирования полное днище по сравнению с учениками нормальных школ. И тогда же я заработал себе мой первый (и, слава богу, единственный) синдром самозванца. Потому что в универ я поступил только благодаря школьной серебряной медали, и первые пару месяцев боялся, что я там самый дибил. Позже, правда, выяснилось, что это далеко не так. На деле в универе я тоже оказался в числе лучших студентов и кодеров, но след эта история всё равно оставила во мне серьёзный. Возможно, именно поэтому я все эти годы за версту обходил олимпиадное программирование. Декабрьский advent of code фактически первое из этой области, к чему я притронулся с тех пор. Вот такие пироги. А в следующий раз я расскажу про мои обсёры уже из профессиональной деятельности.

Advent of Code 2022 Done! #code Ну вот и закончился Advent of Code. Расскажу про задачки, которые хоть чем-то запомнились: 8. Treetop Tree House. Сама задача не особо примечательная, но я уже после основного решения выпендрился оптимизацией, сделав поиск однопроходным и заюзав intrinsic functions (get_trailing_zeros). 11. Monkey in the Middle. Первая задача, в которой надо было минимально подумать, заглянув в инпут и проанализировав его. Про наименьший общий множитель. Хотелось бы больше такого. 13. Distress Signal. Мудацкая задача со списками, которая легко решается в какой-нибудь динамике типа python или lua, чуть ли не простым eval(), но на крестах задолбёшься только структуры заводить. 16. Proboscidea Volcanium. Пожалуй, самая интересная задача. Нужно было сначала упростить граф + запилить кэширование стейтов тем или иным способом. Плюс во второй части нужно было придумать, как "распараллелить" дерево возможностей. Жалко, что оптимальное решение у слона и человека не пересекается. Можно было ещё усложнить немного. Тем не менее, понравилось больше всего. Классная. 17. Pyroclastic Flow. Неплохая задача про тетрис. Выпендрился тем, что уложил многоэтажные фигуры тетриса целиком в один uint64_t и двигал их влево-вправо простым шифтом. Ну и в стакан зашивал битовыми операциями соответственно. Безумно длинный стакан проблем не вызывает, так как паттерн быстро начинает повторяться, но у меня решение получилось не универсальным. Может быть позже вернусь и наведу красоту. 19. Not Enough Minerals. На эту задачу бомбил больше всего. На первый взгляд похожа на 16, но честно закэшировать стейты не получается. В итоге решается эвристиками отсечения, которые на самом деле не гарантируют правильного ответа. Причём самое подлое, что тестовые данные подобраны хитрые, на которых простые эвристики не работают, но которые вполне подходят для самого паззла. То есть в выигрыше были те, кто раньше забил на тестовый пример и сразу попробовал свои эвристики на основном инпуте. 22. Monkey Map. Максимально душная задача. По началу ничего особенно сложного, но во второй части появляется условие, которое хрен запишешь сколько-нибудь красиво. Получается соревнование на то, кто быстрее сможет это захардкодить под конкретный инпут и при этом не запутается. Я всё равно проспал, поэтому решил решать честно и универсально, на что угрохал весь день. Но под конец уже так преисполнился, что даже объяснение алгоритма на реддит запостил. *** В целом был интересный опыт. Но под конец уже знатно задолбали задачи про регулярные квадратные сетки и ту или иную вариацию поиска на ней. На последней собирался уже в шашлык стрелять, если снова будет сетка. Хотелось бы больше чего-то, где надо именно догадаться, как решать, а не просто аккуратно надолбить условия и поиск в ширину. Участвовать в таком конкурсе на крестах, это, конечно, «‎здоровья погибшим», как говорится; но ни о чём не жалею. Насчёт следующего года не уверен, но может быть поучаствую на питоне, чтобы подучить его наконец-то. И да: всех с Рождеством!

Ну вот и закончился Advent of Code. Расскажу про задачки, которые чем-то запомнились: 8. Treetop Tree House. Сама задача не особо примечательная, но я уже после основного решения выпендрился оптимизацией, сделав поиск однопроходным и заюзав intrinsic functions (get_trailing_zeros). 11. Monkey in the Middle. Первая задача, в которой надо было минимально подумать, заглянув в инпут и проанализировав его. Про наименьший общий множитель. Хотелось бы больше такого. 13. Distress Signal. Мудацкая задача со списками, которая легко решается в какой-нибудь динамике типа python или lua, чуть ли не простым eval(), но на крестах задолбёшься только структуры заводить. 16. Proboscidea Volcanium. Пожалуй, самая интересная задача. Нужно было сначала упростить граф + запилить кэширование стейтов тем или иным способом. Плюс во второй части нужно было придумать, как "распараллелить" дерево возможностей. Жалко, что оптимальное решение у слона и человека не пересекается. Можно было ещё усложнить немного. Тем не менее, понравилось больше всего. Классная. 17. Pyroclastic Flow. Неплохая задача про тетрис. Выпендрился тем, что уложил многоэтажные фигуры тетриса целиком в один uint64_t и двигал их влево-вправо простым шифтом. Ну и в стакан зашивал битовыми операциями соответственно. Безумно длинный стакан проблем не вызывает, так как паттерн быстро начинает повторяться, но у меня решение получилось не универсальным. Может быть позже вернусь и наведу красоту. 19. Not Enough Minerals. На эту задачу бомбил больше всего. На первый взгляд похожа на 16, но честно закэшировать стейты не получается. В итоге решается эвристиками отсечения, которые на самом деле не гарантируют правильного ответа. Причём самое подлое, что тестовые данные подобраны хитрые, на которых простые эвристики не работают, но которые вполне подходят для самого паззла. То есть в выигрыше были те, кто раньше забил на тестовый пример и сразу попробовал свои эвристики на основном инпуте. 22. Monkey Map. Максимально душная задача. По началу ничего особенно сложного, но во второй части появляется условие, которое хрен запишешь сколько-нибудь красиво. Получается соревнование на то, кто быстрее сможет это захардкодить под конкретный инпут и при этом не запутается. Я всё равно проспал, поэтому решил решать честно и универсально, на что угрохал весь день. Но под конец уже так преисполнился, что даже объяснение алгоритма на реддит запостил. В целом был интересный опыт. Но под конец уже знатно задолбали задачи про регулярные квадратные сетки и ту или иную вариацию поиска на ней. На последней собирался уже в шашлык стрелять, если снова будет сетка. Хотелось бы больше чего-то, где надо именно догадаться, как решать, а не просто аккуратно надолбить условия и поиск в ширину. Участвовать в таком конкурсе на крестах, это, конечно, «‎здоровья погибшим», как говорится; но ни о чём не жалею. Насчёт следующего года не уверен, но может быть поучаствую на питоне, чтобы подучить его наконец-то.

Психологическая составляющая на собеседовании вообще важная. Не смотря на то, что ты в начале говоришь, что можно чего-то не знать и это не страшно, половина кандидатов теряется после первого «не знаю». Ты задаёшь новые вопросы на другую тему, а кандидат явно продолжает думать над предыдущим. Приходится дополнительно повторять, что ничего страшного не произошло. Также я всегда в начале делал ремарку, что могу перебивать из экономии времени, если вижу, что человек отвечает в правильном русле (некоторые отвечают хорошо, но прям о-о-очень медленно или концентрируются на несущественных деталях), и что если я останавливаю, то это скорее хороший знак, чем плохой. Но, как правило, после первой остановки приходится это ещё раз объяснить, чтобы человек не переживал. В целом, я старался не подавать виду, если ответы прям плохие и всегда задавал ещё какое-то количество вопросов из вежливости, но не уверен, что умел это маскировать очень хорошо. Когда даже гейм-директор, который присутствовал на всех собесах, вздыхает от ответа про виртуальную функцию, то в целом уже всё понятно. В самом конце, если интервью прошло слишком быстро или впечатление смазанное, я мог ещё спросить что-то практическое. Ну, типа: «на бильярдом столе 10 тысяч шаров, все двигаются и сталкиваются. Как будем оптимизировать?» Здесь не было никаких правильных ответов, это чисто на послушать, как человек рассуждает. Ну ещё мог спросить логическую задачу про червячков в стиле google, но это уже больше кека-ради. Как видите, ничего сверхъественного я не спрашивал. В целом, открытая вакансия висела у нас 1-2 месяца. За месяц я в среднем, наверное, видел штук 10 резюме, штук 5 тестовых и проводил штук 5 интервью. 1-2 человека в итоге получали офер, но не все соглашались или приживались после выхода на работу, поэтому найм иногда затягивался. Цифры очень приблизительные. Ну вот пожалуй и всё, что мне есть рассказать по теме. Пообещайте, что не будете использовать эту схему, как руководство к действию. Она здесь исключительно для удовлетворения любопытства и не претендует на ролевую модель.

Начинал интервью я всегда с объяснения, что чёткого списка обязательных вопросов нет. Что я буду прыгать с темы на тему, что можно чего-то не знать, и можно об этом так и сказать — мы тогда просто не пойдём углубляться в эту тему, а поговорим о чём-то другом. Идея состояла в том, чтобы нащупать общее представление об уровне кандидата в разных сферах (С#, математика, С++, графика). Я называл это методом бинарного поиска. Если представить вопросы по теме в виде линии от простого к сложным, то я задавал вопрос где-то посередине и дальше ориентировался по ответам. Если кандидат отвечает хорошо, то я прыгаю в середину отрезка справа, иначе — влево. И так, в ходе эдакой пристрелки из 5-6 вопросов, становится понятен общий уровень по теме. Секцию C# я почти всегда начинал с вопроса «что такое виртуальная функция?». Разминочный вопрос, на который отвечали практически все, но даже на нём уже видно уровень: кто-то начинает рассказывать, как устроена vtable или рассказывать про производительность в сравнении с обычными функциями, а у кого-то знания ограничены ключевым словом. Далее я старался спрашивать более сложные вопросы, хотя по C# трудно спросить что-то сложное. Чтобы не сочинять каждый раз на ходу и чтобы не повисало пауз, у меня всегда перед глазами был файлик с накиданными заранее вопросами, из которых я уже выбирал. Чтобы пройти на мидла надо было хотя бы отличать стек и кучу, знать в чём опасность float’ов, знать размер байта, отличать Dictionary от List и оценивать стоимость их операций, представлять в общих чертах, как работает GC. Да в общем-то и всё. Бонусные очки давались, если человек может внятно рассказать, как устроены флоаты, хэшмапа, когда и почему происходит boxing. Вторая обязательная секция была математика. Минимальный джентльменский набор здесь это понимание тригонометрии, знание отличий векторного и скалярного произведений, хотя бы приблизительное представление о том, как работают матрицы трансформации. Иногда я также спрашивал примитивный тервер или комбинаторику. Ну типа: «пушка попадает с вероятностью 50%, какова вероятность попасть 3 раза подряд?». Если у человека не хватает интуиции это посчитать без формул, то скорее всего это красный флаг. Иногда также мог спросить чего-нибудь про графы (здесь ничего конкретного не требовалось, но хорошо, если человек содержательно может поговорить за Дейкстру, А* или чего-нибудь такое). Остальные секции по большому счёту были опциональные, но знания в них были большим преимуществом. В первую очередь это, конечно, С++. Тут можно было бы много всякого интересного спрашивать в правой части бинарного поиска: всякие там универсальные ссылки, value-категории, guaranteed copy elision или, прости господи, SFINAE (последнее это очень локальный мем — по случаю передаю привет). Но, к сожалению, так далеко мы ни разу не добирались. Всё-таки вакансия была по C#. Что касается графики, то первым пристрелочным вопросом был «что такое depth buffer?». Далее я мог поспрашивать про освещение и нормали, инстансинг, всякие кулинги, как реализуются тени или какой-нибудь моушн-блюр. Мой любимый вопрос по графике это классический «назовите как можно больше причин, почему экран может быть чёрным?». Но, по-моему, я так ни разу его и не задал (вопрос классный, но его надо задавать чуваку, который не только шарит в графике, но и который чувствует себя уверенно на интервью — иначе перенервничает и поплывёт).

Как я проводил собесы? #light Что ж, давайте я вам расскажу, как я проводил собесы, когда был большой начальник в маленькой студии. Речь про Dark Crystal Games, где я был лид-кодер и ещё формально технический директор. Напомню, что там мы писали тактическую РПГ Encased на Unity. Я отвечал только за техническую часть интервью, поэтому в деталях общей картины могу слегка наврать, но в целом можно сказать, что процесс найма у нас состоял из 4 этапов. Первым делом нужно было откликнуться на вакансию и прислать резюме. Зарплаты мы предлагали ниже рынка в силу того, что были полу-инди студией, но это компенсировалось одним из самых интересных проектов на постсоветском пространстве. Так что основную массу откликнувшихся составляли желающие перекатиться из энтерпрайза или проклятых мобилок в «настоящий» ‎геймдев. В каких-то совсем спорных ситуациях мне показывали резюме уже на этом этапе, но в основном фильтрация производилась без меня нашим проджект-менеджером (он же геймдиректор и ваще главный человек в разработке). Он же сам проводил второй этап, который представлял из себя что-то среднее между первичным скринингом и культурным интервью. Надо сказать, что как любая восточноевропейская студия, мы не особо много внимания уделяли софт-скилам. Вся софтскилловая часть у нас по сути сводилась к ответу самим себе на вопрос: «хочется работать совместно с этим кренделем, или ну его нафиг?». Ну ещё, конечно, любовь к Fallout и релевантным играм давала бонус. Но на этом всё. Я не говорю, что это супер правильно — на западе, например, софтскиллы даже важнее хардов — но рассказываю, как есть. Далее у нас было два технических этапа: техническое интервью и тестовое задание. Тут уже подключался я. Кому-то мы давали оба этапа; но кому-то только одно, если видно, что кандидат годный и нет смысла гонять дополнительно. Иногда мы начинали с интервью, иногда — с тестового. Строгой формулы, как мы это решали, не было: руководствовались по ситуации. Например, если в портфолио дофига примеров кода, то тестовое не просили. А если чувак с явно хорошей теоретической базой, но мало опыта в геймдеве, то такого посылали сперва на тестовое. Тестовое я придумал в самом начале проекта и мы его использовали до самого конца. Нужно было сделать 3D-леталку на самолётике от третьего лица. Требовалось реализовать только управление (повороты, ускорение), выпускаемые ракеты, врагов-мишени и интерфейс в виде индикаторов расстояния до них. Разрешалось делать на кубиках или бесплатных ассетах, красота не оценивалась. Я когда-то писал такое на хакатоне, поэтому к тестовому прилагалось видео, как это может выглядеть. Изначально я написал, что задача рассчитана на 3 вечера (из расчёта 6-9 часов), но на деле большинство кандидатов делали за 2-3 часа. В поздних версиях мы также начали делать приписку, что нельзя использовать юнити-корутины и ригидбоди, чтобы кандидаты хотя бы реализовали работу с DeltaTime и проверками расстояния, а то совсем порой оценивать было нечего. Оценивали мы наличие кодстайла и здравого смысла. То есть достаточно было не натворить какой-то лютой дичи, чтобы пройти. Под дичью я имею в виду магические константы, нейминг транслитом, баги и тому подобное. Оценивали мы толпой прямо в канале code в слаке. Делали это в домашней атмосфере, не снимая токсичные тапки. Что тоже не очень профессионально, потому что любопытные сотрудники могли проскролить чат достаточно далеко и почитать не всегда супер-политкорректные формулировки. Благо, это могли видеть только прошедшие кандидаты. Наконец последний этап (который обычно был до тестового) — это техническое интервью. Я неоднократно упоминал статью «интервью глазами пострадавшего», как свой ориентир по собеседованиям. Собственно, я им и руководствовался, но занизил планочку, как мог, под современные реалии.