Upjers Senior 3D Programmer interview questions

Das erste Interview war sehr positiv, aber das technische Feedback war enttäuschend und oberflächlich Zunächst möchte ich betonen, dass mein erstes Gespräch mit dem Team professionell, konstruktiv und respektvoll war. Auch wenn ich kein deutscher Muttersprachler bin und mein Deutsch nicht perfekt ist, war das Gespräch per Video sehr angenehm. Die Kommunikation verlief offen und freundlich und ich fühlte mich willkommen. Für diese positive Erfahrung bin ich dankbar. Gerade deshalb war das anschließende Feedback zur technischen Aufgabe umso enttäuschender. Das technische Feedback war sachlich falsch und oberflächlich Obwohl die Position als Senior Developer ausgeschrieben war, lässt das Feedback zur Testaufgabe vermuten, dass der Reviewer entweder den Code gar nicht gelesen hat oder technisch nicht in der Lage war, diesen fundiert zu beurteilen. Hier die Details: 1. “Grid Cells mit einzelnen GameObjects und individuellen Materialien – ineffizient” Diese Aussage ist faktisch falsch. Das Feedback suggeriert, dass ich für verschiedenfarbige Zellen (Pfad und Umgebung) unterschiedliche Materialien verwendet habe. Das stimmt nicht. Ich habe keine separaten Materialien eingesetzt. Stattdessen habe ich einen eigenen HLSL Shader (InstancedUnlitBaseColor) implementiert, der Farbänderungen über GPU Instancing abbildet – mit per-Instance Properties, sodass das komplette Grid (Pfad + Umgebung) mit nur einem Draw Call gerendert wird. Das lässt sich eindeutig im Unity Profiler erkennen: Das Grid benötigt genau 1 Batch, die gesamte Szene lediglich 8 Batches. Ein solcher Fehler im Feedback zeigt eines von zwei Dingen: • Entweder wurde der Shader gar nicht geöffnet und der Code nicht gelesen, • Oder der Reviewer hat nur flüchtig in die Szene geschaut und voreilige Schlüsse gezogen. Beides ist nicht akzeptabel für ein Review auf Senior-Niveau. 2. “Kein GPU Instancing, keine Static Flags gesetzt” Auch das ist nachweislich falsch. • GPU Instancing ist aktiviert bei allen relevanten Materialien, Türme, Gegner, Haustiere. • Static Flags sind für dynamische Objekte wie Türme und Gegner nicht relevant. 3. “Platzierung im Editor nicht per Maus steuerbar” Hätte der Reviewer im Unity Editor einfach unter „Simulate Touch Input From Mouse or Pen“ aktiviert, hätte er gesehen, dass sich Türme ganz einfach per Maus-Klick oder Drag-&-Drop platzieren lassen – ohne jegliche Codeänderung. Auch hier zeigt sich: Entweder wurde das nicht getestet, oder es fehlt an Kenntnis über grundlegende Unity-Funktionalitäten. 4. “Riesiger EnemyPool, ohne klaren Bezug zum tatsächlichen Bedarf” Der EnemyPool wird als zu groß kritisiert, ohne Verständnis für den technischen Hintergrund: • Die Aufgabe erwähnte Gegnerwellen, aber es gab keine konkreten Angaben zur Anzahl der Gegner pro Welle, Spawnrate oder Schwierigkeitsverlauf. • Ich habe den Pool bewusst großzügig dimensioniert mit Blick auf ein Worst-Case-Szenario (32 Gegner) und um GC-Overhead durch Instantiate/Destroy zu vermeiden. • Die Poolgröße (PoolSize) ist vollständig konfigurierbar über Inspector, JSON oder ScriptableObject. Fazit Das Feedback war technisch oberflächlich, teilweise falsch und hat sich offensichtlich nicht ernsthaft mit dem Code befasst. Ich habe weit mehr geliefert als gefordert: mit modularer MVC-Struktur, Data Binding, Editor-Erweiterungen, reaktiver UI, GPU Instancing und Mobile-Optimierung und nichts davon wurde überhaupt erwähnt. Es wirkt, als hätte der Reviewer die Szene kurz angeschaut, ein paar optische Annahmen getroffen und keine Zeile Code gelesen. So bewertet man keine Senior-Kandidaten. So baut man kein Vertrauen mit erfahrenen Entwicklern auf. Ich bin weiterhin dankbar für das respektvolle Erstgespräch. Aber wer ein Auswahlverfahren professionell beginnt, sollte es auch mit technisch fundierten, fairen und sorgfältigen Code-Reviews beenden.