Pourquoi la question «donnez cinq choses que vous détestez à propos de C #» est si difficile à répondre lors d'une interview? [fermé]

Dans le podcast 73 , Joel Spolsky et Jeff Atwood discutent, entre autres, de "cinq choses que tout le monde devrait détester à propos de leur langage de programmation préféré":

Si vous êtes satisfait de votre chaîne d'outils actuelle, il n'y a aucune raison de changer. Cependant, si vous ne pouvez pas énumérer cinq choses que vous détestez à propos de votre langage de programmation préféré, alors je soutiens que vous ne le connaissez pas encore assez bien pour en juger. Il est bon d'être conscient des alternatives et d'avoir un œil critique sain pour tout ce que vous utilisez.

Curieux, j'ai posé cette question à tout candidat que j'ai interviewé. Aucun d'entre eux n'a pu citer au moins une chose qu'ils détestent à propos de C # ¹.

Pourquoi? Qu'est-ce qui est si difficile dans cette question? C'est à cause du contexte stressant de l'entretien qu'il est impossible de répondre à cette question par les personnes interrogées?

Y a-t-il quelque chose dans cette question qui la rend mauvaise pour une interview?

Évidemment, cela ne signifie pas que C # est parfait. J'ai moi-même une liste de cinq choses que je déteste à propos de C #:

• L'absence de nombre variable de types dans les génériques (similaire aux paramsarguments).
  Action<T>,
  Action<T1, T2>,
  Action<T1, T2, T3>,
        ⁞ Sérieusement ?!
  Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>
  

• Le manque de support pour les unités de mesure, comme dans F #.

• L'absence de propriétés en lecture seule. Écrire un private readonlychamp de support chaque fois que je veux une propriété en lecture seule est ennuyeux.

• Le manque de propriétés avec des valeurs par défaut. Et oui, je sais que je peux les initialiser dans le constructeur sans paramètre et l'appeler à partir de tous les autres constructeurs. Mais je ne veux pas.

