Pourquoi l'utilisation des abstractions (telles que LINQ) est-elle si taboue? [fermé]

Je suis un entrepreneur indépendant et, à ce titre, j'interviewe 3 à 4 fois par an pour de nouveaux concerts. Je suis en plein milieu de ce cycle et je me suis vu refuser une opportunité même si j'avais l'impression que l'entretien s'était bien déroulé. La même chose m’est arrivée plusieurs fois cette année.

Maintenant, je ne suis pas un gars parfait et je ne m'attends pas à être un bon choix pour toutes les organisations. Cela dit, ma moyenne au bâton est inférieure à la normale et j'ai donc demandé poliment à mon dernier intervieweur de lui faire part de ses commentaires constructifs.

Selon l’enquêteur, l’essentiel, c’est que j’ai semblé trop m’intéresser aux abstractions (telles que LINQ) plutôt qu’à des algorithmes de niveau organique développés de manière organique.

En apparence, cela a du sens - en fait, cela a aussi donné du sens aux autres refus parce que j’ai aussi parlé de LINQ dans ces entretiens et qu’il ne semblait pas que les enquêteurs en savaient beaucoup sur LINQ (même s’ils étaient .NET les mecs).

Alors maintenant, je reste avec cette question: si nous sommes censés être "debout sur les épaules de géants" et utiliser des abstractions qui nous sont disponibles (comme LINQ), alors pourquoi certaines personnes considèrent-elles cela si tabou? N’at-il pas de sens de tirer du code "sur étagère" s’il atteint les mêmes objectifs sans coût supplémentaire?

Il me semble que LINQ, même s’il s’agit d’ une abstraction, est simplement une abstraction de tous les mêmes algorithmes que l’on écrirait pour atteindre exactement le même but. Seul un test de performance pourrait vous dire si votre approche personnalisée était meilleure, mais si quelque chose comme LINQ répondait aux exigences, pourquoi se donner la peine d'écrire vos propres cours en premier lieu?

Je ne veux pas me concentrer sur LINQ ici. Je suis sûr que le monde JAVA a quelque chose de comparable, je voudrais juste savoir pourquoi certaines personnes sont si mal à l’aise avec l’idée d’utiliser une abstraction qu’elles-mêmes n’ont pas écrites.

MISE À JOUR

Comme Euphoric l'a fait remarquer, rien n'est comparable à LINQ dans le monde Java. Donc, si vous développez sur la pile .NET, pourquoi ne pas toujours essayer de l’utiliser? Est-il possible que les gens ne comprennent tout simplement pas ce que cela fait?

Je ne pense pas que l'utilisation d'abstractions en soi soit choquante. Il y a deux autres explications possibles. La première est que les abstractions ont toutes des fuites à un moment ou à un autre. Si vous donnez l’impression, correcte ou non, que vous ne comprenez pas les principes fondamentaux sous-jacents, cela pourrait refléter mal une interview.

L'autre explication possible est l'effet fanboy. Si vous parlez de LINQ avec enthousiasme et que vous en parlez à maintes reprises dans une interview avec une entreprise qui ne l'utilise pas et qui n'a pas l'intention de le faire, cela donne l'impression que vous seriez insatisfait ou même mécontent de travailler avec des technologies plus anciennes. Cela peut également donner l’impression que votre enthousiasme pour un produit vous a aveuglé aux alternatives.

Si vous pensez vraiment que vous seriez heureux dans un magasin non LINQ, essayez de demander à ce qu'ils font usage, et d' adapter vos réponses en conséquence. Montrez-leur que si vous préférez LINQ, vous maîtrisez les outils existants.

Certains programmeurs .NET, en particulier ceux issus d'un arrière-plan VB / ASP classique ou C ++, n'aiment pas les nouveautés telles que LINQ, MVC et Entity Framework.

D'après ce que j'ai observé, les ex-VB de ce groupe utiliseront probablement encore des couches d'accès aux données et d'autres codes écrits à l'origine il y a plus de 10 ans. Ils utiliseront également d'anciens mots à la mode, tels que "n-tier", etc., sans rien comprendre au-delà de .NET Framework 2.0, ni vouloir en savoir plus.

