Warum ist die Frage „Gib fünf Dinge, die du an C # hasst“ während eines Interviews so schwer zu beantworten? [geschlossen]

In Podcast 73 diskutieren Joel Spolsky und Jeff Atwood unter anderem "fünf Dinge, die jeder an seiner Lieblingsprogrammiersprache hassen sollte":

Wenn Sie mit Ihrer aktuellen Werkzeugkette zufrieden sind, müssen Sie nicht umsteigen. Wenn Sie jedoch nicht fünf Dinge auflisten können, die Sie an Ihrer bevorzugten Programmiersprache hassen, dann wissen Sie das wohl noch nicht gut genug, um es beurteilen zu können. Es ist gut, sich der Alternativen bewusst zu sein und ein gesundes kritisches Auge für alles zu haben, was Sie verwenden.

Da ich neugierig war, stellte ich diese Frage jedem Kandidaten, den ich interviewte. Keiner von ihnen war in der Lage, mindestens eines zu zitieren, das sie an C # ¹ hassen.

Warum? Was ist an dieser Frage so schwierig? Ist es wegen des stressigen Kontextes des Interviews, dass diese Frage von den Befragten nicht beantwortet werden kann?

Gibt es etwas an dieser Frage, das es schlecht für ein Interview macht?

Das heißt natürlich nicht, dass C # perfekt ist. Ich habe selbst eine Liste von fünf Dingen, die ich an C # hasse:

• Das Fehlen einer variablen Anzahl von Typen in Generika (ähnlich wie paramsbei Argumenten).
  Action<T>,
  Action<T1, T2>,
  Action<T1, T2, T3>,
        ⁞ Ernst ?!
  Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>
  

• Die fehlende Unterstützung für Maßeinheiten, wie in F #.

• Das Fehlen von schreibgeschützten Eigenschaften. private readonlyJedes Mal, wenn ich eine schreibgeschützte Eigenschaft haben möchte, ist es langweilig, ein Hintergrundfeld zu schreiben .

• Das Fehlen von Eigenschaften mit Standardwerten. Und ja, ich weiß, dass ich sie im parameterlosen Konstruktor initialisieren und von allen anderen Konstruktoren aufrufen kann. Aber ich will nicht.

