OO Design bezogene Fragen in technischen Interviews [geschlossen]

Ich habe in letzter Zeit an einigen Interviews teilgenommen und wurde von Unternehmen mehrmals gebeten, Fragen zum Entwerfen eines [Modells einfügen] zu beantworten.

1. Ist das heutzutage in der Branche normal? Ich bin seit mehr als zwei Jahrzehnten in der Software-Welt tätig und habe meinen Teil der Interviews besucht, aber ich sehe dieses Muster in Interviews, die erst vor kurzem aufgetaucht sind.
2. Ich denke, die Frage ist sehr offen. Zum Beispiel: Ich wurde gebeten, ein Klassendiagramm zu "Entwerfen eines Parkplatzes" zu zeichnen. Ich bin mir nicht sicher, welchen Detaillierungsgrad der Interviewer erwartet. Dies war ein Online-Test, bei dem ich ein Visio-Diagramm anhängen sollte, sodass ich sie nicht fragen konnte, welche Erwartungen sie hatten.
3. Verwenden Sie diese Art von Fragen in Ihrem Interviewprozess? Haben sie nur mit Klassendiagrammen zu tun oder fragen Sie auch nach Reihenfolge, Flussdiagrammen und ERDs (natürlich basierend auf der Art der Position)? Waren sie bei Ihrem Einstellungsprozess effektiv?

* Bearbeiten für Kevin Antwort *

Zum Beispiel: Eine vollständige Frage könnte lauten: "Entwerfen Sie ein Parkplatzverwaltungssystem, mit dem freie Parkplätze gefunden werden können".

Ich kann mit zwei Klassen durchgeführt werden, ParkingLotund Slotoder ich könnte weitermachen hinzufügen IVehicleund Vehicleund Carund MotorcycleKlassen. Wo zeichne ich die Linie?

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

1. Bis zu einem gewissen Grad ja. Jeder kann Syntax rezitieren oder sich durch eine Lösung kopieren / einfügen. Wir wollen Leute einstellen, die Probleme lösen können.

2. Sie erwarten, dass Sie das Design ausreichend dokumentieren, damit sie es verstehen können (und nicht mehr als das).

3. Ich frage die Leute, wie sie das XYZ-Problem lösen würden, ja. Normalerweise beschreiben sie es nur mündlich. Ich möchte sehen, ob sie Fragen stellen, um die Anforderungen zu klären. Ich möchte sehen, wie sie mit anderen Programmierern kommunizieren. Ich möchte sehen, ob sie auf den Beinen denken können.

Es war hilfreich für mich. Ich möchte keine Code-Affen, ich möchte Software-Ingenieure.

Ich finde diese Fragen ziemlich albern. Die wahre Antwort lautet: "Was sind die Anwendungsfälle?" Ohne Anwendungsfall ist kein Design erforderlich. Hier ist zum Beispiel eine vernünftige Antwort auf die Parkplatzfrage:

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

Es erfüllt einen offensichtlichen Anwendungsfall.

Sie demonstrieren tatsächlich eine Verwendung dieser Frage in Ihrer Bearbeitung, bei der Sie kein funktionsfähiges Modell entwerfen.

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

Sie erwähnen auch die Schaffung Carund MotorcycleKlassen, die ohne weitere Prüfung nicht viel Sinn machen. Ihr Design profitiert nicht davon, dass es Unterklassen hat Vehicle. Wenn Sie sich Motorcycleohne Verhaltensunterschiede vorstellen Vehicle, würde ich es als Fehlschlag ansehen.

Wenn Sie das einzelne VehicleProblem nicht erkannt hätten, wären wir so ziemlich in einem Live-Interview erledigt. Wenn Sie das korrigieren würden (möglicherweise indem Sie das a machen List<IVehicle>), würde ich dies als Ausgangspunkt verwenden, um die Entwicklung Ihres Designs zu betrachten. Es gibt einen Grund, warum die Anforderungen grundlegend sind, und es gibt keine genau definierten Anwendungsfälle - so funktioniert die Welt.

Ich werde Sie vielleicht mit der neuen Forderung konfrontieren, dass "zwei Motorräder in einem Slot parken können", um zu sehen, wie Sie Ihr Design weiterentwickeln würden, um damit umzugehen. Dann haben wir vielleicht ein Gespräch über Parallelität (Was ist, wenn wir zwei Eingänge haben und zwei Autos gleichzeitig vorfahren - wird Ihr Design scheitern? Wie? Was können wir tun, um es zu beheben?). Andere mögliche Wege zu erkunden wären, wie zugewiesenes Parken, Gebühren für das Parken, Gebühren pro Reihe (möglicherweise zahlen engere Reihen mehr), zeitlich begrenztes Parken und das Auffinden von Tätern usw. usw. implementiert werden.

Ich würde auch Ihren Denkprozess in Bezug auf Parkplätze als Hinweis auf Ihre allgemeine Fähigkeit betrachten, ein Problem intelligent zu analysieren. Wenn Sie mich nach grundlegenden Anwendungsfällen fragen müssen und / oder Sonderfälle entwickeln müssen (wie 2 für 1-Sonderfälle beim Parken), wird mir allmählich unangenehm, dass Sie noch nie zuvor einen Parkplatz benutzt haben und dass wir es sind Es wird schwierig werden, über etwas etwas Kompliziertes zu kommunizieren.