Les développeurs C ++ ont tendance à être des programmeurs à vocation académique qui aiment coder des algorithmes sympas, même si cela implique de réinventer la roue. Ils détestent dépendre de tout ce qu'ils n'ont pas codé eux-mêmes. Quelques-unes de ces personnes sont également ravies de faire en sorte que les personnes interrogées se sentent inférieures, en particulier celles ayant des antécédents moins traditionnels.

Vous risquez de rencontrer des organisations comme celle-ci lorsque vous interviewez. Mais vous rencontrerez également des personnes utilisant des méthodes plus récentes. Ne laissez pas quelques mauvaises entrevues vous décourager.

Microsoft a une longue histoire de développement de nouvelles technologies et d’oublier ces technologies dans 5, 10 ou 20 ans. LINQ pourrait ressembler à un autre pour certaines personnes. Ils noteront que Microsoft ne peut pas déprécier SQL, mais LINQ pourrait suivre Silverlight . Vous pourriez donc voir la paranoïa résultant d'une expérience difficile, ou simplement des personnes laissées pour compte par la technologie moderne et qui en veulent.

N’at-il pas de sens de tirer du code "sur étagère" s'il atteint les mêmes objectifs sans coût supplémentaire?

Il y a toujours un coût supplémentaire.

La courbe d’apprentissage des produits disponibles dans le commerce est toujours présente. La difficulté d'obtenir des mises à jour (et des dépendances) est toujours présente. L'incapacité à faire le tour avec les tripes est toujours là.