• Mehrfachvererbung. Ja, das führt zu Verwirrung und wird in den meisten Fällen nicht benötigt. Es ist in einigen (sehr seltenen) Fällen immer noch nützlich, und die Verwirrung trifft auch auf die Klasse zu (und wurde in C # behoben), die mehrere Schnittstellen erbt, die Methoden mit demselben Namen enthalten.

Ich bin mir ziemlich sicher, dass diese Liste alles andere als vollständig ist, und es gibt viel mehr Punkte hervorzuheben, und vor allem viel bessere als meine.

^{¹ Einige Leute kritisierten einige Assemblys in .NET Framework oder das Fehlen einiger Bibliotheken im Framework oder kritisierten die CLR. Dies zählt nicht, da die Frage sich auf die Sprache selbst bezog und ich möglicherweise eine Antwort auf etwas Negatives im Kern von .NET Framework akzeptieren konnte (zum Beispiel die Tatsache, dass es keine gemeinsame Schnittstelle für gibt TryParse, also wenn Wenn Sie eine Zeichenfolge in mehrere Typen unterteilen möchten, müssen Sie sich für jeden Typ wiederholen.) Eine Antwort zu JSON oder WCF ist völlig inaktiv.}

Wenn ich raten müsste:

1. Einige Programmierer verfügen nicht über eine vielfältige Sprachkenntnis. Es ist schwer, Dinge falsch mit der Sprache zu sehen, wenn man nicht weiß, dass es bessere Dinge gibt.

2. Einige Programmierer sind reine Code-Affen. Sie analysieren kaum die Probleme, geschweige denn, wie ihre Programmiersprache besser sein könnte.

3. Nur wenige Menschen sind besonders kritisch. Sie sehen Vorteile und Merkmale, keine Mängel. Es fällt ihnen schwer, in diese Denkweise zu wechseln, wenn das Interview nicht so verläuft.

4. Zumindest hier in der Gegend wird es als fataler Persönlichkeitsfehler angesehen, übermäßig kritisch zu sein. Anstatt "dieser aufschlussreiche Entwickler zu sein, der immer nach besseren Wegen sucht, Dinge zu tun" (wie in einigen Gegenden, in denen ich gelebt habe), sind sie "das Arschloch, das alles hasst". Sogar Leute, die an Dinge denken können, die sie in der Sprache hassen, könnten sich in einer Interview-Einstellung dahingehend verschieben, dass sie weniger bitter wirken.

Ich würde mir vorstellen, dass die Frage während eines Interviews so schwer zu beantworten ist, weil sie:

1. Wirklich unerwartet,

2. Erfordert viel Nachdenken und ein Denken auf eine ganz andere Art als im Interview.

3. Ist im Allgemeinen in kurzer Zeit schwer zu beantworten (sofern nicht vor dem Vorstellungsgespräch vorbereitet).

1. Es ist unerwartet

Unerwartete Fragen sind wirklich schwierig, insbesondere in einem stressigen Kontext. Stellen Sie sich den folgenden Dialog während eines Interviews vor:

- Was ist der Unterschied zwischen HashSet<T>und List<T>?
- Das Hashset ist so optimiert, dass die Suche nach einem Element sehr schnell ist. Wenn Sie beispielsweise häufig set.Contains()innerhalb einer Schleife arbeiten, kann das Verschieben setvon der Liste zum Hashset die Arbeit beschleunigen.
- Wie erstellen Sie eine schreibgeschützte Eigenschaft?
- Ich verwende ein Feld, das als readonlyHintergrundfeld für eine Eigenschaft markiert ist, die nur einen Getter enthält.
- Wofür wird es verwendet sealed?
- Sie verwenden es für Klassen, die nicht vererbt werden dürfen.
- Was war das letzte Mal, dass Sie einen Zahnarzt gesehen haben?
- Was ?!

2. Es erfordert viel anderes Denken

Wenn Sie allgemeine Fragen zum Interview stellen, verwenden Sie Ihr Gedächtnis, um sich daran zu erinnern, was Sie aus Büchern oder aus Ihrer Praxis über die Sprache und das Framework gelernt haben. Sie denken vielleicht ein bisschen nach, um eine Antwort zu finden, aber nicht zu viel.

Andererseits erfordert die Frage nach den fünf Dingen, die Sie hassen, ein tieferes Nachdenken. Sie können sich nicht einfach an etwas erinnern, was Sie aus Büchern gelernt haben, und Sie können nichts analog finden. Anstatt passiv zu sein, muss man kritisch sein und herausfinden, was in der von Ihnen verwendeten Sprache unangenehm sein kann.

3. Es braucht Zeit

Ehrlich gesagt habe ich meine Liste mit fünf (eigentlich mehr) Dingen, die ich an C # hasse, aber ich habe lange darüber nachgedacht. Einige Dinge stammen aus der .NET Framework 2-Ära. Die meisten Probleme, die ich für .NET Framework 2 aufgelistet habe, sind nicht mehr gültig, da sie entfernt wurden, einige mit LINQ und all diesen Funktionen für die Programmierung, andere mit dynamischer Programmierung. Ich bin mir nicht sicher, ob ich ohne Vorbereitung dieser Frage alle fünf Elemente während eines Interviews finden könnte.

Ich denke, dass es wegen des Wortes fünf schwierig ist . Und in geringerem Maße wegen des Wortes Hass .

Fünf ? Was ist, wenn Sie nur mit vier kommen? Haben Sie die Frage nicht beantwortet? Was ist, wenn Sie mehr als fünf haben? Jetzt müssen Sie vor Ort herausfinden, welche der fünf am besten geeignet sind.

Hass ist ein sehr negatives Wort. Es ist die Art von Negativität, die in Interviews vermieden werden soll. Außerdem denke ich , es zu viele Leute merkwürdig klingen würde , dass viele Dinge zu haben , sie „hate“ über eine Sprache werden sie den ganzen Tag Programmierung in verbringen Manche Leute sogar könnte denken , es ist ein Trick Frage ist:. Wenn sie tatsächlich tun kommen Mit fünf Dingen werden sie disqualifiziert, weil sie C # zu sehr hassen, um gut programmiert zu werden. Leider ist diese Art von perverser Trickfrage in Interviews nicht ungewöhnlich.

Stattdessen könnten Sie sich fragen: Was würden Sie an C # verbessern, wenn es an Ihnen liegen würde? Auf diese Weise kann der Befragte mit einer beliebigen Anzahl von Dingen antworten. Diese Formulierung tauscht auch die Negativität des Wortes "Hass" gegen das relativ positive "Verbessern" aus.

• Die meisten Kandidaten beschäftigen sich nicht so intensiv mit mehr als einer Sprache oder einem Paradigma, um einen Kontrast zu schaffen . Ich habe seit über 5 Jahren nicht mehr mit einer anderen objektorientierten Sprache gearbeitet und mit der, in der ich gearbeitet habe (PowerBuilder), hatte ich viel zu tunvon Hülsen mit. Die meisten Jungs, die gerade ihr Studium beendet haben (oder glauben, dass sie es sind), sind in einer, vielleicht zwei Sprachen heiß und haben drei oder vier weitere "Exponate" erhalten (was bedeutet, dass sie mindestens eine Hausaufgabe abgeschlossen haben, die dies erfordert, aber weniger als ein ganzes Semester natürlich studieren). Das ist nicht genug Wissen oder Erfahrung, um wirklich zu wissen, was mit der Sprache falsch ist. Holen Sie sich einen Job in der realen Welt, und dieser Fokus verengt sich erheblich; Sie lernen viel mehr über die Sprache, mit der Sie den Gehaltsscheck erhalten, als jede andere, und dabei akzeptieren Sie, was die Sprache nicht oder auf seltsame Weise tut, bis zu einem Punkt, an den Sie sich nicht mehr erinnern können anders machen.

• Die meisten C # -savvy Kandidaten, die es mit Java / C / C ++ vergleichen, sind ziemlich zufrieden damit . C # wurde von Grund auf dafür entwickelt, viele Dinge besser zu machen als Java (Ereignisse, Rückrufe, die Grafikbibliothek, Datenbankarbeit). Java wiederum war benutzerfreundlicher und konzentrierter auf korrekten Code als C ++. Ich habe noch keinen C # -Programmierer kennengelernt, der in einer Umgebung, in der es nicht unbedingt auf Leistung und Steuerung auf Schaltungsebene ankommt, auf C ++ zurückgreifen möchte.

Mit anderen Worten, See-Sharpers haben es in jeder Hinsicht ziemlich gut.

Hier ist meine Liste:

• Lambda-Aussagen nicht beobachtbar / auswertbar . Aufrufe von benannten Methoden können in die VS-QuickWatch eingesteckt werden. So können Ausdrücke. Aber Lambdas? Nein (zumindest nicht in VS2010). Macht das Debuggen von Linq-Ketten zu einer echten Aufgabe.

• Optionale Parameterwerte für andere Referenztypen als string können nur null sein . Wenn ich einen Überlastungsstapel erstellt habe, möchte ich möglicherweise andere Standardeinstellungen verwenden. Möglicherweise kann ich einen Wert basierend auf einer Eigenschaft oder einen einfachen Ausdruck basierend auf einem anderen Parameter als Standard festlegen. Aber ich kann nicht Der Wert, keinen Überlastungsstack erstellen zu müssen (was bei einem Refactoring-Assistenten wie ReSharper für die Handhabung der Boilerplate von untergeordneter Bedeutung ist), sinkt, wenn die Optionen für die optionalen Parameter so drastisch eingeschränkt sind.

• C # wird alt genug, um ernsthafte Probleme mit älteren Codes zu haben . Code, der ursprünglich für 1.1 geschrieben wurde, würde dazu führen, dass jeder, der an 4.0 gewöhnt war, vor Entsetzen zusammenzucken würde. Sogar 2.0-Code lässt viel zu wünschen übrig. Gleichzeitig sind Bibliotheken von Drittanbietern hinzugekommen, die Dinge wie ADO.NET so primitiv erscheinen lassen (und ein Großteil des "verbundenen Modells" von ADO.NET ist jetzt ein großes Anti-Pattern). Aus Gründen der Abwärtskompatibilität wird die Unterstützung dieses alten, schlechten Codes von .NET jedoch nicht unterstützt, und es wurde nie gewagt, etwas wie "ArrayList war ein beschissener Weg, dies zu tun, es tut uns leid, dass wir es jemals eingegeben haben und wir nehmen." Verwenden Sie stattdessen List, und wenn Sie eine Liste mit unterschiedlichen Typen unbedingt benötigen, deklarieren Sie sie als List<Object>.

• Ernsthaft eingeschränkte Switch-Anweisungsregeln . Wahrscheinlich ist eines der besten Dinge, die ich über PowerBuilder sagen kann, dass die Choose Case-Anweisung (äquivalent zu switch) Boolesche Ausdrücke basierend auf der Variablen zulässt. Dadurch konnten switch-Anweisungen auch dann ausgeführt werden, wenn sie Code enthielten. Ich verstehe die Gründe, warum diese zweite nicht erlaubt ist (es ist eher ungewollt als absichtlich), aber es wäre trotzdem schön, von Zeit zu Zeit eine Erklärung zu schreiben wie:

  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;
  }

