Warum ist die Verwendung von Abstraktionen (wie LINQ) so tabu? [geschlossen]

60

Ich bin ein unabhängiger Auftragnehmer und als solcher interviewe ich 3-4 Mal im Jahr für neue Auftritte. Ich bin jetzt mitten in diesem Zyklus und wurde für eine Gelegenheit abgelehnt, obwohl ich das Gefühl hatte, dass das Interview gut verlaufen ist. Dasselbe ist mir in diesem Jahr ein paar Mal passiert.

Jetzt bin ich kein perfekter Typ und erwarte nicht, dass er zu jeder Organisation passt. Trotzdem ist mein Schlagdurchschnitt niedriger als sonst, also habe ich meinen letzten Interviewer höflich um konstruktives Feedback gebeten und er hat es geliefert!

Die Hauptsache laut dem Interviewer war, dass ich mich zu sehr auf die Verwendung von Abstraktionen (wie LINQ) zu stützen schien, anstatt auf niedrigere, organisch gewachsene Algorithmen.

Oberflächlich gesehen macht dies Sinn - tatsächlich machten die anderen Ablehnungen auch Sinn, weil ich in diesen Interviews auch über LINQ geschwatzt habe und es schien, als wüssten die Interviewer nicht viel über LINQ (obwohl sie .NET waren) Jungs).

Jetzt bleibt mir die Frage: Wenn wir "auf den Schultern von Riesen stehen" und uns zur Verfügung stehende Abstraktionen (wie LINQ) verwenden sollen, warum halten manche Leute das für so tabu? Ist es nicht sinnvoll, Code "von der Stange" zu ziehen, wenn dieselben Ziele ohne zusätzliche Kosten erreicht werden?

Es scheint mir , dass LINQ, auch wenn es ist eine Abstraktion, ist einfach eine Abstraktion von allen gleichen Algorithmen würde man genau das gleiche Ziel zu erreichen , schreiben. Nur ein Leistungstest kann Ihnen sagen, ob Ihr kundenspezifischer Ansatz besser ist, aber wenn etwas wie LINQ die Anforderungen erfüllt, warum sollten Sie sich überhaupt die Mühe machen, Ihre eigenen Klassen zu schreiben?

Ich möchte mich hier nicht auf LINQ konzentrieren. Ich bin mir sicher, dass die JAVA-Welt etwas Vergleichbares hat. Ich möchte nur wissen, warum es einigen Leuten so unangenehm ist, eine Abstraktion zu verwenden, die sie selbst nicht geschrieben haben.

AKTUALISIEREN

Wie Euphoric betonte, gibt es in der Java-Welt nichts Vergleichbares zu LINQ. Wenn Sie also auf dem .NET-Stack entwickeln, warum nicht immer versuchen, davon Gebrauch zu machen? Ist es möglich, dass die Leute nicht ganz verstehen, was es tut?

Matt Cashatt
quelle
8
Ich glaube, Sie wissen nicht, was "Abstraktion" ist, weil LINQ nichts damit zu tun hat.
Euphoric
8
"Ich bin sicher, dass die JAVA-Welt etwas Vergleichbares hat." LINQ ist eines der wenigen Dinge, die .NET und Java nicht haben.
Euphoric
42
@ Euphoric - Ist LINQ nicht abstrakt die untere Ebene der Arbeit von Aufgaben wie das Sortieren und Filtern zum Beispiel weg? Ich bin mir ziemlich sicher, dass objectCollection.Where(oc=>oc.price > 100)zum Beispiel ein zusätzlicher Code dahinter steckt . Wäre das nicht eine Verwendung einer Abstraktion? Vielleicht kannst du mir sagen, was ich hier vermisse. . .
Matt Cashatt
37
Es besteht immer die Möglichkeit, dass sie LINQ einfach nicht verstehen und den Wert nicht erkennen, wenn sie es lernen. Die funktionalen Aspekte des Schreibens unterscheiden sich sehr stark von der imperativen Programmierung. Als Auftragnehmer habe ich erst 2009 "erfahrene" Java-Entwickler gesehen, die SQL nicht genug verstehen, um erweiterte Abfragen zu schreiben, sodass sie Wochen damit verbringen, Code zu optimieren, der alle Daten auf die Java-Seite bringt und sie mit Java-Code filtert, anstatt dies zu tun die Datenbank macht es. Ignoranz ist in der Softwareentwicklungsbranche weit verbreitet.
18
Wenn Sie LINQ verstehen, Ihre Interviewer jedoch nicht, sind Sie besser als sie. Setze deine Ziele höher.
Jay Bazuzi

Antworten:

74

Ich denke nicht, dass die Verwendung von Abstraktionen per se zu beanstanden ist. Es gibt zwei weitere mögliche Erklärungen. Eine davon ist, dass alle Abstraktionen zu der einen oder anderen Zeit undicht sind . Wenn Sie den Eindruck erwecken, richtig oder falsch, dass Sie die zugrunde liegenden Grundlagen nicht verstehen, könnte dies in einem Interview schlecht reflektiert werden.

Die andere mögliche Erklärung ist der Fanboy-Effekt. Wenn Sie aufgeregt über LINQ sprechen und es in einem Interview mit einem Unternehmen, das es nicht nutzt und derzeit keine Pläne dazu hat, wiederholt ansprechen, entsteht der Eindruck, dass Sie mit älteren Technologien unzufrieden oder sogar verärgert wären. Es kann auch den Eindruck erwecken, dass Ihre Begeisterung für ein Produkt Sie für Alternativen blind gemacht hat.

