Senior .NET Backend Developer — .NET-Interviewfragen

Was ist der Unterschied zwischen Workstation- und Server-GC, und wann stellst du daran etwas ein?

Workstation-GC führt Collections auf dem Thread aus, der sie ausgelöst hat, und ist auf niedrige Pausenzeiten für UI-nahe Workloads getrimmt; Server-GC betreibt einen Heap und Thread pro Core, bevorzugt Durchsatz und ist für ASP.NET-Core-Apps in den meisten Hosting-Szenarien der Standard. Concurrent (Background) GC lässt Gen-2-Collections neben der App laufen, auf Kosten von etwas Durchsatz. Mit dotnet-counters und dotnet-trace schaust du dir Collection-Raten und Pausenzeiten an, bevor du an irgendeiner Einstellung drehst — blindes Tuning tauscht ein Problem gegen ein schlimmeres.

Welchen Trade-off geht Native AOT gegenüber dem klassischen JIT-kompilierten Deployment-Modell ein?

Native AOT kompiliert vorab zu einer eigenständigen nativen ausführbaren Datei — kein JIT-Warmup, nahezu sofortiger Start, kleinerer Footprint, was bei Containern zählt, die auf null skalieren, oder bei Functions, wo Cold Start die entscheidende Metrik ist. Der Preis ist, dass Runtime-Reflection, dynamische Codegenerierung und manche Drittbibliotheken, die auf JIT-Semantik aufbauen, entweder brechen oder explizite Trimming-Annotationen brauchen, und der Build ist plattformspezifisch. Es lohnt sich für einen latenzsensitiven Service mit einem bekannten, AOT-kompatiblen Dependency-Graphen, nicht als Standard für jedes Projekt.

Wie gehst du das Containerisieren und Deployen eines ASP.NET-Core-Service in Produktion an?

Ein Multi-Stage-Dockerfile baut im SDK-Image, published und kopiert nur das Ergebnis in das reine ASP.NET-Runtime-Image, was die Image-Größe deutlich senkt und das SDK aus der Angriffsfläche heraushält. Konfiguration kommt aus Umgebungsvariablen und einem Secrets Manager — Azure Key Vault, AWS Secrets Manager — nie fest ins Image gebacken. In Produktion zählen Graceful Shutdown über IHostApplicationLifetime, Health-Check-Endpoints für den Orchestrator und strukturiertes Logging, das irgendwohin geht, wo es durchsuchbar ist, mehr als das Dockerfile selbst — denn docker logs bei einem toten Container ist keine Debugging-Strategie.

Ein Junior in deinem Team liefert einen Service aus, der jeden Test besteht, aber unter Produktionslast in Timeouts läuft. Wie leitest du die Untersuchung?

Fang bei dem an, was sich zwischen Produktion und Tests unterscheidet — meist Nebenläufigkeit und Datenvolumen, die ein standardmäßig einsträngiger xUnit-Lauf komplett verschleiert. Ziehe dotnet-trace oder APM-Daten heran, statt zu raten, denn „fühlt sich nach der Datenbank an" ist der Weg, Stunden zu verlieren; Thread-Pool-Starvation durch Blockieren auf asynchronem Code (.Result oder .Wait() innerhalb eines Requests) sieht identisch aus wie eine langsame Query, bis du wirklich hinschaust. Nach dem Fix ist es wertvoller, daraus etwas zu machen, das das Team automatisch prüfen kann — eine Analyzer-Regel oder ein Punkt auf der Review-Checkliste —, damit dieselbe Bug-Klasse nicht zweimal ausgeliefert wird.

Wie entscheidest du, ob eine Migration einer Legacy-.NET-Framework-Anwendung auf modernes .NET sinnvoll ist?

Geh von dem aus, was dich tatsächlich blockiert — reines Windows-Hosting, eine End-of-Life-Bibliothek oder eine echte Performance-Grenze —, denn eine Migration um ihrer selbst willen verbrennt Monate, ohne das Produkt voranzubringen. .NET Framework und modernes .NET unterscheiden sich am stärksten bei Web Forms, WCF und einigen reflexionslastigen Bibliotheken, für die es keinen sauberen 1:1-Ersatz gibt — die eigentlichen Kosten liegen in der Inventur genau dieser Stellen, nicht im Gros des gewöhnlichen ASP.NET-MVC/Web-API-Codes. Der inkrementelle Weg — Alt und Neu laufen hinter einem Reverse-Proxy nebeneinander, Migration Route für Route — liefert fortlaufend Wert, statt das Team für mehrere Quartale in eine Neuentwicklung ohne sichtbares Ergebnis bis zum Schluss einzufrieren.