• Keine numerische Schnittstelle . Wenn es eine Zahl ist, können Sie damit rechnen. In vielen Fällen muss sich die eigentliche Methode nicht genau darum kümmern, welche Typen angeschlossen sind. Präzision liegt in der Verantwortung des Anrufers. Es ist jedoch nicht möglich, eine generische Methode oder Klasse zu erstellen, die nur Zahlentypen als GTP akzeptiert.

Ich würde vorschlagen, dass ein Teil des Problems die Angst vor einer schlechten Antwort ist - Sie sagen, Sie hassen X, der Interviewer liebt X oder Sie denken, dass Ihr Grund für den Hass auf X idiotisch ist.

Es ist wahrscheinlich auch etwas, worüber die meisten Leute nicht wirklich nachgedacht haben. Sie haben aktuelle Probleme und frühere Probleme. Frühere Probleme, die durch die Sprache verursacht wurden, sind vorbei. Daher denken die Leute hauptsächlich an die Lösung und nicht an das Problem, da dies bedeutender ist. Nur wenige werden ein aktuelles Problem haben, das durch die Sprache verursacht wird.

Für ein Interview würde ich nur 1 oder 2 verlangen, aber ich stimme zu, wenn Sie keine Einschränkungen des von Ihnen verwendeten Tools nennen können, dann wissen Sie es wahrscheinlich nicht sehr gut. Wir stellen genau diese Frage zu SSIS und es hilft wirklich, die Spreu vom Weizen zu trennen. Jeder, den wir angeheuert haben und der diese Frage gut beantwortet hat, hat sich zu einem großartigen Mitarbeiter entwickelt. Wir brauchen Leute, die über fortgeschrittenes Wissen verfügen, nicht jemanden, der es ein paarmal angeschaut hat. Und ich wette, dass du das auch willst.