Pour LINQ, le premier s'applique seulement vraiment. Beaucoup de gens considèrent que le code à la "bizarre" est difficile à lire et à déboguer. La syntaxe de type sql est à peu près persona-non-grata à chaque travail professionnel que j'ai effectué depuis sa sortie. LINQ to SQL (et d'autres sources de données) ont un certain nombre de pièges et d'options d'optimisation limitées.

Ce sont les arguments généraux contre les outils tiers et LINQ en particulier. Cela dit, LINQ est un outil extrêmement utile et devrait être préféré dans la plupart des situations. Crying Not Invented Here, et les abstractions ne doivent pas être privilégiées sent fortement la dissonance cognitive .

Ils ne savent pas / ne peuvent pas apprendre LINQ, mais ils sont "évidemment" de bons développeurs, donc LINQ ne doit pas en valoir la peine. C'est un piège commun.

Une autre chose à considérer est que votre enthousiasme pour une nouvelle technologie cool peut simplement rendre les gens mal à l'aise et ne pas vouloir de vous. Vous ne les "autonomisez" pas, car c'est vous qui connaissez cette technologie, pas eux. Même s'ils ne le réalisent pas eux-mêmes, ils peuvent rechercher des candidats qui renforcent ce pour quoi ils ont déjà investi tant de temps.

Vous voulez présenter une attitude qui dit: "Quoi que vous fassiez, je veux vous aider à y parvenir", plutôt que de donner un sous-texte qui dit: "Vous faites peut-être les choses mal, et m'avoir autour me prouvera il."

Mon point de vue (et TBH, je suppose, car aucun d’entre nous ne peut dire ce que pensaient les intervieweurs) est que vous assistez souvent à un entretien pour expliquer pourquoi ils devraient vous engager pour s’intégrer à leur équipe, à leur façon de travailler .

Vous pouvez être le développeur idéal, un dieu du code rock start, mais cela ne signifie absolument rien si ce que vous voulez faire (souligné par vos propos excessifs et trop enthousiastes au sujet de robots géniaux de la technologie) leur dit simplement de vous, et que vous ne le feriez pas. cadrer avec ce qu'ils veulent. S'ils ont un système d'accès aux données à l'ancienne, qui ne peut pas être mis à niveau pour une raison quelconque, ils n'ont pas besoin de quelqu'un qui avait oublié comment le maintenir. S'ils développent de nouvelles technologies et que vous voulez vraiment utiliser cette nouvelle technologie géniale partout dans le monde, il est évident qu'ils auront un gros problème en ce qui concerne la maintenance du code et / ou la formation du personnel.

En tant que pigiste, c'est beaucoup plus un problème que s'ils embauchaient une permie. Avec une permission, la formation et le développement de nouvelles méthodes de travail ne sont pas des mauvaises choses, dans le cadre du code et des pratiques existantes - vous serez là pendant longtemps pour améliorer les choses. Avec un pigiste, ils ne donnent vraiment pas envie de faire ce que vous voulez, vous êtes là uniquement pour faire leur travail comme ils l'entendent, et ce n'est pas votre travail de faire autre chose. (en désaccord - devenir un employé permanent)

Cela n'a probablement rien à voir avec LINQ lui-même, j'ai rejeté un candidat qui s'est présenté et a expliqué à quel point tout serait mieux écrit en Haskell. Nous ne faisons pas Haskell. Il en va de même pour toute technologie non utilisée par l'entreprise. Généralement, ce n'est pas un problème si vous le mentionnez comme quelque chose de bon. Le problème survient lorsque vous êtes trop enthousiaste et passionné.

Ceux qui n'utilisent pas Linq ont exprimé une préoccupation valable, et je la prends à coeur: "Ce n'est pas parce que vous ne pouvez pas voir la mise en œuvre que cela ne signifie pas qu'elle n'est pas chère".

Prenez l'extrait suivant:

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

Les LINQ-initiés ici sont en train de reculer. Pourquoi? Parce que ce code est beau et élégant ne signifie pas qu'il n'est pas terriblement inefficace. Count (), avec un prédicat, évalue chaque élément de l'énumérable parent et résume les heures auxquelles le prédicat a renvoyé la valeur true. Ainsi, non seulement N ^ 2 (lorsque inputList et otherInputList ont une cardinalité à peu près égale N), c’est le pire cas absolu N ^ 2; CHAQUE élément de otherInputList est traversé pour CHAQUE élément de l'entrée. Au lieu de cela, la première étape consiste à utiliser Any () à la place de Count, car c’est vraiment ce que vous voulez savoir, et elle s’arrêtera dès que la réponse sera connue comme "oui". La configuration d’un hachage contenant des valeurs distinctes otherInputListObject.OtherPropertypeut également vous aider; l'accès devient O (1) au lieu de O (N),la pire des cas au lieu de la complexité quadratique au mieux .

Ainsi, nous voyons que ces belles méthodes élégantes entraînent des coûts importants. Si vous ne savez pas quels sont ces coûts, vous pouvez très facilement coder un algorithme de complexité O (mon GD) dans le serveur de fichiers central hautes performances de votre futur employeur. ou la page principale du portail d'atterrissage la prochaine fois qu'ils pourraient avoir besoin d'un ajustement. Vous licencier après avoir fait cela ne défait pas ce que vous avez fait, mais ne pas vous embaucher s'il pense que vous le feriez, cela l'empêcherait. Donc, pour éviter cela, vous devez leur prouver le contraire; discutez de ce que font ces méthodes (ce qui signifie que vous devez vous connaître), de leur complexité, et de la manière d’arriver à une réponse efficace (NlogN ou mieux).

Une autre préoccupation concerne le bon vieux argument "Quand votre seul outil est un marteau". Mettez-vous à la place de l'intervieweur qui interviewe ce fan de Linq. Le candidat aime Linq, veut l'utiliser, pense que c'est la meilleure des choses. Il pourrait même sembler que le candidat ne pourrait pas coder sans, puisque chaque problème de programmation posé a été résolu avec Linq. Bien que se passe-t-il quand il ne peut pas être utilisé? Il reste encore beaucoup de code .NET 2.0 qui, s'il était mis à niveau, nécessiterait de douloureuses mises à niveau des serveurs, des postes de travail des utilisateurs, etc., le tout pour que vous puissiez utiliser vos méthodes d'extension sophistiquées. En tant qu’interviewer, j’essayerais de vous montrer que vous pouvez coder un tri efficace ou utiliser les méthodes de tri 2.0 si vous le devez, quel que soit le degré d’accord avec vous sur le fait que les bibliothèques Linq et les méthodes d’extension similaires sont assez jolies. sucré. Un intervieweur qui ne comprend pas le problème pourrait ne même pas se donner la peine d'essayer de vous faire montrer de l'aptitude à autre chose. ils vont supposer que vous ne l'avez pas et passer à autre chose.

Celui-ci est un peu long, mais il pourrait être utile à quelqu'un, alors je le laisse faire.

En fait, j'ai rencontré quelque chose de similaire, passant à travers un peu plus de 20 entretiens le mois dernier (mélange de téléphone et de face à face). Il y avait définitivement quelque chose d'inattendu sur lequel je ne pouvais pas vraiment mettre le doigt.

Une des choses que j’ai remarquées cependant, c’est que les sujets qui ont généralement été au centre des cycles d’interviews des cinq ou six dernières années n’ont décidément pas été discutés ou ont fait l’objet d’une discussion franche. Des éléments tels que les principes fondamentaux de l’analyse / conception orientée objet, les modèles (à la fois architecturaux et conceptuels), certaines des fonctionnalités .net les plus avancées / orientées vers l’abstraction (notamment lambdas ou LINQ, les génériques, la sérialisation / liaison de données, etc.), et même la sujet généralement brûlant de la méthodologie privilégiée (personne ne semblait se soucier beaucoup de l’agilité par rapport à la cascade ou à la saveur de l’agile) et des outils ou du choix de l’ORM ou des moyens de collaboration privilégiés ou de la gestion du contrôle à la source. Dans certains cas, pas du tout mentionnés, dans presque tous les cas, apparemment pas préoccupants.

Ce qui a attiré l’attention, dans de multiples entretiens et diverses entreprises non liées dans des industries non liées, allait dans ce sens:

• Une étrange fixation sur les conventions obsolètes / dépassées et les limitations du "retour à l'âge de pierre". Comme développer une application web primitive dans VS2003 avec une liste de restrictions absurdes, interdisant davantage l'utilisation de fonctionnalités explicites dans cette ère de .net ... comme s'il s'agissait d'un véritable indicateur de la capacité d'un développeur moderne ... la capacité de se souvenir le paradigme et les limites d'il y a 9 ans sont encore affaiblis par des contraintes irréalistes / arbitraires. Un autre lieu était très acharné au sujet des collections personnalisées, des collections pré-génériques. Un autre endroit a filtré un exemple de code d’un modèle de classe que j’ai gratté parce que je n’utilisais pas de constructeurs en cascade (ils ne semblaient pas au courant du support de l’initialisation de la propriété lors de la déclaration, ce qui était suffisant pour répondre aux besoins).

• Concentrez-vous sur les détails d’implémentation spécifiques dans un microcosme et / ou les paramètres de configuration, même dans le cas de technologies axées sur l’agnostic des plates-formes ou des protocoles sur la réutilisation / la réaffectation / l'extensibilité / l'intégration requise).