Wenn Sie wirklich denken , Sie würden in einem nicht-LINQ - Shop glücklich sein, versuchen Sie zu fragen , was sie tun , verwenden und Ihre Antworten entsprechend zuzuschneiden. Zeigen Sie ihnen, dass Sie zwar LINQ bevorzugen, aber mit allen verfügbaren Tools kompetent sind.

Karl Bielefeldt
quelle
4
@MatthewPatrickCashatt Innerhalb von Methoden, die linq-Anweisungen enthalten, können Sie den Debugger nicht bearbeiten und fortsetzen. Es ist nicht genug von einer Abzweigung, dass ich es nicht benutze; aber es war der Hauptgrund, warum ich eine Weile gezögert habe.
Dan Neely
3
+1, insbesondere für den zweiten Absatz. Das trifft völlig auf mich zu, da ich völlig unglücklich wäre, an einem C # -Code zu arbeiten, ohne LINQ verwenden zu können.
Arseni Mourzenko
5
Hinzu kommt, dass neben der undichten Abstraktion häufig auch ein Performance-Hit zu verzeichnen ist. Sie tauschen Benutzerfreundlichkeit gegen Präzision aus, und dieser Präzisionsverlust umfasst häufig Details, die die Dinge schneller machen würden. Und je weiter Sie von der Quelle entfernt sind, desto mehr Details verlieren Sie und desto größer ist die Wahrscheinlichkeit, dass diese Details für die Leistung wichtig sind.
Jmoreno
6
+1 aber es kann auch anders funktionieren. Wenn mir jemand sagt, dass er mich nicht eingestellt hat, weil ich mit Yacc Parser baue, anstatt meine eigenen zu rollen, dann ist es sowieso kein Ort, an dem ich arbeiten möchte.
Spencer Rathbun
5
@MatthewPatrickCashatt: Diese Antwort (und mein Kommentar dazu) sind nicht spezifisch für LINQ, sondern allgemeine Aussagen. Aber für LINQ ist hier ein Auszug aus C # 4.0 / 5.0 in aller Kürze, der sich mit Leistungsproblemen bei LINQ befasst. Zurück zu den Allgemeingültigkeiten: In vielen Fällen wird sich der Leistungseinbruch lohnen, 5% +/- sind irrelevant. Aber manchmal wird es größer und manchmal ist sogar 0,1% nicht akzeptabel. Wenn Sie nicht glauben, dass es jemals ein Problem geben kann oder diese Leistung nur für Unternehmen wie Google gilt ...
jmoreno
29

Einige .NET-Programmierer, insbesondere solche mit klassischem VB / ASP- oder C ++ - Hintergrund, mögen keine neuen Inhalte wie LINQ, MVC und Entity Framework.

Basierend auf den Beobachtungen, die ich gemacht habe, werden die Ex-VB'er in dieser Gruppe wahrscheinlich immer noch Datenzugriffsschichten und anderen Code verwenden, der ursprünglich vor über 10 Jahren geschrieben wurde. Sie verwenden auch alte Schlagworte wie "n-tier" und dergleichen und verstehen überhaupt nichts über .NET Framework 2.0 und möchten auch nichts darüber lernen.

Die C ++ - Entwickler sind in der Regel akademisch orientierte Programmierer, die es lieben, coole Algorithmen zu programmieren, auch wenn dies bedeutet, das Rad neu zu erfinden. Sie hassen es, abhängig von irgendetwas, das sie nicht selbst ausgehändigt haben. Einige dieser Personen freuen sich darüber, dass sich die Befragten minderwertig fühlen, insbesondere diejenigen mit weniger traditionellem Hintergrund.

Wenn Sie ein Interview führen, werden Sie wahrscheinlich auf solche Organisationen stoßen. Sie werden jedoch auch einige kennenlernen, die neuere Methoden verwenden. Lassen Sie sich nicht von ein paar schlechten Interviews abschrecken.

jfrankcarr
quelle
2
Vielen Dank, jfrankcarr. Ich vermutete, dass dies der Fall sein könnte - es gab Fragen zum Öffnen und Schließen datareaders!
Matt Cashatt
2
+1 für den Aufruf von MVC "new stuff". Hat mich laut zum Lachen gebracht. Es gibt es schon seit den 70ern. Möglicherweise haben Sie MVVM gemeint, bei dem es sich im Wesentlichen um MVP (eine MVC-Variante) handelt, die Bindungen verwendet.
14
@ GlenH7 Ich denke es war aus dem Zusammenhang ziemlich klar, dass er das Produkt "ASP.NET MVC" meinte, nicht das Grundkonzept des Model-View-Controllers.
Carson63000
4
@ GlenH7 - Ich habe ausschließlich im Kontext der .NET- und Visual Studio-Produktlinie und der Produkt-Schlagworte von Microsoft gesprochen.
Jfrankcarr
6
Guter Gott, gibt es wirklich Läden, die Linq als "neu" betrachten? Es gibt es schon seit über 4 Jahren. Ich kann verstehen, dass ich mich nicht mit den Aufgabenerwartern, der Verwendung von dynamic/ ExpandoObject/ etc. Oder der Pflege von Azure und all den anderen Cloud-Inhalten beschäftigt habe. Ich kann sogar verstehen, dass ich weiterhin die WebForms-Ansicht der alten Schule verwende Engine in MVC oder Web Forms selbst oder Schreiben von WPF / WinRT-Code ohne MVVM ... aber Linq? Wenn Sie das noch nicht herausgefunden haben, ist es Zeit, Ihren Job als .NET-Entwickler zu beenden.
Aaronaught
16

