In meinem Software-Team testen wir im Rahmen des Interviews das Datenbankverständnis.
Wir präsentieren - ein sehr schlechtes Design (think CRM type application) und bitten sie, das Design nach ca. 30 Minuten Bedenkzeit zu verbessern.
Wir stellen ihnen dann weitere Fragen, basierend auf dem, worüber sie sprechen.
Wir suchen nach Verständnis für
- Leistung V Normalistion
- Schlüsseldesign und Referenzintegrität
- Orte für Verbesserungen - die alternative DB-Struktur - Trigger, View, Procuedures
- Bereiche, die im Design schwach sind - wie man viele bis viele Beziehungen überwindet
- Wie sich dies auf den Server auswirkt - warten
- Datensicherheitsprobleme
- Anwendungssicherheitsprobleme
Wir als Team haben dann darüber nachgedacht, was wir als Junior / Senior / Architect-Antworten auf diese Art von Fragen betrachten würden.
Also für - Leistung gegen Normierung -
würde das Problem in erster Linie sehen und in der Lage sein zu diskutieren, warum (Junior)
Ich würde 4/5 NF empfehlen, aber das Problem mit der Leistung verstehen. Würden sie das Problem denormalisieren und verstehen, wie man es artikuliert. (Senior)
Würden sie einen anderen Designtyp empfehlen, z. B. ein Sternschema, und die Auswirkungen auf vielen Ebenen diskutieren (Architekt)?
- Schlüsseldesign und referentielle Integrität
Würde sehen, dass die Ref-Integrität erforderlich ist, um Datenbeziehungen zu erzwingen und dies zu diskutieren, aber würde das Problem mit Key Choice und Design (Junior) nicht sehen
Erläutert Probleme im Zusammenhang mit Datenmengen und Datentypen, v sucht nach natürlichen Schlüsseln in den Daten und kann erläutern, warum sie diese untersuchen - und die Probleme, die mit der referenziellen Integrität verbunden sind. (Senior)
Konnte verschiedene Gesichtspunkte im Zusammenhang mit Schlüsseln und Integrität diskutieren und in der Lage sein, verschiedene aktuelle Modelle für schnelles Design zu entwickeln (Architekt)
Du bekommst das Bild.
Wenn du willst, dass ich mehr hinzufüge, dann schreibe einen Kommentar und werde detailliert beschreiben, was wir über den Rest denken.
Der Punkt ist, über die 1. Fragen nachzudenken. 2. Wir als Team haben uns dann Gedanken darüber gemacht, was wir als Junior / Senior / Architect-Antworten auf diese Art von Fragen ansehen würden.
Ich betone das Team, da der Kandidat und das Team zuversichtlich sein müssen, dass die Person, die hereinkommt, die richtigen Antworten auf die verschiedenen Ebenen findet. Die Person, die reinkommt, passt hoffentlich besser zum Team. Es gibt dem Team auch die Möglichkeit, die Wahl des Kandidaten zu beeinflussen. Sie benennen auch eine Person, die in der Fragetafel vertreten sein soll. Hilft viel beim Team-Buy-In.