• Héritage multiple. Oui, cela crée de la confusion et vous n'en avez pas besoin dans la plupart des cas. Il est toujours utile dans certains cas (très rares), et la confusion s'applique également (et a été résolue en C #) à la classe qui hérite de plusieurs interfaces qui contiennent des méthodes du même nom.

Je suis à peu près sûr que cette liste est loin d'être complète, et il y a beaucoup plus de points à souligner, et surtout beaucoup mieux que le mien.

^{¹ Quelques personnes ont critiqué certains assemblys dans .NET Framework ou le manque de bibliothèques dans le framework ou critiqué le CLR. Cela ne compte pas, car la question portait sur le langage lui-même, et bien que je puisse potentiellement accepter une réponse à propos de quelque chose de négatif dans le noyau de .NET Framework (par exemple quelque chose comme le fait qu'il n'y a pas d'interface commune pour TryParse, donc si vous voulez analyser une chaîne en plusieurs types, vous devez vous répéter pour chaque type), une réponse sur JSON ou WCF est complètement hors sujet.}

Si je devais deviner:

1. Certains programmeurs manquent d'exposition linguistique diversifiée. Il est difficile de voir les choses avec la langue quand on ne sait pas que de meilleures choses existent.

2. Certains programmeurs sont de simples singes de code. Ils analysent à peine les problèmes devant eux, sans parler de la façon dont leur langage de programmation pourrait être meilleur.

3. Peu de gens sont particulièrement critiques. Ils voient des avantages et des fonctionnalités, pas des lacunes. Il leur est difficile de passer à ce mode de pensée si l'entretien ne se déroule pas de cette façon.

4. Au moins ici, être trop critique est considéré comme un défaut de personnalité fatal. Au lieu d'être `` ce développeur perspicace qui cherche toujours de meilleures façons de faire les choses '' (comme certains domaines dans lesquels j'ai vécu), ils sont `` ce connard qui déteste tout ''. Même les gens qui peuvent penser à des choses qu'ils détestent dans la langue peuvent différer dans un cadre d'entrevue pour sembler moins acerbes.

J'imagine qu'il est si difficile de répondre à la question lors d'une interview car c'est:

1. Vraiment inattendu,

2. Nécessite beaucoup de réflexion et une réflexion très différente de celle utilisée lors d'un entretien,

3. Il est difficile de répondre en général dans un court laps de temps (sauf si préparé avant l'entretien).

1. C'est inattendu

Les questions inattendues sont vraiment difficiles, surtout dans un contexte stressant. Imaginez la boîte de dialogue suivante lors d'une interview:

- Quelle est la différence entre HashSet<T>et List<T>?
- Le hashset est optimisé de manière à ce que la recherche d'un élément soit très rapide. Par exemple, si vous utilisez set.Contains()souvent une boucle, le déplacement de la setliste du hashset peut accélérer les choses.
- Comment créez-vous une propriété en lecture seule?
- J'utilise un champ marqué comme readonlychamp de support pour une propriété qui n'a qu'un getter.
- À quoi sert-il sealed?
- Vous l'utilisez pour des classes qui ne doivent pas être héritées.
- Quelle est la dernière fois que vous avez vu un dentiste?
- Quoi?!

2. Cela nécessite beaucoup de réflexion différente

Lorsque l'on vous pose des questions générales de type entretien, vous utilisez votre mémoire pour vous rappeler ce que vous avez appris dans des livres ou de votre pratique sur la langue et le cadre. Vous pouvez réfléchir un peu pour trouver une réponse, mais pas trop.

D'un autre côté, la question des cinq choses que vous détestez nécessite une réflexion plus approfondie. Vous ne pouvez pas simplement vous rappeler quelque chose que vous avez appris dans les livres, et vous ne pouvez rien trouver par analogie. Au lieu d'être passif, vous devez être critique et trouver ce qui pourrait être désagréable dans la langue que vous utilisez.

3. Il faut du temps

Franchement, j'ai ma liste de cinq choses (en fait plus) que je déteste à propos de C #, mais j'y ai réfléchi pendant une longue période de temps. Quelques éléments datent de l'ère .NET Framework 2; la plupart des problèmes que j'ai répertoriés pour .NET Framework 2 ne sont plus valides car ils ont été supprimés, certains avec LINQ et tous ces trucs de programmation fonctionnelle, d'autres avec la programmation dynamique. Je ne sais pas si, sans préparer cette question, je serais en mesure de retrouver les cinq éléments lors d'une interview.

Je pense que c'est difficile à cause du mot cinq . Et dans une moindre mesure, à cause du mot haine .

Cinq ? Et si vous n'en trouviez que quatre? N'avez-vous pas répondu à la question? Et si vous en avez plus de cinq? Maintenant, sur place, vous devez déterminer lesquels sont les cinq meilleurs à utiliser.

La haine est un mot très négatif. C'est le genre de négativité que l'on dit aux gens d'éviter lors des entretiens. De plus, je pense que ce serait paraître étrange à beaucoup de gens à avoir que beaucoup de choses qu'ils « haine » d'une langue qu'ils vont dépenser tous les programmes de jour Certaines personnes pourraient même penser que c'est une question piège. Si elles réellement ne viennent avec cinq choses, ils seront disqualifiés pour détester trop C # pour bien programmer. Malheureusement, ce genre de question piège perverse n'est pas inconnu dans les interviews.

Au lieu de cela, vous pourriez demander Que feriez-vous pour améliorer C # si cela ne tenait qu'à vous? Cela permet à la personne interrogée de répondre avec un certain nombre de choses. Cette formulation échange également la négativité du mot «haine» pour le relativement positif «améliorer».

• La plupart des candidats ne sont pas profondément impliqués dans plus d'une langue ou d'un paradigme afin de contraster . Je n'ai pas travaillé avec un autre langage orienté objet depuis plus de 5 ans maintenant, et celui dans lequel je travaillais (PowerBuilder), j'avais beaucoupdes écailles avec. La plupart des gars qui sortent de l'université sont (ou pensent qu'ils sont) des trucs chauds dans une, peut-être deux langues, et ont reçu une "exposition" à trois ou quatre autres (ce qui signifie qu'ils ont terminé au moins un devoir à la demande, mais moins d'un semestre complet) cours l’étudiant). Ce n'est pas assez de connaissances ou d'expérience pour vraiment savoir ce qui ne va pas avec la langue. Obtenez un emploi dans le monde réel, et cet objectif se rétrécit considérablement; vous en apprenez beaucoup plus sur la langue qui vous rapporte le salaire que n'importe quelle autre, et dans le processus, vous en arrivez à accepter ce que la langue ne fera pas, ou fait de manière bizarre, au point où vous ne vous en souvenez plus le faire différemment.

• La plupart des candidats sauvés en C # qui le comparent à Java / C / C ++ en sont assez satisfaits . C # a été conçu dès le départ pour faire beaucoup de choses mieux que Java (événements, rappels, bibliothèque graphique, travail de base de données). Java à son tour a été conçu pour être plus facile à utiliser, et donc plus axé sur le code correct, que C ++. Je n'ai pas encore rencontré un programmeur C # qui souhaite revenir au C ++ dans n'importe quel environnement où les performances fulgurantes et le contrôle au niveau du circuit proche ne sont pas des nécessités essentielles.

En d'autres termes, les See-Sharpers l'ont plutôt bien, tout bien considéré.

Voici ma liste:

• Les instructions Lambda ne sont pas observables / évaluables . Les appels aux méthodes nommées peuvent être connectés à QuickWatch de VS. Les expressions aussi. Mais les lambdas? Non (du moins pas dans VS2010). Fait du débogage des chaînes Linq une véritable corvée.

• Les valeurs de paramètre facultatives pour les types de référence autres que chaîne ne peuvent être que nulles . si je créais une pile de surcharge, je pourrais vouloir utiliser d'autres valeurs par défaut. Je pourrais peut-être par défaut une valeur basée sur une propriété ou une expression simple basée sur un autre paramètre. Mais je ne peux pas. Ainsi, la valeur de ne pas avoir à créer une pile de surcharge (ce qui est mineur avec un assistant de refactoring comme ReSharper pour gérer le passe-partout) est diminuée lorsque les options pour les paramètres facultatifs sont si drastiquement limitées.

• C # devient assez vieux pour avoir de sérieux problèmes de code hérités . Le code écrit à l'origine pour 1.1 ferait grincer des dents toute personne habituée à 4.0. Même le code 2.0 manque beaucoup. Dans le même temps, des bibliothèques tierces sont arrivées qui font que des choses comme ADO.NET semblent terriblement primitives (et une grande partie du "modèle connecté" d'ADO.NET est maintenant un grand anti-modèle). Pourtant, pour une compatibilité ascendante, .NET accélère la prise en charge de tout ce vieux et mauvais code, n'osant jamais dire quelque chose comme "ArrayList était une façon merdique de le faire, nous sommes désolés de l'avoir mis et nous prenons utilisez-le à la place et si vous avez absolument besoin d'une liste de types différents, déclarez-la comme List<Object>.

• Règles de déclaration de commutateur sérieusement limitées . L'une des meilleures choses que je puisse dire à propos de PowerBuilder est probablement que l'instruction Choose Case (équivalente à switch) permettait des expressions booléennes basées sur la variable. Cela permettait également aux instructions de basculement de passer même si elles avaient du code. Je comprends les raisons pour lesquelles ce deuxième n'est pas autorisé (il est plus probable qu'il soit fait involontairement que volontairement) mais il serait quand même bien de temps en temps d'écrire une déclaration comme:

  switch(someInt)
  {
      case < 0: //all negative values enter here
         //...
         break;
      case 0: 
         //...
         break;
      case 1:
         //...
         //no break; continue through to the code for > 1
      case > 1 // all positive values enter here (including 1)
         //...
         break;
  }