Microsoft hat eine lange Tradition darin, heiße neue Technologien herauszubringen und diese in den nächsten 5, 10 oder 20 Jahren zu vergessen. LINQ könnte für manche Leute wie ein anderes aussehen. Sie werden feststellen, dass Microsoft SQL nicht ablehnen kann, LINQ jedoch möglicherweise Silverlight folgt . Es könnte also sein, dass Sie Paranoia sehen, die aus harten Erfahrungen resultiert, oder nur Leute, die von der modernen Technologie zurückgelassen wurden und diese ablehnen.

RalphChapin
quelle
12
Ehrlich gesagt, obwohl ich den Grundgedanken sehe, glaube ich nicht, dass Linq so schnell wie möglich verschwinden wird. Linq2SQL, ja, sie haben es zugunsten des viel mächtigeren EF abgelehnt. Aber Linq selbst ist das Fundament für so viele andere Neuerungen in den letzten 3 .NET-Versionen, dass sie, wenn sie es ablehnen, die Hälfte ihrer neuen Persistenzschicht-Technologie wie Azure und EF rückgängig machen würden, geschweige denn praktisch jeden ORM lähmen da draußen und eine Menge In-Memory-List-Verarbeitung außerdem.
KeithS
6
warte ... "erschrocken, weg von alter, veralteter Technologie, weil es funktioniert" ... WTF. Sind wir an einem Punkt angelangt, an dem erprobtes, verständliches, wartbares und ausgereiftes Arbeitsmaterial NICHT mehr gut ist?
gbjbaanb
7
@ gbjbaanb - Nr. Aber - als Anekdote - möchten Sie, dass ein Arzt Ihre Brustschmerzen mit einem Röntgenbild der Brust diagnostiziert, weil diese Methode „erprobt, getestet, verständlich“ ist, oder möchten Sie eine neuere fMRT, die jedoch eine höhere Auflösung aufweist , bessere Prognose und mehr Informationen? Niemand sagt, dass er sich hier von klassischen Prinzipien abwenden soll. ganz im Gegenteil. Sie sehen, LINQ (als Beispiel) baut auf diesen Prinzipien auf. Ich denke, wie andere bereits erwähnt haben, ist es das Erlernen der Teile, die LINQ ausmachen, und seine ordnungsgemäße Verwendung, die WTF-Momente wie Ihren auslösen.
Matt Cashatt
2
@MatthewPatrickCashatt: Hängt davon ab, ob der Arzt nicht für das Lesen der fMRT-Ergebnisse geschult wurde. Ich würde das Röntgenbild verwenden, anstatt eine Diagnose zu erraten. Wenn ich im Stauwasser krank würde, hätte ich lieber einen Arzt, der nur mit einem Stethoskop diagnostizieren kann, als ohne die neuesten Werkzeuge nicht zurechtzukommen.
gbjbaanb
2
@MatthewPatrickCashatt Ich verstehe Ihren Standpunkt, aber ein ausgleichender Faktor ist, dass Sie nicht jedem Trend folgen möchten, nur weil er neuer ist. Ich werde gerne einer neuen Technologie folgen, die in eine von zwei Kategorien passt. 1. Es reizt mich und ich bin bereit, meine Freizeit damit zu verbringen. 2. Es erweist sich als besser und scheint lange genug zu halten, um die Investition wert zu sein. Trends, die nicht in eine der beiden Kategorien passen, sind bestenfalls ein Glücksspiel.
TimothyAWiseman
15

Ist es nicht sinnvoll, Code "von der Stange" zu ziehen, wenn dieselben Ziele ohne zusätzliche Kosten erreicht werden?

Es gibt immer einen Aufpreis.

Die Lernkurve für Standardprodukte ist immer da. Der Schmerz, Updates (und Abhängigkeiten) zu bekommen, ist immer da. Die Unfähigkeit, mit den Eingeweiden herumzudrehen, ist immer da.

Für LINQ gilt eigentlich nur das erste. Viele Leute halten den "seltsam" aussehenden Code für schwer zu lesen und schwerer zu debuggen. Die SQL-artige Syntax ist so ziemlich eine Persona-Non-Grata für jeden professionellen Auftritt, an dem ich gearbeitet habe, seit er herauskam. LINQ to SQL (und andere Datenquellen) bieten eine Reihe von Fallstricken und eingeschränkten Optimierungsmöglichkeiten.

Dies sind die allgemeinen Argumente gegen Tools von Drittanbietern und speziell gegen LINQ. Trotzdem ist LINQ ein verdammt nützliches Tool und sollte in den meisten Situationen bevorzugt werden. Weinen hier nicht erfunden, und Abstraktionen sollten nicht stark von kognitiver Dissonanz bevorzugt werden .

Sie kennen LINQ nicht / können es nicht lernen, aber sie sind "offensichtlich" gute Entwickler, also muss sich LINQ nicht lohnen. Es ist eine häufige Falle.