Ich denke, es ist eine berechtigte Frage und die Tatsache, dass so viele sie nicht beantworten konnten, ist nur ein Beispiel dafür, wie arm viele der Kandidaten für Jobs wirklich sind. Wenn jemand nicht analytisch genug ist, um einige Einschränkungen des Tools herauszufinden, wie kann er dann jemals analytisch genug sein, um schwierige Programmierprobleme zu lösen?

Es kommt darauf an, wie Sie sagten, mangelnde Erfahrung mit C # und / oder mangelnde Kontaktaufnahme mit anderen Sprachen. Ich habe eine Reihe von Entwicklern interviewt, die sich für Senioren hielten und einige Fragen nicht beantworten konnten, die ihnen selbst ein kleiner Kratzer auf der Oberfläche von C # hätte verraten sollen.

Wenn Sie nicht genug graben, werden Sie die Grenzen der Sprache nicht erreichen und wünschen, dass sie weg sind. Meine Top Five für den Fall, dass sich jemand wundert

1. Die Erstellung unveränderlicher Objekte erfordert viel Zeitaufwand (im Gegensatz zu einer funktionalen Sprache, in der Objekte standardmäßig unveränderlich sind).
2. Metaprogrammierung ist schwierig. Vergleichen Sie die Typausgabe mit Lisp-Makros. (Compiler Services werden in Zukunft sehr hilfreich sein).
3. Erweiterungsmethoden sind großartig ... Erweiterungseigenschaften und Erweiterungsoperatoren (speziell implizite und explizite Operatoren) wären besser.
4. Explizite Casts werden nicht zur Laufzeit, sondern zur Kompilierungszeit aufgelöst.
5. No Sequence Matching ist so viel übersichtlicher als das Überladen von Funktionen.