Ich habe diese Fragen gestellt, als wir Klassendiagramme für die Codegenerierung erstellt haben. Ich mache es immer noch gelegentlich, aber nicht routinemäßig. Ich mag die Frage, weil ich sehen kann, wie die Person nachdenkt.

Es soll unbefristet sein. Das ist okay. Es gibt keine richtige Antwort. Ich habe keine Antwort im Kopf. Ich möchte sehen, wohin es führt. Ich denke, es ist eine bessere Frage, persönlich zu fragen, nicht "E-Mail als Antwort". Es geht um Kommunikation, Annahmen und Interaktion; nicht nur eine Antwort!

1. Ich habe diese Art von Interviews vor mindestens 12 Jahren gesehen. Es ist der Ansatz, den ich in den letzten 6 Jahren verwendet habe. Die Erfahrung zeigt, dass es bessere Kandidaten für den Job auswählt, als 20 Fragen zu stellen, und ihnen eine Punktzahl von 20 Ansatzpunkten gibt.

2. Auch hier würde ich es sehr offen auslegen. Ziel ist es, dem Kandidaten Raum zu geben, um seine Fähigkeiten unter Beweis zu stellen. Ein Kandidat zu haben, der zu diesem Zeitpunkt relevante Fragen stellte, wäre ein Plus. Da ein Kandidat gute Annahmen trifft, aber darauf hinweist, dass es sich um Annahmen handelt, die vor der Implementierung überprüft werden müssen.

3. Ich fordere alle potenziellen Mitarbeiter auf, die Fähigkeiten, die sie für den Job benötigen, beim Vorstellungsgespräch unter Beweis zu stellen. Für Programmierer müssen sie Code implementieren und über ihr Design dafür sprechen. Es ist sehr effektiv, um Fehleinstellungen zu verhindern, aber Sie sollten beim Vorstellungsgespräch auf eine Ausfallrate von 90% vorbereitet sein.

Das Entwerfen eines kleinen Systems ist eigentlich eine sehr relevante Aufgabe, die Sie in einem Interview stellen sollten. Es zeigt, wie gut Sie in der Lage sind, eine gute Softwarelösung für ein Domain-Problem zu finden.

Ich finde es jedoch seltsam, nur darum zu bitten, ein Klassendiagramm ohne menschliche Interaktion online zu stellen:

• Sie werden das Wesentliche vermissen - die Argumentation hinter dem Diagramm und was Sie dazu gebracht hat, Dinge auf diese Weise zu entwerfen.
• Es gibt keine "Brüstung", die den Bewerber davon abhält, zu weit zu gehen. Wenn Sie eine endgültige Implementierung im Diagramm widerspiegeln, werden Sie wahrscheinlich Dutzende von Klassen und ein nicht lesbares Schema haben.
• Das Zeichnen eines UML-Klassendiagramms ist keine wesentliche Fähigkeit, sondern nur eine OO-Notation. Die Fähigkeit, solide Designs zu erstellen, ist.

In einem Live-Interview wären die idealen Schritte, die ein Kandidat unternehmen sollte:

• Sprechen Sie mit dem Personalvermittler über das Problem und fangen Sie an, mündlich eine grundlegende Lösung auszudrücken, Fragen zu stellen und Anpassungen vorzunehmen, wenn der Personalvermittler genauere Anforderungen stellt.
• Stellen Sie sich auf und skizzieren Sie eine Gesamtansicht des Systems und das Zusammenspiel der Komponenten. Könnte der reinste Stil von UML sein, könnte nur Kästchen und Kreise sein.
• Schreiben Sie einen Test, entweder einen Test mit hoher Akzeptanz oder einen Komponententest für eine der Komponenten / Klassen.
• Beginnen Sie mit dem Schreiben der entsprechenden Implementierung.

Hoffentlich hat der Personalvermittler irgendwann genug Informationen über die Fähigkeiten des Bewerbers gesammelt und nennt es einen Tag. Das Ziel ist nicht, eine voll funktionsfähige Lösung zu implementieren (es sei denn, es handelt sich um einen dieser unbezahlten Dienste in Verkleidungsinterviews).

Die OOP-Fragen sind offen. Es gibt keine richtige oder falsche Antwort, aber es gibt einige Prinzipien, die von den Interviewern erwartet werden (wie die Verwendung eines Konstruktors zum Initialisieren von Variablen, das Kleinhalten Ihrer Methoden, die Verwendung von Kapselung / Komposition / Polymorphismus / Vererbung, falls zutreffend, usw.).

Erwarten Sie in Interviews immer Datenstruktur-, OOP- und datenbankbezogene Fragen, sie sind sehr häufig. Bücher wie "Cracking the Coding Interview" und "Programming Interviews Exposed" können Ihnen bei der Vorbereitung helfen.

Ich war vor nicht allzu langer Zeit nach einem Entwurf für einen Parkplatz gefragt worden. Ich habe zunächst keine Use Cases erhalten, aber später ein paar erwähnt. Ich glaube, mein Design passte nicht zu den Vorstellungen des Interviewers. Ich bin damit einverstanden, dass jedes Softwaredesign nur für einen bestimmten Anwendungsfall gültig ist. Zurück zu dieser Interviewfrage glaube ich, dass mein Interviewer keine wirkliche Designerfahrung hatte. Diese Leute glauben zu wissen, wonach sie fragen. Es ist eine andere Geschichte, ob das tatsächlich wahr ist oder nicht.