Telastyn
quelle
1
Gute Argumente. Vereinbaren Sie die Kosten, die Sie erwähnen, und es ist eine gute Klarstellung. Im weiteren Sinne stellt die Entwicklung von Klassen, mit denen keine neuen Mitarbeiter vertraut sein können , weil sie nicht außerhalb der Organisation existieren, zusätzlich zu den Kosten für die primäre Entwicklung die gleichen Herausforderungen dar.
Matt Cashatt
2
@MatthewPatrickCashatt - Oh, absolut. Dieser einheimische Code sollte sich also fast immer mehr Mühe geben, um den gleichen Gewinn zu erzielen, muss aber nicht. Wie bei vielen anderen Dingen sollte der Preis / die Belohnung geschätzt und die beste Vorgehensweise bevorzugt und nicht blind befolgt werden.
Telastyn
@Telastyn Eigenentwickelter Code ist auch gut, da Sie wissen, was er tut, und ihn in Kürze beheben können. Sie können auch auf der Grundlage Ihrer eigenen Nutzung für bestimmte Umstände optimieren, nicht für jeden Durchschnittswert.
Hawken
13

Darüber hinaus sollten Sie berücksichtigen, dass Ihre Begeisterung für eine coole neue Technologie dazu führen kann, dass sich die Menschen unwohl fühlen und Sie nicht in der Nähe haben möchten. Sie "befähigen" sie nicht, weil Sie diese Technologie kennen, nicht sie. Selbst wenn sie es selbst nicht bemerken, suchen sie möglicherweise Kandidaten, die das verstärken, in das sie bereits so viel Zeit investiert haben.

Sie möchten eine Haltung präsentieren, die besagt: "Was auch immer Sie tun, ich möchte Ihnen dabei helfen, es zu erreichen", anstatt einen Untertext zu geben, der besagt: "Möglicherweise tun Sie Dinge auf eine schlechte Art und Weise, und wenn Sie mich dabei haben, wird dies beweisen es."

John Wiegley
quelle
+1 - sowie ihnen zu sagen, was Sie wissen, fragen Sie sie, was sie tun und worauf sie sich spezialisieren.
Kirk Broadhurst
12

Mein Standpunkt (und ich vermute, TBH, weil keiner von uns sagen kann, was diese Interviewer gedacht haben) ist, dass Sie oft zu einem Interview gehen, um zu erklären, warum sie Sie einstellen sollten, um sich in ihr Team und ihre Arbeitsweise einzufügen .

Sie können der perfekte Entwickler sein, ein Rock-Start-Codegott, aber das bedeutet absolut nichts, wenn das, was Sie tun möchten (betont durch übermäßiges und zu enthusiastisches Reden über einige coole Technologie-Gubbins), ihnen nur von Ihnen erzählt, und das würden Sie nicht passen in was sie wollen. Wenn sie über ein altes Datenzugriffssystem verfügen, das aus irgendeinem Grund nicht aktualisiert werden kann, brauchen sie niemanden, der vergessen hat, wie es zu warten ist. Wenn sie neue Produkte entwickeln und Sie diese coole neue Technologie wirklich überall einsetzen möchten, dann haben sie offensichtlich ein großes Problem mit der zukünftigen Pflege des Codes und / oder der Schulung des Personals.

Als Freiberufler ist dies ein weitaus größeres Problem, als wenn sie ein Permie einstellen würden. Mit der Erlaubnis, neue Arbeitsweisen zu trainieren und zu entwickeln, sind keine schlechten Dinge im Rahmen des bestehenden Codes und der bestehenden Praktiken - Sie werden lange Zeit da sein, um die Dinge zu verbessern. Mit einem Freiberufler geben sie wirklich nicht das, was Sie wollen, Sie sind nur da, um ihre Arbeit so zu machen, wie sie es wollen, und es ist nicht Ihre Aufgabe, etwas anderes zu tun. (Stimme nicht zu - werde ein fester Angestellter)

Es hat wahrscheinlich nichts mit LINQ selbst zu tun. Ich habe einen Kandidaten abgelehnt, der aufgetaucht ist und erklärt hat, wie viel besser alles in Haskell geschrieben werden würde. Wir machen kein Haskell. Gleiches gilt für alle Technologien, die nicht von der Firma verwendet werden. Normalerweise ist dies kein Problem, wenn Sie es als etwas Gutes bezeichnen. Das Problem entsteht, wenn Sie zu enthusiastisch und begeistert sind.

