Прим. переводчика: в данной статье обсуждается общий подход к выбору вопросов для собеседований на позицию программиста компьютерной графики на примерах конкретных вопросов.
Недавно я видел в твиттере довольно много дискуссий о хороших и плохих вопросах на интервью. Некоторые из этих вопросов выглядят полезными.
В основном, наиболее интересные из них выглядят открытыми. Они могут привести к весьма большим и разветвленным обсуждениям или даже не имеют «верного» ответа. В конце концов, вам, скорее, нужно не узнать ответ (он всё равно будет 42), а увидеть процесс решения проблемы и/или оценить общие знания и понять собеседуемого.
Ниже я приведу примеры, которые я использовал несколько раз, и они ориентированы на программистов графики с некоторым количеством опыта.
Когда GPU семплирует текстуру, как он выбирает MIP-уровень, из которого нужно читать?
Хорошо, этот вопрос имеет верный ответ, но он всё ещё может привести к обширным обсуждениям. Правильный ответ на сегодняшний день примерно такой:
GPU растеризует всё блоками 2x2, считает разницу по вертикали и по горизонтали между фрагментами блока и использует величину этой разности, чтобы выбрать MIP-уровень, который наиболее близок к соотношению 1:1 между фрагментами и текселями.
Если соискатель не знает ответа, вы можете попытаться вывести его. «Итак, если бы вы создавали GPU или писали программный растеризатор, что бы вы делали?».
Многие люди начинают с идей «базирующихся на расстоянии до камеры» или «основанных на том, насколько большой треугольник на экране» и так далее. Это отличный первый шаг (примерно так растеризаторы и работали в действительности в прежние времена). Вы можете принять вызов, вбросив следующий вопрос: “а что если UV координаты не вычисляются в вершинах?”. Это, конечно, сделает неприменимыми предложенные методы и нужно будет придумать что-то ещё.
Когда же вы придёте к решению с фрагментными блоками 2x2, вы можете продолжить дискуссию на эту тему (или сразу перейдите сюда, если соискатель знает ответ). Какие последствия влечет за собой такое решение для разработки программ, эффективности и т.д.? Возможные темы для обсуждения:
Для квада 2x2 инструкции шейдера должны выполняться вместе и одновременно, только в этом случае разница между UV-координатами может быть вычислена. Это приводит к некоторым последствиям для ветвлений, обычное семлпирование может быть запрещено (HLSL) или его результат будет не определён (GLSL), когда оно используется в ветке кода с динамическим ветвлением.
Одновременное выполнение может привести к разговору о том, как вообще работает GPU. Что такое wavefront, warp, SIMD (или как это называется в API/GPU, который вы предпочитаете). Как работает ветвление, как хранятся временные переменные, как оптимизировать загрузку, как работает скрытие задержки и т.д. Можно потратить много времени, чтобы это обсудить.
Растеризация квадами 2x2 является неэффективной для маленьких треугольников (треугольники, которые занимают один фрагмент, всё равно требуют 4 выполнения шейдера). Какие это имеет последствия для высокой плотности геометрии, тесселяции, созданию LOD (уровней детализации) для геометрии.
Вы разрабатываете систему освещения для игры/движка. Какой она будет?
Здесь нет «верного» ответа. Система освещения может быть какой угодно. Есть как минимум несколько десятков обобщённых методов сделать её и, возможно, миллионы специализированных подходов! Освещение охватывает множество вещей: точечные, площадные источники света, освещение от окружения, эмиссивные поверхности; предпосчитанные и вычисляемые в реальном времени компоненты освещения; направленное и глобальное освещение; тени, отражения, рассеивающие среды; соотношение между производительностью в реальном времени и производительностью при настройке, требования платформ и многое другое. Разговор может выйти долгим.
Тут вы заинтересованы в следующем:
Общий процесс мышления и подход к открытым проблемам. Стараются ли соискатели прояснить требования и пробуют ли сузить круг вопросов? Говорят ли, что они знают, чего не знают, и что требует дальнейшего исследования? Предлагают ли они единственную любимую технику и не могут предоставить никаких её недостатков?
Осведомлённость в существующих решениях. Знают ли соискатели принципы работы, достоинства и недостатки популярных техник? Пробовали ли какие-то из них? Насколько актуальны их знания?
Знание проблемной области и принятие решений. Это система освещения для одной очень специфической игры или она должна быть «применима для всего»? Как это повлияет на возможные выборы, и каковы последствия этих выборов? В частности, как делать выбор в зависимости поддерживаемых платформ, минимальных требований, ожидаемой сложности контента и других факторов?
Отношение к компромиссам. Почти все инженерные решения их включают. Выбирая тот или иной путь разработки чего-либо, вы приходите к компромиссам. Это может быть производительность, удобство использования, расширяемость, доступность на разных платформах, сложность реализации, влияние на рабочий процесс, количество того, что нужно изучить, и так далее. Понимают ли соискатели эти компромиссы? Знают ли они достоинства и недостатки различных техник и понимают ли их?
Вы разрабатываете графический API для движка. Как бы он выглядел?
Так же как и с вопросом о системах освещения выше, тут нет одного верного ответа.
Этот вопрос проверяет осведомленность в проблемной области (консольные графические API, «современные» API такие, как DX12, Vulkan, Metal, более старые API: DX11, OpenGL, DX9). Что нравится и не нравится в существующих графических API (тревожный знак, если всё устраивает: идеального API не существует). Что бы поменяли если бы была возможность?
И вновь компромиссы. Что предпочтительнее, производительность или удобство использования? Можно ли иметь и то, и другое (если «да», то почему и как? если «нет» — почему?). Можно ли сузить требования в зависимости от того, кем будет пользователь? Будет ли предложенная абстракция работать эффективно на нижележащих API?
Вам нужно хранить и рисовать большой город. Как бы вы это сделали?
Этот вопрос я не использовал, но видел его упоминание в твиттере. Звучит как отличный вопрос, потому что он не имеет верного ответа и затрагивает много вещей.
Создание, процедурная генерация, запекание, изменения в реальном времени, хранение, стриминг, пространственные структуры данных, уровни детализации, перекрытие видимости, рисование, освещение и так далее. Много-много возможных обсуждений.
Ну, вот и всё.
Стоит сказать, что прошло много времени с тех пор, как я сам собеседовался… Так что я не знаю, так ли полезны эти вопросы для соискателей, как мне кажется.