• Volonté de spéculer / superviser / réviser le code / et autrement transférer du travail vers et depuis une équipe off-shore, et compétences non-codantes liées à cette tâche.

• Utilisation de versions spécifiques de produits / plates-formes / modules / etc. À un degré parfois absurde; "Alors ... vous avez utilisé les versions 1, 2 et 4? Mais pas 3, hein? Hmmm ... {annote votre CV avec" no v3 !!!} ". Le degré d'utilisation ne semblait pas avoir d'importance; seulement que vous avez ou avez pas utilisé quelque chose du tout , et la chose spécifique qu'ils demandent aussi ... aucune substitution semblait compter, même d'un produit concurrent plus largement utilisé et complet.

• Nous nous concentrons beaucoup plus sur "comment vous allez bien s'intégrer à notre équipe", "êtes-vous vraiment bon en tant que développeur de logiciels" ou "avez-vous les compétences et l'expérience pour ajouter de la valeur à l'entreprise et nous aider à fournir une qualité produit "ou même" êtes-vous un imbécile dangereux qui va venir et épave boutique ". Dans certains cas, mon CV était considéré comme acquis et même le prétendu "écran technique" ou entretien technique constituait une évaluation de la personnalité bien plus qu'une évaluation des compétences. Même pour des postes contractuels relativement à court terme où vous seriez là et reparti avant deux saisons ont changé.

• Cette fois-ci, les entreprises semblaient beaucoup moins concentrées sur la résolution de problèmes techniques spécifiques, le lancement de nouveaux projets dans des environnements verts ou de grands projets de développement 2.0, ou la mise sur le marché d'un produit spécifique pour tirer parti d'une tendance ou d'une opportunité émergente, ou des grands lancements habituels . Un thème récurrent que j'ai remarqué dans au moins 15 endroits est qu'un petit groupe de 3 à 5 développeurs, principalement des survivants du krach boursier de 08, a été en mesure de créer un produit au cours des trois dernières années environ. et ont rencontré un certain succès ou leur société dans son ensemble est en plein essor et ils embauchent de nouvelles personnes pour faire face à la demande croissante de fonctionnalités ou pour traiter / corriger les défauts de conception intégrés à ces systèmes, ou pour prendre en charge les plateformes susmentionnées afin de libérer l’équipe de base qui l’a construite pour faire "d’autres projets".

