Pourquoi l'utilisation d'abstractions (comme LINQ) est-elle si taboue?
Je suis un entrepreneur indépendant et, à ce titre, j'interviewe 3 à 4 fois par an pour de nouveaux concerts. Je suis au milieu de ce cycle maintenant et je me suis vu refuser une opportunité même si j'avais l'impression que l'entretien s'était bien passé. 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 candidat pour chaque organisation. Cela dit, ma moyenne au bâton est inférieure à la normale, j'ai donc poliment demandé à mon dernier intervieweur des commentaires constructifs, et il a livré!
L'important, selon l'intervieweur, était que je semblais trop pencher vers l'utilisation d'abstractions (telles que LINQ) plutôt que vers des algorithmes de niveau organique plus bas.
En surface, cela a du sens - en fait, cela a également fait sens aux autres rejets parce que j'ai aussi bavardé sur LINQ dans ces interviews et il ne semblait pas que les enquêteurs en savaient beaucoup sur LINQ (même s'ils étaient .NET les mecs).
Alors maintenant, je me retrouve avec cette question: Si nous sommes censés être "debout sur les épaules de géants" et utiliser des abstractions qui sont à notre disposition ( comme LINQ), alors pourquoi certains le considèrent-ils si tabou? N'est-il pas logique de retirer le code "de l'étagère" s'il atteint les mêmes objectifs sans coût supplémentaire?
Il me semble que LINQ, même si c'est est une abstraction, est simplement une abstraction de tous les même algorithmes que l'on écrirait pour accomplir exactement la même chose fin. 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 s'embêter à écrire vos propres classes en premier lieu?
Je ne veux pas me concentrer sur LINQ ici. Je suis sûr que le monde Java 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 écrite.
MISE À JOUR
Comme l'a souligné Euphoric, il n'y a rien de comparable à LINQ dans le monde Java. Donc, si vous développez sur la pile .NET, pourquoi ne pas toujours essayer est-il possible que les gens ne comprennent tout simplement pas ce qu'il fait?
Je ne pense pas que ce soit l'utilisation d'abstractions en soi qui soit répréhensible. Il y a deux autres explications possibles. La première est que les abstractions sont toutes qui fuient à un moment ou à un autre. Si vous donnez l'impression, correcte ou non, que vous ne comprenez pas les fondamentaux sous-jacents, cela pourrait mal se refléter dans une interview.
L'autre explication possible est l'effet fanboy. Si vous parlez avec enthousiasme de LINQ et que vous en parlez à plusieurs 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é à des alternatives.
Si vous pensez vraiment que vous seriez heureux dans une boutique non-LINQ, essayez de demander ce qu'ils utilisent et adaptez vos réponses en conséquence. Montrez-leur que, même si vous préférez LINQ, vous êtes compétent avec les outils disponibles.
Certains programmeurs .NET, en particulier ceux provenant d'un arrière-plan VB/ASP classique ou C++, n'aiment pas les nouveautés comme LINQ, MVC et Entity Framework.
Sur la base de ce que j'ai observé, les anciens VB de ce groupe sont susceptibles d'utiliser 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 comme "n-tier" et similaires et ne comprendront vraiment rien du tout au-delà de .NET Framework 2.0 et ne veulent rien apprendre à ce sujet.
Les C++ 'ont tendance à être des programmeurs à orientation académique qui aiment coder des algorithmes sympas, même si cela signifie 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 se plaisent également à faire en sorte que les personnes interrogées se sentent inférieures, en particulier celles qui ont une formation moins traditionnelle.
Vous risquez de rencontrer des organisations comme celle-ci lorsque vous interviewez. Mais, vous rencontrerez également certains qui utilisent des méthodes plus récentes. Ne laissez pas quelques mauvaises interviews vous décourager.
Microsoft a une longue histoire de sortie avec de nouvelles technologies chaudes et d'oubli à leur sujet 5, 10 ou 20 ans plus tard. LINQ pourrait ressembler à un autre pour certaines personnes. Ils noteront que Microsoft ne peut pas déprécier SQL, mais LINQ pourrait suivre Silverlight . Donc, vous pourriez voir la paranoïa résultant d'une expérience difficile, ou simplement des gens qui ont été laissés pour compte par la technologie moderne et qui en veulent.
N'est-il pas logique de retirer le code "de l'é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 pour les produits standard est toujours là. La douleur d'obtenir des mises à jour (et des dépendances) est toujours là. L'incapacité à visser avec les tripes est toujours là.
Pour LINQ, le premier ne s'applique vraiment. Beaucoup de gens considèrent que le code à l'aspect "bizarre" est difficile à lire et plus difficile à déboguer. La syntaxe sql-like est à peu près persona-non-grata chaque concert professionnel que j'ai travaillé 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 sacré outil utile et devrait être préféré dans la plupart des situations. Pleurer non inventé ici, et les abstractions ne devraient pas être favorisées sent fortement Dissonance Cognitive .
Ils ne connaissent 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 courant.
Quelque chose d'autre que vous devriez considérer est que votre enthousiasme pour une nouvelle technologie cool peut simplement mettre les gens mal à l'aise et ne pas vouloir de vous. Vous ne les "habilitez" pas, car c'est vous qui connaissez cette technologie, pas eux. Même s'ils ne s'en rendent pas compte eux-mêmes, ils peuvent rechercher des candidats qui renforcent ce dans 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 de manière incorrecte, et me faire voir vous prouvera il."
Mon opinion à ce sujet (et TBH je suppose parce qu'aucun d'entre nous ne peut dire ce que ces enquêteurs pensaient) est que souvent vous vous rendez à une entrevue pour expliquer pourquoi ils devraient vous embaucher pour s'intégrer à leur équipe, leur façon de travailler.
Vous pouvez être le développeur parfait, un dieu du code de démarrage, mais cela ne signifie absolument rien si ce que vous voulez faire (souligné par vous en parlant de manière excessive et trop enthousiaste de quelques gubbins de technologie cool) leur parle simplement de vous, et que vous ne le feriez pas s'adapter à 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 ait oublié comment le maintenir. S'ils développent de nouvelles choses et que vous voulez vraiment mettre cette nouvelle technologie cool partout, il est évident qu'ils auront un gros problème avec la future maintenance du code et/ou la formation du personnel.
En tant que pigiste, c'est beaucoup plus un problème que s'ils embauchaient un permie. Avec une permie, la formation et le développement de nouvelles façons de travailler ne sont pas de mauvaises choses, dans le cadre du code et des pratiques existants - vous serez là pendant longtemps pour améliorer les choses. Avec un pigiste, ils ne donnent vraiment pas un coup de coude ce que vous voulez, vous êtes là uniquement pour faire leur travail comme ils le veulent, 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. La même chose s'applique à toute technologie qui n'est pas utilisée par l'entreprise, ce n'est généralement pas un problème si vous la mentionnez comme quelque chose de bien. Le problème survient lorsque vous êtes trop enthousiaste et intéressé.
Celui-ci est devenu un peu long, mais il pourrait être utile à quelqu'un, alors je le laisse faire.
J'ai en fait rencontré quelque chose de similaire, en passant par un peu plus de 20 interviews le mois dernier (un mélange de téléphone et de face à face). Il se passait certainement 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 choses qui ont généralement été au centre des cycles d'entrevues des cinq ou six dernières années n'ont décidément pas été discutées ou ont fait l'objet d'une courte discussion. Des choses comme les principes fondamentaux de OOP analyse/conception, modèles (conception et architecture à la fois), certaines des fonctionnalités .net plus avancées/axées sur l'abstraction (y compris lambdas ou LINQ en particulier, génériques, sérialisation/données contraignante, et similaire), et même le sujet habituellement brûlant de la méthodologie privilégiée (personne ne semblait se soucier beaucoup de l'agile par rapport à la cascade ou de la saveur de l'agile) et des outils ou du choix de l'ORM ou des moyens préférés de collaboration ou de gestion du contrôle des sources. cas non mentionnés du tout, dans presque tous les cas apparemment pas préoccupants.
Ce qui a retenu l'attention, dans plusieurs entrevues et dans diverses entreprises non liées dans des secteurs non liés, allait dans le sens suivant:
Une étrange fixation sur les conventions obsolètes/dépassées et les limites 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 des fonctionnalités explicites dans cette ère de .net ... comme si c'était une vraie jauge d'une capacité de développeur moderne ... la capacité de se souvenir le paradigme et les limites d'il y a 9 ans sont encore paralysés par des contraintes irréalistes/arbitraires. Un autre endroit était très acharné au sujet des collections personnalisées, vers les collections pré-génériques. Un autre endroit a dessiné un exemple de code d'un modèle de classe que j'ai gribouillé parce que je n'utilisais pas de constructeurs en cascade (ils ne semblaient pas conscients de la prise en charge de l'initialisation des propriétés lors de la déclaration, ce qui était suffisant pour le besoin). Un autre endroit était important pour les délégués et n'aimait pas ma réponse que j'avais l'habitude de déclarer souvent mais je n'ai pratiquement plus besoin de les déclarer grâce à Action <> et Func <>.
Accent extrême sur les détails d'implémentation spécifiques dans un microcosme et/ou des paramètres de configuration, même dans le cas de technologies qui se concentrent sur le fait d'être indépendantes de la plate-forme ou du protocole (c.-à-d. Que le point essentiel ne doit PAS être fixé sur une implémentation spécifique ou une utilisation particulière, mais plutôt sur la réutilisation/réaffectation/extensibilité/au besoin intégration).
Volonté de spécifier/superviser/réviser le code/et, par ailleurs, de suspendre le travail vers et depuis une équipe offshore, et les compétences non liées au codage associées.
Utilisation de versions spécifiques de produits/plates-formes/modules/etc. Dans une mesure 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 n'avez pas utilisé quelque chose pas du tout, et la chose spécifique qu'ils demandent aussi ... aucune substitution ne semble compter, même d'un produit concurrent plus largement utilisé et plus complet.
Une concentration beaucoup plus importante sur "comment vous adapterez-vous à notre équipe" plutôt que "êtes-vous réellement 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 idiot dangereux qui viendra et démolira boutique ". Dans certains cas, mon curriculum vitae était simplement considéré comme une évidence, et même le soi-disant "écran technique" ou l'entretien technique était une évaluation de la personnalité bien plus qu'une évaluation des compétences. Même pour des postes à contrat à court terme où vous seriez là et repartiriez avant que les deux saisons aient changé.
Les entreprises semblaient cette fois-ci se concentrer beaucoup moins sur la résolution de problèmes techniques spécifiques, le démarrage de nouveaux projets de développement green-field ou big 2.0, ou la mise sur le marché d'un produit spécifique pour capitaliser sur une tendance ou une opportunité émergente, ou sur les gros lancements habituels . Un thème récurrent que j'ai remarqué dans au moins 15 des endroits était qu'un petit groupe de 3 à 5 développeurs, principalement des survivants de l'effondrement du marché en 08, ont été capables de moudre un produit au cours des 3 dernières années environ. et ont trouvé un certain succès ou leur entreprise dans son ensemble est en plein essor et ils embauchent de nouvelles personnes pour répondre aux demandes croissantes de fonctionnalités ou pour corriger/surmonter les défauts de conception qu'ils ont intégrés à ces systèmes, ou pour reprendre les plates-formes susmentionnées pour libérer l'équipe de base qui l'a construit pour faire "d'autres projets". Les détails différaient et il y avait des exceptions, mais c'était la configuration générale du terrain cette fois-ci.
Mais ... s'il y a une chose que je sais de cette entreprise, c'est qu'elle est cyclique. La prochaine fois que je chercherai un nouveau concert, je ne serai pas surpris si le jeu a encore changé. Vous devez juste rester mentalement flexible, faire de l'écoute active, éviter de faire des déclarations absolues si elles ne sont pas nécessaires, mais ne soyez pas une belette non plus, et ne paraissez pas comme étant unidimensionnelle (vous venez comme un idiot ou un fanatique, ni souhaitable) ou comme étant trop bon (cela 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 quelques façons différentes dont vous pourriez aborder un problème ... mais même si c'est une connaissance par cœur pour vous, agissez comme si vous y réfléchissiez réellement et raisonnement sur place. Cela semble plus humble et moins intimidant ou choquant de cette façon.
Bien sûr, la loi de Murphy étant ce qu'elle est, la toute prochaine interview après que vous ayez cessé d'être "passionné par mon gars technologique préféré" et d'adopter une position plus équilibrée/caressante de barbe est le concert que vous le feriez avez obtenu si vous aviez été le fanatique fou. ;)
Il y a une préoccupation valable que j'ai entendue de la part de ceux qui n'utilisent pas Linq, et c'est celle que je prends à cœur: "Ce n'est pas parce que vous ne pouvez pas voir la mise en œuvre 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 initiés par LINQ ici grincent des dents. Pourquoi? Parce que ce code a l'air agréable et élégant ne signifie pas qu'il n'est pas terriblement inefficace. Count (), avec un prédicat, évalue chaque élément de son parent énumérable et résume les fois où le prédicat a renvoyé true. Donc, non seulement ce N ^ 2 (lorsque inputList et otherInputList ont une cardinalité N à peu près égale), c'est le pire des cas N ^ 2 absolu; CHAQUE élément de otherInputList est traversé pour CHAQUE élément d'entrée. Au lieu de cela, la première étape consiste à utiliser Any () au lieu de Count, car c'est vraiment ce que vous voulez savoir, et il se fermera dès que la réponse sera "oui". Configuration d'un HashSet qui stocke des valeurs distinctes de otherInputListObject.OtherProperty pourrait aussi vous aider; l'accès devient O(1) au lieu de O (N), donc pour un coût de configuration linéaire initial, vous réduisez toute l'opération à linéaire pire des cas complexité au lieu de quadratique meilleur cas complexité.
Ainsi, nous voyons que ces méthodes élégantes de Nice ont des coûts sérieux derrière elles, et si vous ne savez pas quels sont ces coûts, vous pouvez très facilement coder un O (mon GD) -algorithme de complexité dans le serveur de fichiers central haute performance de votre futur employeur ou la page principale du portail de destination la prochaine fois qu'il pourrait avoir besoin d'un Tweak. Vous renvoyer après avoir fait cela n'annule pas ce que vous avez fait, mais ne pas vous embaucher s'ils pensent que vous le feriez 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) et de leur complexité, et comment arriver à la réponse en un temps efficace (NlogN ou mieux).
Une autre préoccupation est le bon vieux argument "Quand votre seul outil est un marteau". Mettez-vous à la place de l'intervieweur interviewant ce fanboy de Linq. Le candidat aime Linq, veut l'utiliser, pense que c'est la meilleure chose qui soit. Il pourrait même sembler que le candidat ne pourrait pas coder sans lui, car chaque problème de programmation donné a été résolu avec Linq. Eh bien, que se passe-t-il quand il ne peut pas être utilisé? Beaucoup de code .NET 2.0 est toujours là, que s'il était mis à niveau nécessiterait des mises à niveau douloureuses des serveurs, des postes de travail des utilisateurs, etc., tout cela pour que vous puissiez utiliser vos méthodes d'extension sophistiquées. En tant qu'enquêteur, j'essayerais de vous montrer que vous pouvez coder un tri efficace ou utiliser les méthodes de tri 2.0 si vous le deviez, peu importe à quel point je pourrais être d'accord avec vous que les bibliothèques Linq et les méthodes d'extension similaires sont plutôt jolies. doux. Un enquêteur qui ne voit pas le point pourrait même ne pas prendre la peine d'essayer de vous montrer aptitude à autre chose; ils vont supposer que vous ne l'avez pas et continuer.
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 informatiques avec une forte aversion pour tout ce qui n'est "pas inventé là-bas"1, aucun d'entre eux ne disqualifierait les candidats en fonction de leurs préférences dans la pile technologique: ils étaient à juste titre convaincus qu'ils pouvaient apprendre au bon candidat à utiliser leurs bibliothèques locales.
Je doute sérieusement que la société ait carrément 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 savoir si vous connaissez vos tables de hachage est de vous demander d'en implémenter une primitive sur un tableau blanc. Cet exercice simple révèle au réviseur une quantité surprenante de données sur vos connaissances: il apprend instantanément si vous connaissez le code de hachage/égal 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 si bien fait son travail. 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 expérience est suffisante 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 utiliseraient insister pour que vous utilisiez les implémentations de bibliothèque plutôt que la vôtre une fois que vous serez embauché pour travailler pour leur entreprise. Mais pendant l'entrevue, ils vous pousseraient vers le code de bas niveau pour mieux comprendre vos vraies capacités.
1
Je pense que vous faites là des généralisations folles du type "J'ai vu une vache noire en Écosse, donc toutes les vaches écossaises sont noires".
Si je vous interviewais, je serais déçu si vous ne pouviez pas répondre à mes questions linq.
Linq est cependant délicat, beaucoup de gens le voient comme vaudou, ce qui est injuste car il est en fait très simple et d'autant plus intelligent pour cela.
Pour jouer l'avocat du diable, la raison en est que de nombreux développeurs ne se soucient pas des nouvelles choses et pensent que tout doit être résolu avec des outils locaux (généralement inférieurs). Il n'y a rien de mal à utiliser des abstractions. Enfer, il n'y a généralement pas de bonne raison pas pour utiliser ces abstractions.
On dirait que vous venez d'interviewer un pauvre développeur qui ne se tient pas au courant des choses et adopte l'approche marteau-clou pour tout. Ce sont les types de développeurs qui ne connaissent rien aux outils open source utiles comme NUnit, ou NHibernate, ou les différents conteneurs IoC; ceux qui essaient de résoudre tous les problèmes avec un proc stocké massif dans la base de données; ceux qui ne savent absolument rien de MVC bien qu'il soit sorti depuis plusieurs années maintenant.