Ich denke in seiner Art, wie er sagt; Wenn du denkst, dass es kaputt ist, verstehst du wahrscheinlich nicht, warum es so ist, wie es ist. Möglicherweise haben Sie ein Loch in Ihrem Wissen.

Ironischerweise verpassen Interviewer, die glauben, sie zitieren "den großen Joel", indem sie das als Interviewfrage verwenden, wahrscheinlich eher den Punkt.

Sie könnten auf Antwort zögern, weil sie den Eindruck haben , könnten, wenn sie können 5 Dinge auflisten sie über eine Sprache hassen die Interviewer könnte sich umdrehen und sagen : ‚Oh, wir suchen C #‚Ninjas‘und Sie scheinen nicht um die Sprache zu mögen "oder" Warum haben Sie sich für den Job beworben, wenn Sie die Sprache nicht mögen? "

Die Befragten stehen unter großem Druck, während der Befragungen positiv zu bleiben.

Weil Sprachen unser Denken prägen . Durch die tägliche Verwendung von C # haben Sie es sich zur Gewohnheit gemacht, Ihren Code so zu denken und zu gestalten, dass die Probleme der Sprache auf natürliche Weise umgangen werden.

Sie tun es jetzt ohne nachzudenken, ohne zu wissen, dass Sie es tun. Aus diesem Grund ist es so schwierig herauszufinden, was die schlechten Dinge sind. Zweifellos haben Sie an dem Tag, an dem Sie angefangen haben, C # zu lernen, viele Probleme festgestellt, aber jetzt sehen Sie sie nicht mehr. Gewohnheiten sind mächtige Dinge. Denkgewohnheiten, noch mehr .

Die positive Seite davon ist, wenn es schwierig ist, die Fehler in C # aufzulisten, muss es sein, dass Sie ein guter C # -Programmierer sind, die Sprache mögen und sie mehr als andere Sprachen verwenden.

Wenn Sie jedoch die Fehler in C # besser erkennen möchten, müssen Sie Ihre Denkweise ändern. Lerne mehr Programmiersprachen und gewöhne dich an sie. Streben Sie die unterschiedlichsten Sprachen an. Sie sind es gewohnt, statisch zu tippen? Versuchen Sie es mit Python oder Ruby. Sie sind objektorientiert und imperativ gewöhnt? Haskell ist eine ganz andere Welt.

Und wenn Sie zu C # zurückkehren, werden Sie fragen: "Warum brauche ich hundert Zeilen C #, um diese einfache Sache zu tun, die nur eine Zeile in Haskell ist?". Sie werden eine Menge Dinge über C # hassen.

• C # verfügt nicht über nicht nullfähige Referenztypen.
• Keine algebraischen Datentypen.
• Keine Stringinterpolation.
• Die Syntax ist überall zu ausführlich.
• Kein Makrosystem.
• Die Typinferenz ist begrenzt.
• Keine regulären Literale.
• Keine strukturelle Typisierung.
• Schlechte Unterstützung für Unveränderlichkeit.
• C # -Strukturen sind fehleranfällig.
• Die Standardbibliothek ist sehr begrenzt.
• Einschränkungen für Parameter von Konstruktoren können nicht definiert werden.
• Kann nicht generisch mit Einschränkungen für mathematische Operatoren programmieren.
• Kein "neuer Typ".
• Kein Array-Slicing, kein Range-Literal.
• Die Funktionen listen nicht die Nebenwirkungen auf, die sie als Teil ihres Typs verursachen können. :)

(Natürlich kann keine Sprache alles haben. Das Sprachdesign ist extrem schwierig, und es kann nicht funktionieren, alle Funktionen in dieselbe Sprache zu integrieren. Verschiedene Tools für verschiedene Zwecke.)

Ja, die Frage ist schwer zu beantworten, besonders während eines Interviews. Aber Leute, die darauf antworten können, beweisen, dass sie darüber nachgedacht haben, dass sie eine Perspektive haben.