Mais… s'il y a une chose que je sais à propos de cette affaire, c'est que c'est cyclique. La prochaine fois que je cherche un nouveau concert, je ne serai pas surpris si le jeu a encore changé. Vous devez simplement rester mentalement flexible, faire de l'écoute active, éviter de faire des déclarations absolues si elles sont inutiles, mais ne soyez pas non plus une indiscrète, et ne prétendez pas être unidimensionnel (vous devenez idiot ou un zélote, ni souhaitable) ou comme trop bon (il peut être menaçant et vous coûter un concert).

Ajustez simplement votre approche et essayez de donner une réponse plus mesurée la prochaine fois. Mentionnez plusieurs façons différentes d’approcher un problème. raisonner sur place. Cela semble plus humble et moins intimidant ou choquant.

Bien sûr, la loi de Murphy étant ce qu'elle est, la toute prochaine interview après que vous cessez d'être "passionné par mon type actuel de technologie préféré" et adoptiez une position plus équilibrée / caressant la barbe est le concert que vous auriez eu si vous aviez été fou gars zélé. ;)

Je pense que vous tirez une fausse conclusion, car votre ensemble d'échantillons est trop limité. Bien que j'aie vu une bonne partie des magasins d'informatique qui manifestaient une forte aversion pour tout ce qui "n'était pas inventé là-bas" ¹ , aucun d'entre eux ne disqualifierait les candidats en fonction de leurs préférences dans la pile de technologies: ils étaient à juste titre convaincus qu'ils pourraient apprendre au bon candidat à utiliser leurs bibliothèques locales.

Je doute sérieusement que la société ait totalement interdit l'utilisation de LINQ. Plus probablement, ils voulaient que vous leur montriez vos compétences à un niveau plus profond.

Par exemple, une façon de déterminer si vous connaissez vos tables de hachage consiste à vous demander d’en implémenter une primitive sur un tableau blanc. Cet exercice simple révèle une quantité surprenante de données sur vos connaissances: il apprend instantanément si vous savez à propos du code de hachage / égaux, et ce que vous savez des collisions de hachage. En même temps, il est difficile d’imaginer une personne sensée ré-implémenter une table de hachage, car Microsoft a fait un si bon travail dans ce domaine. Il en va de même pour de nombreux algorithmes, tels que le tri et la recherche: les enquêteurs souhaitent souvent savoir si votre arrière-plan est suffisant pour comprendre les interactions de bas niveau, plutôt que de vérifier que vous avez une connaissance pratique des bibliothèques .NET.

Il est presque certain qu'ils insisteraient pour que vous utilisiez des implémentations de bibliothèques plutôt que les vôtres une fois que vous êtes embauché pour travailler pour leur entreprise. Mais pendant l'entretien, ils vous poussent vers le code de bas niveau pour mieux comprendre vos véritables capacités.

Je pense que vous faites des généralisations folles à propos du type "j’ai vu une vache noire en Ecosse, donc toutes les vaches écossaises sont noires".

Si je vous interviewais, je serais déçu de ne pas pouvoir répondre à mes questions sur linq.

Linq est un problème cependant, beaucoup de gens le voient comme du vaudou, ce qui est injuste car très simple et d'autant plus astucieux.

Pour défendre les intérêts du diable, la raison en est que de nombreux développeurs ne se soucient tout simplement pas de nouvelles choses et pensent que tout doit être résolu avec des outils développés par nos soins (généralement de qualité inférieure). Il n'y a rien de mal à utiliser des abstractions. Enfer, il n'y a généralement aucune bonne raison de ne pas utiliser ces abstractions.

On dirait que vous venez d’interviewer un développeur médiocre qui ne se tient pas au courant de la situation et adopte une approche irréprochable. Ce sont les types de développeurs qui ignorent tout des outils open source utiles comme NUnit ou NHibernate, ou des divers conteneurs IoC; ceux qui essaient de résoudre tous les problèmes avec un processus stocké massif dans la base de données; ceux qui ne savent absolument rien de MVC alors qu'il existe depuis plusieurs années.