gbjbaanb
quelle
2
Ich stimme dem zu, aber ich habe viel mehr Leute bemerkt, die diese Einstellung nutzen, um gute Ideen zu verwerfen , die sie einfach nicht verstehen (z. B. Tests, Entwurfsmuster, ORMs). Obwohl ich der Meinung bin, dass eine gute Passform für das Team eine gute Sache ist, ist es wichtig zu erkennen, dass Sie möglicherweise besser als der Rest des Teams sind und Gleichgesinnte finden sollten, bei denen es nicht schlecht ist, gut zu wissen Abstraktionen.
Wayne Molina
1
@WayneM sicher, aber der OP ist ein Freiberufler, also ist es wirklich egal, ob er ein Kodierungsgott ist, es sei denn, sie sind bereit, ihn dauerhaft einzustellen, um den Code zu pflegen, den der Rest des Teams dann nicht versteht (hmm) er muss tun, was sie wollen, nicht was er will.
gbjbaanb
1
@WayneM Ebenso würden viele Leute etwas Ähnliches wie das, was Sie gerade gesagt haben, verwenden, um dafür zu werben, dass ihre Ideen über die eines anderen stehen (weil sie sicher sind, dass der Gesprächspartner es einfach nicht versteht). Am Ende sind beide Seiten voreingenommen, aber bei der OP geht es darum, eingestellt zu werden, und nicht darum, den großen DIY- / Abstraktionskrieg zu gewinnen. Jeder wird seine eigene Meinung haben, aber jemand muss darüber hinwegkommen. Ich vermute, es wird in diesem Fall nicht der Arbeitgeber sein. :(
Hawken
10

Es gibt eine berechtigte Sorge, die ich von denen gehört habe, die Linq nicht verwenden, und die ich mir zu Herzen nehme: "Nur weil Sie die Implementierung nicht sehen können, heißt das nicht, dass sie nicht teuer ist."

Nehmen Sie den folgenden Ausschnitt:

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

Die hier von LINQ initiierten kriechen. Warum? Denn nur weil dieser Code schön und elegant aussieht, heißt das nicht, dass er nicht fürchterlich ineffizient ist. Count () wertet mit einem Prädikat jedes Element der übergeordneten Aufzählung aus und fasst zusammen, wie oft das Prädikat true zurückgegeben hat. Dies ist also nicht nur N ^ 2 (wenn inputList und otherInputList ungefähr die gleiche Kardinalität haben wie N), sondern auch der absolut schlechteste Fall N ^ 2. JEDES Element von otherInputList wird für JEDES Eingabeelement durchlaufen. Der erste Schritt besteht stattdessen darin, Any () anstelle von Count zu verwenden, da dies genau das ist, was Sie wissen möchten, und es wird beendet, sobald bekannt ist, dass die Antwort "yes" lautet. Das Einrichten eines HashSets, in dem unterschiedliche Werte von gespeichert sind, otherInputListObject.OtherPropertykann ebenfalls hilfreich sein. Zugriff wird O (1) anstelle von O (N),Worst-Case- Komplexität statt quadratischer Best-Case- Komplexität.

Wir sehen also, dass diese netten, eleganten Methoden erhebliche Kosten verursachen, und wenn Sie diese Kosten nicht kennen, können Sie sehr einfach einen O- Komplexitätsalgorithmus (my GD) in den leistungsstarken zentralen Dateiserver Ihres potenziellen Arbeitgebers einprogrammieren oder Hauptlandeportalseite, wenn sie das nächste Mal eine Optimierung benötigen. Sie zu entlassen, nachdem Sie das getan haben, macht nicht rückgängig, was Sie getan haben, aber Sie nicht einzustellen, wenn sie glauben, dass Sie es tun würden, würde es verhindern. Um dies zu vermeiden, müssen Sie beweisen, dass sie falsch sind. Besprechen Sie, was diese Methoden tun (was bedeutet, dass Sie sich selbst kennen müssen) und ihre Komplexität, und wie Sie in einer effizienten Zeit (NlogN oder besser) zur Antwort gelangen.

Ein weiteres Problem ist das gute alte Argument "Wenn Ihr einziges Werkzeug ein Hammer ist". Versetzen Sie sich in die Lage des Interviewers, der diesen Linq-Fanboy interviewt. Der Kandidat mag Linq, will es benutzen, findet es das Beste, was es je gab. Es könnte sogar den Anschein haben, als könne der Kandidat ohne sie nicht codieren, da jedes gegebene Programmierproblem mit Linq gelöst wurde. Was passiert, wenn es nicht verwendet werden kann? Es gibt noch viel .NET 2.0-Code, der bei einem Upgrade schmerzhafte Upgrades auf Server, Benutzerarbeitsstationen usw. erfordert, sodass Sie Ihre ausgefallenen Erweiterungsmethoden verwenden können. Als Interviewer würde ich versuchen, Sie dazu zu bringen, zu zeigen, dass Sie eine effiziente Sortierung codieren oder die 2.0-Sortierungsmethoden verwenden könnten, wenn Sie müssten, egal wie sehr ich Ihnen zustimmen könnte, dass die Linq-Bibliotheken und ähnliche Erweiterungsmethoden hübsch sind Süss. Ein Interviewer, der den Punkt nicht versteht, könnte sich nicht einmal die Mühe machen, Sie dazu zu bringen, sich für etwas anderes zu eignen. Sie werden annehmen, dass Sie es nicht haben und weiterziehen.

KeithS
quelle
Warum würden Sie Ihre Anfrage nicht einfach als schreiben var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));? Ich hätte das vielleicht verpfuscht, aber mein Punkt ist, dass LINQ bessere Möglichkeiten hat, die oben erwähnte Abfrage auszuführen (.Join () ist eine andere Möglichkeit). Mir ist klar, dass es Möglichkeiten zur Verwendung von LINQ gibt, die möglicherweise nicht so effizient sind wie andere, aber das bedeutet nicht, dass Sie sich auf diese schlechten Implementierungen verlassen müssen.
Matt Cashatt
4
@MatthewPatrickCashatt Ich glaube nicht, dass es so wichtig ist, zu behaupten, dass LINQ immer ineffizient ist - während Sie eine bestimmte LINQ-Abfrage immer überbieten können, bieten einige Anwendungen eine bessere Leistung pro Entwicklerstunde als viele andere Ansätze. Vielmehr kann es relativ einfach sein , eine LINQ - Abfrage zu schreiben , das ist ineffizient und nicht erkennen , dass es, da die Ineffizienzen nicht so krass sind.
Jon Hanna
3
@JonHanna: Vielleicht mehr auf den Punkt gebracht, wird der Wert einer Abstraktion stark reduziert, wenn man untersuchen muss, welcher Code "wirklich" tut, um festzustellen, welche ungewöhnlichen, aber plausiblen Szenarien dazu führen können, dass die Leistung um viele Größenordnungen schlechter als erwartet ist. Wenn der Wechsel von einer Datenstruktur zu einer anderen dazu führt, dass Code 10.000-mal langsamer ausgeführt wird, ist die Möglichkeit, eine solche Änderung ohne Änderung eines anderen Codes vorzunehmen, möglicherweise nicht immer eine gute Sache.
Supercat
1
@supercat: ja und nein. Nur weil das Wissen darüber, wie etwas in einer Drittanbieterimplementierung getan wird, für das Verständnis der Auswirkungen auf die Leistung und das Vermeiden von Ineffizienzen von entscheidender Bedeutung ist, bedeutet dies nicht, dass die Bibliotheken, in denen diese Tools enthalten sind, einen geringeren Wert haben. Es sind zwei Seiten einer Medaille. Sie kennen die Art der Implementierung und können sie mit wenigen Tastenanschlägen verwenden, anstatt eine Stunde lang selbst zu arbeiten. Aber man muss beide Seiten kennen und den stereotypen Linq-Fan, der es für perfekt hält, nichts Falsches, verwenden Sie es für alles, was es wahrscheinlich nicht tut.
KeithS
@KeithS: Eine Sache, die meiner Meinung nach sowohl in Java als auch in .net schmerzlich fehlt, ist ein Standardmittel, um Objekte oder Sammlungen nach verschiedenen Dingen über sich selbst zu fragen. Zum Beispiel könnte Code, der eine Auflistung von Auflistungen erhält, davon profitieren, zu wissen, ob sich die Anzahl der Elemente und / oder die Reihenfolge der vorhandenen Elemente jemals ändern könnte, ob bekannt ist, dass die Anzahl der Elemente endlich oder unendlich ist (oder nicht bekannt ist, wie auch immer). und ob die Sammlung von Natur aus weiß, wie viele Elemente sich darin befinden. Technologien wie LINQ müssen oft Annahmen über solche Dinge treffen, die möglicherweise nicht korrekt sind, und ...
supercat
10

