FR
RU
EN
ES
ZH
DE
PT
AR
HI
Entretien avancé en C# : comment impressionner l'employeur sans échouer
\n\nUn entretien pour un poste de développeur Senior ou Middle .NET ne se limite pas à une simple vérification de la syntaxe. Les recruteurs veulent voir une compréhension approfondie du fonctionnement interne de la plateforme, la capacité à écrire du code performant et à prendre des décisions architecturales. Dans cet article, nous analyserons les sujets et questions clés de niveau avancé qui vous aideront à réussir un entretien technique en C#.
\n\n1. Programmation asynchrone : async/await et Task
\n\nC'est sans doute le sujet le plus populaire lors des entretiens. Il ne suffit pas de dire que vous connaissez async/await. Vous devez comprendre comment cela fonctionne sous le capot.
Question : Qu'est-ce que SynchronizationContext et comment influence-t-il l'exécution de await ?
\nUne question classique. SynchronizationContext est une abstraction qui permet de planifier l'exécution du code dans un contexte spécifique (par exemple, dans le thread UI de WPF ou dans le pool de threads d'ASP.NET). Lorsque vous utilisez await, après la fin de l'opération asynchrone, le code tente par défaut de revenir au contexte d'origine. Dans les applications console, il s'agit du pool de threads, tandis que dans l'interface utilisateur, c'est le thread du dispatcher. Comprendre ce mécanisme permet d'éviter les blocages.
Question : Quelle est la différence entre Task.Run et Task.Factory.StartNew ?
\nÀ première vue, ils se ressemblent, mais Task.Run est une enveloppe simplifiée. Task.Factory.StartNew offre plus de contrôle (par exemple, vous pouvez définir TaskCreationOptions ou TaskScheduler). Cependant, par défaut, Task.Run utilise TaskScheduler.Default (le pool de threads), tandis que Task.Factory.StartNew peut utiliser le planificateur actuel, ce qui peut parfois entraîner un comportement inattendu.
// Exemple de blocage dû à SynchronizationContext (dans une application UI)\npublic async Task<string> GetDataAsync()\n{\n var result = await SomeAsyncMethod(); // capture du contexte\n return result.ToString(); // tente de revenir au thread UI\n}\n\n// Si on appelle .Result ou .Wait() sur la tâche, un deadlock se produit\nvar data = GetDataAsync().Result; // MAUVAIS !\n2. Gestion de la mémoire et Garbage Collector (GC)
\n\nUn développeur avancé doit comprendre comment .NET gère la mémoire pour éviter les fuites et optimiser les performances.
\n\nQuestion : Expliquez les générations du GC (Gen 0, Gen 1, Gen 2) et le Large Object Heap (LOH).
\nLe GC dans .NET utilise un modèle générationnel. Les objets commencent dans Gen 0 (collecte fréquente). S'ils survivent à la collecte, ils passent en Gen 1, puis en Gen 2. Le LOH est destiné aux objets de plus de 85 000 octets. Il n'est pas compacté par défaut (avant .NET 4.5.1), ce qui peut entraîner une fragmentation. La question peut être approfondie : "Comment fonctionne le garbage collection en arrière-plan ?" ou "Quels sont les modes GC : Workstation vs Server ?"
\n\nQuestion : Qu'est-ce que la finalisation (Finalization) et comment éviter les problèmes qui y sont liés ?
\nLes finaliseurs (~Finalizer()) ralentissent le garbage collection, car les objets avec finaliseurs sont placés dans la file d'attente de finalisation et nécessitent deux passages du GC. Le modèle correct est l'implémentation de IDisposable avec le modèle Dispose.
public class ResourceHolder : IDisposable\n{\n private IntPtr _handle;\n private bool _disposed = false;\n\n public void Dispose()\n {\n Dispose(true);\n GC.SuppressFinalize(this);\n }\n\n protected virtual void Dispose(bool disposing)\n {\n if (!_disposed)\n {\n if (disposing)\n {\n // Libérer les ressources managées\n }\n // Libérer les ressources non managées (handle)\n _disposed = true;\n }\n }\n\n ~ResourceHolder()\n {\n Dispose(false);\n }\n}\n3. Délégués, événements et LINQ : de la syntaxe à la compréhension
\n\nCes sujets sont souvent
