Architekturaufgabe für Interview für Go und Java

Architektur-Interview-Herausforderung: Testen von Entwicklungsdenken

Diese Aufgabe prüft das Verständnis der SOLID-Prinzipien, des SRP und der Systemflexibilität. Kandidaten sollen eine bestehende Struktur zur Gehaltsberechnung von Mitarbeitern (oder eine Klasse) erweitern, die zusätzlich einen PDF-Bericht generiert, um Führungskräfte zu berücksichtigen. Wichtige Einschränkungen: gleiche KPI- und Bonusprozentsätze bezogen auf das Grundgehalt, aber Führungskräfte haben ein höheres Grundgehalt. Das System muss zukünftige Änderungen mit minimalen Störungen unterstützen.

Für Go bedeutet dies die Erstellung einer Struct; bei klassenbasierten Sprachen eine Klasse. Obwohl die Aufgabe oberflächlich einfach wirkt, testet sie die Fähigkeit, Designfehler zu erkennen und skalierbare Architekturen zu bauen.

Häufige Fehler & KI-gestützte Lösung

Die meisten Kandidaten übersehen SRP-Verstöße: Die ursprüngliche Struktur mischt Gehaltsberechnung und Berichtserstellung. Die richtige Herangehensweise ist die Trennung der Verantwortlichkeiten.

Die KI-Lösung nutzt Zusammensetzung und Schnittstellen:

• Eine Basis-Employee-Struct mit gemeinsamen Feldern (Stundensatz, KPI-%, Bonus-%) und Methoden (CalculateBase, CalculateKPI, CalculateBonus).
• Eine Schnittstelle SalaryCalculator mit der Methode CalculateSalary() *Report.
• Manager setzt sich aus Employee zusammen und wendet einen Multiplikator auf das Grundgehalt an.
• Ein dedizierter ReportGenerator akzeptiert jeden SalaryCalculator.
• Konstruktoren NewEmployee und NewManager übernehmen die Initialisierung.

Problem: Ein einzelner Berichtsgenerator kann zukünftige Unterschiede (z. B. Anzahl direkter Berichtslinien, unterschiedliche KPI-Termine) nicht berücksichtigen. Dies zwingt zu bedingten Logiken oder Neuschreibungen – was OCP verletzt.

Versteckte Herausforderungen in der Aufgabenstellung

Der Prompt enthält absichtlich Fallstricke:

• SRP-Verstoß: "eine Klasse, die Gehalt berechnet... und einen Bericht erstellt." Kandidaten sollten eine Trennung vorschlagen.
• Falsche Generalisierung: "gleiche KPI- und Bonusprozentsätze." Formeln können sich je nach Rolle unabhängig entwickeln.
• Übervereinfachung der Rolle: "nur das Grundgehalt unterscheidet sich." Führungskräfte sind eigenständige Geschäftseinheiten mit spezifischen KPIs und Verantwortungsbereichen.

Starke Kandidaten stellen klärende Fragen: Wie ändern sich die Formeln? Welche Daten gehen in den Bericht? Sind neue Rollen geplant?

Beurteilungskriterien für Kandidaten

Die Bewertung konzentriert sich auf das Denken, nicht auf den Code:

• Gestellte Fragen: Klärt Anforderungen, deckt versteckte Annahmen auf.
• Begründung: Erklärt Designentscheidungen (SOLID, Zusammensetzung vs. Vererbung).
• Flexibilität: Plant die Entwicklung des Systems (Hinzufügen von Rollen, Berichtsformaten).
• Vor- und Nachteileanalyse: Selbstkritik am vorgeschlagenen Lösungsansatz.
• Testbarkeit: Komponenten so gestaltet, dass sie isoliert und unit-getestet werden können.

Empfohlene Architektur

Eine funktionale Lösung (Go-Stil, anpassbar für klassenbasierte Sprachen):

• Schnittstellen:

- SalaryCalculator: Methoden zur Berechnung von Grundgehalt, KPI, Bonus und Gesamtgehalt.

- ReportDataProvider: liefert Daten für den Bericht (Gehalt, zusätzliche Felder).

- ReportTemplate: Generate(ReportDataProvider) PDF.

• Implementierungen:

- EmployeeSalary und ManagerSalary implementieren SalaryCalculator.

- EmployeeReport und ManagerReport implementieren ReportTemplate, jeweils mit Referenz auf ihren entsprechenden SalaryCalculator.

• Factory: NewReport(templateType string, calc SalaryCalculator) ReportTemplate.

Vorteile:

• Einfache Hinzufügung neuer Rollen (z. B. DirectorSalary + DirectorReport).
• Keine bedingten Logiken im Berichtsgenerator.
• Zusammensetzung ermöglicht Wiederverwendung über Komponenten hinweg.

Schlüsselerkenntnisse

• SRP-Einhaltung: Berechnung und Berichterstattung sind getrennte Anliegen.
• OCP-Konformität: Neue Rollen können hinzugefügt werden, ohne bestehenden Code zu modifizieren.
• Zusammensetzung statt Vererbung: ermöglicht langfristige Anpassungsfähigkeit des Systems.
• Fabriken zur Kapselung: verbergen die Komplexität der Erzeugung.
• Fragen des Kandidaten: signalisieren tiefgründige, reflektierte Analyse.

— Editorial Team