• Pas d'interface INumérique . Si c'est un nombre, vous pouvez faire des calculs avec. Dans de nombreux cas, la méthode réelle n'a pas à se soucier exactement des types qui sont branchés; la précision est la responsabilité de l'appelant. Pourtant, il n'est pas possible de créer une méthode ou une classe générique qui ne peut accepter que des types de nombres comme GTP.

Je dirais qu'une partie du problème est la peur de donner une mauvaise réponse - vous dites que vous détestez X, l'intervieweur aime X ou pense que votre raison de haïr X est idiot, disant que vous pensez que ça va peut sembler l'option la moins controversée.

C'est aussi probablement quelque chose auquel la plupart des gens n'ont pas vraiment réfléchi; ils ont des problèmes actuels et des problèmes passés, les problèmes passés causés par la jauge sont terminés et donc les gens pensent principalement à la solution et non au problème car c'était plus important, et peu auront un problème actuel causé par la langue.

Pour une interview, je ne demanderais que 1 ou 2, mais je suis d'accord, si vous ne pouvez pas nommer les limites de l'outil que vous utilisez, alors vous ne le savez probablement pas très bien. Nous posons cette question exacte sur SSIS et cela aide vraiment à séparer le blé de l'ivraie; tous ceux que nous avons embauchés qui ont bien répondu à cette question se sont transformés en un excellent employé. Nous avons besoin de personnes qui ont des connaissances avancées et non de quelqu'un qui les a examinées plusieurs fois. Et je parie que c'est ce que vous voulez aussi.

Je pense que c'est une question valable et le fait que tant de personnes ne puissent pas y répondre n'est qu'un exemple de la pauvreté réelle de nombreux candidats à des emplois. Si quelqu'un n'est pas suffisamment analytique pour être en mesure de déterminer certaines limites de l'outil, comment seront-ils jamais suffisamment analytiques pour résoudre des problèmes de programmation difficiles?