Dieser hat ein bisschen zu lange gedauert, aber es könnte für jemanden hilfreich sein, also werde ich es zulassen.

Ich bin tatsächlich auf etwas Ähnliches gestoßen, als ich letzten Monat etwas mehr als 20 Interviews durchlaufen habe (eine Mischung aus Telefon und persönlichem Gespräch). Es passierte definitiv etwas Unerwartetes, worauf ich nicht ganz eingehen konnte.

Eines der Dinge, die mir aufgefallen sind, war, dass die Dinge, die normalerweise im Mittelpunkt der Interviewzyklen der letzten fünf oder sechs Jahre standen, entschieden nicht besprochen oder kurz zusammengefasst wurden. Dinge wie die Grundlagen der OOP-Analyse / des Designs, Muster (sowohl Design als auch Architektur), einige der fortgeschritteneren / abstraktionsorientierten .net-Funktionen (einschließlich Lambdas oder LINQ, Generics, Serialisierung / Datenbindung und ähnliches) und sogar die In der Regel ein aktuelles Thema der bevorzugten Methodik (niemand schien sich für Agilität im Vergleich zu Wasserfällen oder den Geschmack von Agilität zu interessieren) und Tools oder die Wahl von ORM oder bevorzugten Mitteln für die Zusammenarbeit oder die Verwaltung der Quellcodeverwaltung. In einigen Fällen gar nicht erwähnt, in fast allen Fällen offenbar ohne Belang.

