Scorecard Développeur .NET
Voici comment évaluer un Développeur .NET en entretien : les compétences à noter, les questions à poser et les signaux d'alerte. Une grille de base, à ajuster selon votre contexte et vos priorités.
Un exemple à adapter. Cette scorecard est un modèle, pas une grille à appliquer telle quelle. Gardez les critères qui correspondent à votre poste et à votre équipe, ajustez ou retirez les autres. Le bon profil dépend de votre contexte.
Développeur .NET
La mission en une phrase
Des API back end fiables et documentées
Le profil livre des services et des API en ASP.NET Core qui tiennent en production, avec une gestion des erreurs et une documentation claires pour les équipes qui les consomment.
Un code testé et maintenable
Les fonctionnalités sont couvertes par des tests automatisés et structurées de façon à pouvoir évoluer sans tout casser. La dette technique reste sous contrôle et est traitée de manière explicite.
Des performances maîtrisées
Le profil sait repérer un goulot d'étranglement, le mesurer et le corriger. Les requêtes à la base de données et les temps de réponse restent dans des limites raisonnables sous charge.
Des livraisons régulières et prévisibles
Les développements avancent par incréments, sont relus en revue de code et intégrés sans heurts. Les engagements pris en début de sprint sont tenus ou renégociés en temps utile.
✗ Faible · Écrit du C# qui fonctionne mais reste daté, ignore async/await ou en abuse sans comprendre le modèle sous-jacent.
✓ Excellent · Manipule à l'aise les constructions récentes du langage (async/await, LINQ, génériques, records) et explique pourquoi il les utilise.
✗ Faible · Sait créer un contrôleur mais peine sur la structuration, l'injection de dépendances ou la gestion des cas d'erreur.
✓ Excellent · Construit des API REST propres en ASP.NET Core, gère l'injection de dépendances, le middleware, l'authentification et le versionnement sans hésiter.
✗ Faible · Utilise Entity Framework comme une boîte noire, ne voit pas les requêtes générées et provoque des problèmes de performance sans s'en rendre compte.
✓ Excellent · Modélise les données avec Entity Framework Core, comprend le suivi des entités, les migrations et sait quand descendre en SQL pour une requête sensible.
✗ Faible · Teste après coup ou pas du tout, confond couverture et qualité, ou écrit des tests fragiles qui cassent au premier changement.
✓ Excellent · Écrit des tests unitaires et d'intégration utiles, isole ses dépendances, et considère la testabilité comme un critère de conception.
✗ Faible · Optimise au jugé sans mesurer ou ignore les problèmes de performance jusqu'à ce qu'ils deviennent bloquants.
✓ Excellent · Profile une application, lit des métriques, identifie une fuite mémoire ou une requête trop lente et la corrige avec méthode.
✗ Faible · Reste cantonné à un usage Windows historique et n'a pas de repères sur les versions récentes de la plateforme.
✓ Excellent · Connaît les évolutions du .NET unifié, sait faire tourner et déployer une application sur Linux et en conteneur, et suit la cadence des versions.
✗ Faible · Considère le déploiement comme l'affaire d'un autre et ne sait pas reproduire un build en dehors de sa machine.
✓ Excellent · Met en place ou fait vivre un pipeline de build et de déploiement, automatise les tests et comprend la chaîne qui mène son code en production.
Rigueur et sens de la qualité
✗ Faible · Livre vite mais laisse des angles morts, néglige la relecture et accumule des correctifs après coup.
✓ Excellent · Soigne ses livrables, anticipe les cas limites et ne laisse pas passer un code qu'il ne serait pas fier de relire.
Communication technique
✗ Faible · Reste silencieux sur ses difficultés, livre sans contexte ou rend ses décisions difficiles à suivre pour l'équipe.
✓ Excellent · Explique un choix d'architecture à un pair comme à un non-technique, documente l'essentiel et alerte tôt quand un point bloque.
Esprit de collaboration
✗ Faible · Travaille en silo, prend mal la critique de son code ou impose ses choix sans écouter.
✓ Excellent · Donne et reçoit des revues de code de façon constructive, partage sa connaissance et tire l'équipe vers le haut.
Autonomie et fiabilité
✗ Faible · A besoin d'être relancé en permanence, sous-estime ses tâches ou laisse des sujets en suspens sans prévenir.
✓ Excellent · Prend en charge un sujet de bout en bout, sait quand demander de l'aide et tient ses engagements sans supervision rapprochée.
Compétences techniques
Quand utilisez-vous async/await, et qu'est-ce qui se passe réellement quand on attend une tâche ? Quels pièges avez-vous déjà rencontrés ?
→ Vérifiez la compréhension du modèle asynchrone, pas juste la syntaxe. Le candidat doit citer un piège concret comme un blocage ou un deadlock.
Une requête Entity Framework rend votre endpoint lent. Comment vous y prenez-vous pour diagnostiquer et corriger ?
→ Attendez une démarche : observer le SQL généré, mesurer, repérer un problème de chargement ou de N+1, puis corriger plutôt que deviner.
Comment décidez-vous de ce qui mérite un test unitaire, un test d'intégration, ou rien du tout ?
→ Le candidat doit raisonner sur la valeur et le risque, pas viser un pourcentage de couverture. Méfiez-vous du dogmatisme dans un sens comme dans l'autre.
Réalisations & expérience
Décrivez une application back end en .NET dont vous êtes fier. Quel était votre périmètre, et quelles décisions techniques avez-vous portées ?
→ Cherchez une responsabilité réelle sur la conception, pas seulement l'exécution de tickets. Le candidat doit savoir expliquer le pourquoi de ses choix.
Mise en situation
Racontez une fois où vous avez dû reprendre une base de code .NET héritée et difficile à maintenir. Par quoi avez-vous commencé ?
→ Cherchez du pragmatisme : sécuriser par des tests, comprendre avant de refondre, livrer de la valeur sans tout réécrire d'un coup.
Motivation & fit
Qu'est-ce qui vous donne envie de travailler sur cette stack et ce produit en particulier ?
→ Cherchez un intérêt sincère pour l'écosystème et le contexte, au-delà du salaire. Une réponse trop générique est un signal à creuser.
Savoir-être & collaboration
Donnez un exemple de désaccord technique avec un collègue. Comment l'avez-vous résolu ?
→ Le candidat doit montrer qu'il argumente sur des faits, écoute l'autre, et sait se ranger derrière une décision même s'il n'était pas d'accord.
Utilise l'écosystème .NET comme une boîte noire sans curiosité pour ce qui se passe en dessous.
Sur des sujets de performance ou de fiabilité, ce profil reste bloqué dès que le framework ne suffit plus et ne sait pas diagnostiquer.
Considère les tests comme une perte de temps ou une formalité imposée.
La maintenabilité et la confiance dans les livraisons en pâtissent directement, et la dette s'accumule sans filet de sécurité.
Reste figé sur le .NET Framework historique sans aucune ouverture vers les versions modernes.
Le décalage avec la cadence actuelle de la plateforme s'aggrave vite et limite les choix d'hébergement comme de recrutement futur.
Optimise au jugé, sans jamais mesurer ni profiler.
Les efforts partent dans le vide ou créent de nouveaux problèmes, et les vrais goulots d'étranglement restent en place.
Prend mal la revue de code et défend son code plus que la solution.
La collaboration se tend, la qualité collective baisse et les bonnes pratiques d'équipe deviennent difficiles à faire respecter.
Lecture du score
Notez chaque compétence et savoir-être de 1 à 5. Repère de décision : moyenne supérieure ou égale à 4 sur les must-have et aucun red flag majeur = go ; 3 à 4 avec réserves = à challenger en second tour ; un must-have sous 3 ou un red flag majeur = no-go. Un nice-to-have faible ne doit jamais éliminer un bon profil.
Qu'est-ce qu'une scorecard pour recruter un Développeur .NET ?
Une scorecard développeur .net est une grille d'évaluation structurée : elle liste les compétences et savoir-être à noter de 1 à 5, les questions d'entretien à poser et les signaux d'alerte. Elle permet de comparer les candidats sur des critères objectifs plutôt que sur une impression. On parle aussi de scorecard développeur dotnet, scorecard dev c#, scorecard développeur asp.net core.
Comment utiliser cette scorecard Développeur .NET ?
Téléchargez-la en PDF, Excel ou Notion, notez chaque critère de 1 à 5 pendant l'entretien, puis additionnez les scores du panel pour décider sur des faits. La version Excel calcule la moyenne et la décision automatiquement.
Quelle différence faire entre le .NET Framework historique et le .NET moderne dans le profil recherché ?
Le .NET Framework historique reste lié à Windows et n'évolue plus que pour la maintenance. Le .NET moderne, unifié et cross-platform, tourne aussi sur Linux et en conteneur, avec un rythme de versions soutenu. Un profil qui ne connaît que le premier peut convenir pour maintenir l'existant, mais pour un produit qui doit durer, privilégiez quelqu'un à l'aise avec la plateforme moderne ou clairement motivé pour migrer.
Faut-il exiger une expérience de migration vers le .NET moderne ?
Cela dépend de votre contexte. Si vous portez encore une application sur l'ancienne génération, une expérience de migration vaut de l'or car elle suppose de comprendre les deux mondes et leurs incompatibilités. Si votre base est déjà sur le .NET moderne, c'est un atout secondaire. Dans tous les cas, la capacité à se tenir à jour sur les versions compte plus qu'une migration précise sur le CV.