Cela revient à dire que vous avez dit manque d'expérience approfondie en C # et / ou manque d'exposition à d'autres langages. J'ai interviewé un certain nombre de développeurs qui se considéraient comme seniors et qui ne pouvaient pas répondre à certaines questions que même une légère égratignure à la surface de C # aurait dû leur révéler.

Sans creuser suffisamment, vous n'atteindrez pas les limites de la langue et souhaiteriez qu'elles soient parties. Mon top cinq au cas où quelqu'un se demanderait

1. Les objets immuables nécessitent beaucoup de cérémonie pour créer (par opposition à un langage fonctionnel où les objets sont immuables par défaut).
2. La métaprogrammation est difficile à réaliser. Comparez le type emit aux macros Lisp. (Les services de compilation seront très utiles à l'avenir).
3. Les méthodes d'extension sont excellentes ... les propriétés d'extension et les opérateurs d'extension (en particulier les opérateurs implicites et explicites) seraient mieux.
4. Les conversions explicites sont résolues au moment de la compilation au lieu de l'exécution.
5. Pas de correspondance de séquence, c'est tellement plus propre que la surcharge de fonctions.

Je pense que dans sa ronde sur la façon dont il dit; si vous pensez qu'il est cassé, vous ne comprenez probablement pas pourquoi il est tel qu'il est. Il peut y avoir un trou dans vos connaissances.

Ironiquement, les enquêteurs qui pensent citer «le grand Joël» en utilisant cela comme une question d'entrevue manquent probablement le point.

Ils pourraient être réticents à répondre parce qu'ils pourraient avoir l'impression que s'ils peuvent énumérer 5 choses qu'ils détestent à propos d'une langue, l'intervieweur pourrait se retourner et dire `` Oh, nous recherchons des ninjas C # '' et vous ne semblez pas aimer la langue »ou« Pourquoi avez-vous postulé si vous n'aimez pas la langue? ».

Les personnes interrogées sont soumises à de fortes pressions pour rester positives lors des entretiens.

Parce que les langues façonnent notre façon de penser . En utilisant C # tous les jours, vous avez pris l'habitude de penser et de concevoir votre code d'une manière qui contourne naturellement les problèmes du langage.

Vous le faites maintenant sans réfléchir, sans même savoir que vous le faites. C'est pourquoi il est si difficile de signaler les mauvaises choses. Nul doute que le jour où vous avez commencé à apprendre le C #, vous avez trouvé beaucoup de problèmes, mais maintenant vous ne les voyez plus. Les habitudes sont des choses puissantes. Habitudes de pensée, encore plus .

Le côté positif de ceci est que si vous trouvez difficile de lister les défauts en C #, ce doit être parce que vous êtes un bon programmeur C #, vous aimez le langage et l'utilisez plus que les autres langages.

Mais si vous voulez devenir plus capable de voir les défauts de C #, vous devez changer votre façon de penser. Apprenez plus de langages de programmation et familiarisez-vous avec eux. Visez les langues les plus différentes possibles. Vous êtes habitué à la frappe statique? Essayez Python ou Ruby. Vous êtes habitué aux objets et impératif? Haskell est un tout autre monde.

Et quand vous reviendrez en C #, vous vous demanderez: "Pourquoi ai-je besoin de cent lignes de C # pour faire cette chose simple qui n'est qu'une ligne dans Haskell?". Vous détesterez beaucoup de choses sur C #.

• C # n'a pas de types de référence non nullables.
• Pas de types de données algébriques.
• Pas d'interpolation de chaîne.
• La syntaxe est trop verbeuse partout.
• Pas de macro système.
• L'inférence de type est limitée.
• Aucun littéral regexp.
• Pas de typage structurel.
• Mauvais support pour l'immuabilité.
• Les structures C # sont sujettes aux erreurs.
• La bibliothèque de collections standard est très limitée.
• Impossible de définir des contraintes sur les paramètres des constructeurs.
• Impossible de programmer de manière générique avec des contraintes sur les opérateurs mathématiques.
• Pas de «nouveau type».
• Aucun découpage de tableau, aucun littéral de plage.
• Les fonctions ne répertorient pas les effets secondaires qu'elles peuvent faire dans le cadre de leur type. :)

(Bien sûr, aucune langue ne peut tout avoir. La conception d'une langue est extrêmement difficile, et l'ajout de chaque fonctionnalité dans la même langue ne peut pas fonctionner. Différents outils à des fins différentes.)

Oui, la question est difficile à bien répondre, surtout lors d'un entretien. Mais les gens qui peuvent y répondre prouvent qu'ils y ont pensé, qu'ils ont une certaine perspective.