In mehreren Interviews und verschiedenen unabhängigen Unternehmen in unabhängigen Branchen wurden folgende Schwerpunkte gesetzt:

  • Eine seltsame Fixierung auf veraltete / veraltete Konventionen und Einschränkungen der "Zurück in die Steinzeit". Wie die Entwicklung einer primitiven Web-App in VS2003 mit einer Liste absurder Einschränkungen, die die Verwendung expliziter Funktionen in dieser Ära von .net weiter verbieten Das Paradigma und die Grenzen von vor 9 Jahren wurden durch unrealistische / willkürliche Zwänge weiter verkrüppelt. Ein anderer Ort war sehr hartnäckig in Bezug auf benutzerdefinierte Sammlungen, etwa vorgenerische Sammlungen. An einer anderen Stelle befand sich ein Codebeispiel eines Klassenmodells, das ich ausgearbeitet hatte, weil ich keine kaskadierten Konstruktoren verwendet hatte (sie schienen sich der Unterstützung für die Initialisierung von Eigenschaften bei der Deklaration nicht bewusst zu sein, die für den Bedarf ausreichte).

  • Extremer Fokus auf bestimmte Implementierungsdetails in einem Mikrokosmos und / oder Konfigurationseinstellungen, selbst bei Technologien, die sich darauf konzentrieren, plattform- oder protokollunabhängig zu sein (dh, der springende Punkt ist NICHT auf eine bestimmte Implementierung oder bestimmte Verwendung zu fixieren, sondern vielmehr bei Wiederverwendung / Wiederverwendung / Erweiterbarkeit / nach Bedarf Integration).

  • Bereitschaft, Arbeiten an und von einem Offshore-Team auszuarbeiten, zu überwachen, zu kodieren und anderweitig zu verlagern, und damit verbundene nicht-kodierende Fähigkeiten.

  • Verwendung bestimmter Versionen von Produkten / Plattformen / Modulen / usw. In einem manchmal absurden Ausmaß; "Also ... Sie haben die Versionen 1, 2 und 4 verwendet? Aber nicht 3, wie? Hmmm ... {kommentiert Ihren Lebenslauf mit" no v3 !!!} ". Der Grad der Nutzung schien keine Rolle zu spielen. nur , dass Sie haben oder etwas nicht verwendet überhaupt , und die spezifische Sache , die sie für auch fragen ... schien kein Ersatz zu zählen, auch von einem weit verbreiteten und voll konkurrierenden Produkt gekennzeichnet.

  • Ein weitaus größeres Augenmerk darauf, "wie gut Sie in unser Team passen" oder "wie gut Sie als Softwareentwickler wirklich sind" oder "haben Sie die Fähigkeiten und die Erfahrung, dem Unternehmen einen Mehrwert zu verleihen und uns dabei zu helfen, Qualität zu liefern Produkt "oder sogar" sind Sie ein gefährlicher Idiot, der in und Wrack-Shop kommen wird ". In einigen Fällen wurde mein Lebenslauf einfach als gegeben angesehen, und selbst der sogenannte "Tech Screen" oder das technische Interview war eine Persönlichkeitsbeurteilung, die weit mehr war als eine Kompetenzbeurteilung. Selbst für relativ kurzfristige Vertragspositionen, bei denen Sie vor dem Wechsel von zwei Spielzeiten wieder da und weg wären.

  • Die Unternehmen schienen sich diesmal weniger darauf zu konzentrieren, bestimmte technische Probleme zu lösen, neue Green-Field- oder große 2.0-Entwicklungsprojekte zu starten oder ein bestimmtes Produkt auf den Markt zu bringen, um aus einem aufkommenden Trend oder einer sich bietenden Gelegenheit oder den üblichen großen Kickoffs Kapital zu schlagen . Ein sich wiederholendes Thema, das mir an mindestens 15 Stellen auffiel, war, dass eine kleine Gruppe von 3-5 Entwicklern, die meistens den Marktabsturz von 08 überlebten, in den letzten drei Jahren ein Produkt schleifen konnte und stellten einen gewissen Erfolg fest oder ihr Unternehmen boomt insgesamt und sie stellen neue Mitarbeiter ein, um mit den steigenden Funktionsanforderungen Schritt zu halten oder die Konstruktionsmängel, die sie in diese Systeme eingebaut haben, zu beheben / überwinden oder die oben genannten Plattformen zu übernehmen, um sie freizugeben das Kernteam aufbauen, das es für "andere Projekte" gebaut hat.

Aber ... wenn ich etwas über dieses Geschäft weiß, ist es, dass es zyklisch ist. Das nächste Mal, wenn ich nach einem neuen Auftritt suche, werde ich mich nicht wundern, wenn sich das Spiel noch einmal geändert hat. Sie müssen nur geistig flexibel bleiben, aktiv zuhören, absolute Aussagen vermeiden, wenn sie unnötig sind, aber auch kein Wiesel sein und sich nicht als eindimensional herausstellen (Sie kommen als Idiot oder ein Eiferer, weder wünschenswert) noch als zu gut (es kann bedrohlich sein und einen Auftritt kosten).

Passen Sie einfach Ihre Herangehensweise an und versuchen Sie beim nächsten Mal, eine angemessenere Antwort zu geben. Nennen Sie einige verschiedene Möglichkeiten, wie Sie ein Problem angehen könnten. Aber selbst wenn es Ihnen klar ist, tun Sie so, als würden Sie tatsächlich darüber nachdenken und Begründen Sie es an Ort und Stelle. Auf diese Weise wirkt es bescheidener und weniger einschüchternd oder beleidigend.

Natürlich ist Murphy's Law genau das, was es ist. Das nächste Interview, nachdem Sie aufgehört haben, "leidenschaftlich über meinen aktuellen Lieblingstechniker" zu sein und eine ausgeglichenere / bartstreichendere Haltung einzunehmen, ist der Auftritt, den Sie bekommen hätten, wenn Sie der Verrückte gewesen wären Eiferer Kerl. ;)

Ähnliche neuere Erfahrungen
quelle
6

Ich denke, Sie ziehen eine falsche Schlussfolgerung, weil Ihre Stichprobenmenge zu begrenzt ist. Ich habe zwar einen beachtlichen Anteil von IT-Shops mit einer starken Abneigung gegen "dort nicht erfundene" 1 gesehen , aber keiner von ihnen würde Kandidaten aufgrund ihrer Präferenzen im Technologiestapel disqualifizieren: Sie waren zu Recht davon überzeugt, den richtigen Kandidaten zu unterrichten ihre einheimischen Bibliotheken.

Ich bezweifle ernsthaft, dass das Unternehmen die Verwendung von LINQ vollständig verboten hat. Eher wollten sie, dass du ihnen deine Fähigkeiten auf einer tieferen Ebene zeigst.

Eine Möglichkeit, herauszufinden, ob Sie Ihre Hash-Tabellen kennen, besteht darin, Sie aufzufordern, eine primitive Tabelle auf einem Whiteboard zu implementieren. Diese einfache Übung enthüllt dem Prüfer eine überraschende Menge an Daten über Ihr Wissen: Er erfährt sofort, ob Sie über Hash-Code / Equals Bescheid wissen und was Sie über Hash-Kollisionen wissen. Gleichzeitig ist es schwer vorstellbar, dass jemand, der bei klarem Verstand ist, eine Hash-Tabelle erneut implementiert, weil Microsoft einen so guten Job gemacht hat. Gleiches gilt für viele Algorithmen wie Sortieren und Suchen: Interviewer möchten häufig wissen, ob Ihr Hintergrund ausreicht, um Interaktionen auf niedriger Ebene zu verstehen, anstatt zu prüfen, ob Sie über ausreichende Kenntnisse der .NET-Bibliotheken verfügen.

