Был ли опыт работы с шейдерами?

Что проверяют

Для C#-разработчика это почти всегда вопрос про Unity. Интервьюер хочет понять, писали ли вы шейдеры руками, собирали в Shader Graph или только крутили параметры материалов, и понимаете ли, во что это обходится GPU. Следом просят разобрать конкретный эффект и рассказать, как вы его отлаживали.

Как отвечать

Ответ строится на личном опыте, а внутри него стоит показать такие опоры:

• конвейер рендера: Built-in, URP или HDRP. От него зависит всё: surface shaders есть только в Built-in, в URP и HDRP пишут HLSL в блоках HLSLPROGRAM или собирают граф в Shader Graph;
• стадии: вершинный шейдер двигает геометрию (трава на ветру, волны), фрагментный считает цвет пикселя (растворение, контур, освещение). Compute shader для вычислений без отрисовки запускается из C# через ComputeShader.Dispatch;
• связка с C#: свойства задаются через SetFloat и SetColor, идентификаторы кэшируются через Shader.PropertyToID;
• производительность: число текстурных выборок, overdraw у прозрачных объектов, точность half на мобильных, число вариантов от multi_compile и shader_feature;
• инструменты: Frame Debugger в Unity и RenderDoc, чтобы увидеть, что и в каком порядке рисуется.

Рассказ хорошо идёт по схеме: какой эффект был нужен, почему не хватило стандартного материала, как реализовали, что намерили в профайлере. Цифры берите свои, например время кадра до и после.

Если писали мало, скажите прямо: «эффекты собирал в Shader Graph, HLSL читаю и правлю, с нуля писал только простые». Это честнее и сильнее, чем пересказ учебника.

Где спотыкаются

Меняют параметры через renderer.material, не зная, что Unity при этом создаёт объекту собственную копию материала. Копия сама не удаляется, её надо уничтожать вручную, а для общих настроек есть sharedMaterial.

Не понимают варианты шейдеров. Каждое ключевое слово в multi_compile умножает число вариантов, сборка раздувается, а компиляция идёт в разы дольше.

Говорят «писал шейдеры», а на вопросе о разнице вершинной и фрагментной стадии теряются.