Вопросы на собеседовании для программистов компьютерной графики

Kate

Administrator
Команда форума
Прим. переводчика: в данной статье обсуждается общий подход к выбору вопросов для собеседований на позицию программиста компьютерной графики на примерах конкретных вопросов.
Недавно я видел в твиттере довольно много дискуссий о хороших и плохих вопросах на интервью. Некоторые из этих вопросов выглядят полезными.
В основном, наиболее интересные из них выглядят открытыми. Они могут привести к весьма большим и разветвленным обсуждениям или даже не имеют «‎верного» ответа. В конце концов, вам, скорее, нужно не узнать ответ (он всё равно будет 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?

Вам нужно хранить и рисовать большой город. Как бы вы это сделали?​

Этот вопрос я не использовал, но видел его упоминание в твиттере. Звучит как отличный вопрос, потому что он не имеет верного ответа и затрагивает много вещей.
Создание, процедурная генерация, запекание, изменения в реальном времени, хранение, стриминг, пространственные структуры данных, уровни детализации, перекрытие видимости, рисование, освещение и так далее. Много-много возможных обсуждений.
Ну, вот и всё.
Стоит сказать, что прошло много времени с тех пор, как я сам собеседовался… Так что я не знаю, так ли полезны эти вопросы для соискателей, как мне кажется.

 
Сверху