Es ist fast sicher, dass sie darauf bestehen, dass Sie Bibliotheksimplementierungen anstelle Ihrer eigenen verwenden, wenn Sie für deren Unternehmen eingestellt werden. Aber während des Interviews würden sie Sie zum Low-Level-Code drängen, um ein besseres Verständnis Ihrer wahren Fähigkeiten zu erlangen.


1 Ein Shop ging so weit, sein eigenes, eher primitives Build-Tool zu bauen!

dasblinkenlight
quelle
2
Alle Ihre Argumente sind gut formuliert, aber ich sollte Ihnen etwas Farbe für das letzte Interview geben: Der Interviewer bestand darauf, dass LINQ "veraltet" sei. Ich fragte: "Meinst du nicht, dass MS nicht mehr in Linq-to-SQL investieren wird, sondern dass es Linq-to-Entities geben wird?" Nein, ich glaube nicht, dass er zu viel über LINQ wusste oder darauf bestehen würde, dass es verwendet wird.
Matt Cashatt
1
@MatthewPatrickCashatt Wenn jemand LINQ für LINQ2SQL in Bezug auf die veraltete Technologie verwirrt hätte, hätte ich mir eine dumme Ausrede ausgedacht, das Interview vorzeitig zu verlassen, und diese Firma nie zurückgerufen. Wenn das tatsächlich der Fall war, sollten Sie sich darüber freuen, dass sie Sie nicht
einstellen
1
100% sicher, dass dies der Fall war. Tatsächlich konnte ich nicht widerstehen, ihm ein paar Links zu schicken, um ihn auf den richtigen Weg zu bringen, nicht als Stich, da ich den Auftritt nicht bekam, sondern weil ich mich für ihn wirklich verlegen fühlte und hoffte, dass ich es könnte hilf ihm, nicht zweimal den gleichen Fehler zu machen;).
Matt Cashatt
4
Dann scheint dies weniger mit dem Technologie-Stack zu tun zu haben, als vielmehr mit der Tatsache, dass Sie ihn korrigiert haben. Die Leute wollen nicht korrigiert werden. Es ist nur die menschliche Natur. Wenn Menschen Entscheidungen wie die Einstellung von Menschen treffen, gehen 99% mit ihrer Intuition. Sie richten sich danach, ob Sie positive oder negative Emotionen hervorgerufen haben oder nicht. Das Korrigieren von ihm kann dazu geführt haben, dass er negative Gefühle verspürt. Und er assoziiert diese Negativität dann mit der Situation.
Kodierer
1
Ich weiß nicht, wie Hashtables intern funktionieren. Solche tiefgreifenden technischen Tests werfen Menschen mit einer praxisnahen Ausbildung aus dem Weg, die dennoch gute Kandidaten sind. Es scheint mir unnötig zu sein, von Leuten geringes Wissen zu verlangen, das sie niemals benutzen werden. Designprinzipien sind viel wichtiger geworden!
Tjaart
4

Ich glaube, Sie machen da einige verrückte Verallgemeinerungen des Typs "Ich habe in Schottland eine schwarze Kuh gesehen, also sind alle schottischen Kühe schwarz".

Wenn ich Sie interviewt hätte, wäre ich enttäuscht, wenn Sie meine Fragen nicht beantworten könnten.

Linq ist allerdings eine heikle Sache, viele Leute sehen es als Voodoo an, was unfair ist, da es eigentlich sehr einfach und umso klüger ist.

Ian
quelle
3

Um Devil's Advocate zu spielen, sind viele Entwickler einfach nicht an neuen Dingen interessiert und denken, dass alles mit selbst entwickelten (normalerweise minderwertigen) Tools gelöst werden muss. Es ist nichts Falsches daran, Abstraktionen zu verwenden. Verdammt, es gibt normalerweise keinen guten Grund , diese Abstraktionen nicht zu verwenden.

Es hört sich so an, als hätten Sie gerade ein Interview mit einem armen Entwickler geführt, der mit den Dingen nicht auf dem neuesten Stand ist und sich mit Hammer und Nagel an alles heranmacht. Dies sind die Entwicklertypen, die nichts über hilfreiche Open Source-Tools wie NUnit oder NHibernate oder die verschiedenen IoC-Container wissen. diejenigen, die versuchen, jedes Problem mit einem massiven gespeicherten Prozess in der Datenbank zu lösen; diejenigen, die absolut nichts über MVC wissen, obwohl es seit einigen Jahren nicht mehr erhältlich ist.

Wayne Molina
quelle
Sie können LINQ in einen Schlagwortpool werfen, der Nhibernate usw. enthält. Das würde ich nicht tun. Tatsächlich denke ich, dass Schlagworte unsere Unfähigkeit veranschaulichen, Abstraktionen in richtigen Ausdrücken zu erklären.
AndreasScheinert
Sie sprechen von "auf dem Laufenden halten" und ich denke, das Gegenteil wäre sehr viel angemessener. In der Vergangenheit wurden viele nützliche Konzepte entdeckt und verwendet, zum Beispiel DSLs. Es liegt an uns, unsere Kommunikation zu verbessern und Konzepte so zu verstehen, dass wir keine neuen Modewörter für alte Konzepte erfinden müssen.
AndreasScheinert