it-swarm-eu.dev

Wie beantworten Sie die Frage "Aktuelle Architektur Ihres Projekts erklären" in Interviews?

Die Anwendung, an der ich gerade arbeite, ist ein bisschen riesig. Es kann nicht in 15 Minuten oder so erklärt werden.

Das letzte Mal habe ich einige Klassendiagramme gezeichnet und wie sie verknüpft sind, aber ich konnte sehen, dass der Interviewer mit der Antwort nicht zufrieden war.

Was sind die wichtigsten Dinge, die bei der Beantwortung dieser Frage hervorgehoben werden sollten?

Zum Beispiel, wie die Sitzung verwaltet wird, wie die Persistenz erreicht wird, sind nur wenige Dinge.

Was sind andere Dinge, die man sich nicht entgehen lassen sollte?

10

Persönlich denke ich, dass Sie (für ein Interview) zu tief gehen werden, wenn Sie anfangen, Klassendiagramme zu zeichnen, es sei denn, sie fragen danach.

Als ich das letzte Mal diese Frage hatte, zeichnete ich die verschiedenen Ebenen (3-Ebenen-App) und erklärte, wie die Baugruppen zugeordnet wurden (da dies meiner Meinung nach für das Projekt etwas „Seltsames“ war), in welche Richtung die Ebenen Abhängigkeiten hatten und in welche Richtung Richtung des Datenflusses.

Sie können sich eingehender mit bestimmten Komponenten befassen, wenn Sie dies für erforderlich halten. Aber ich bin nie viel tiefer gegangen als "Wir haben aus diesem Grund die Workflow Foundation für diesen Teil der Geschäftslogik verwendet". Dies gab mir die Möglichkeit darauf hinzuweisen, dass wir eine bestimmte verwendete Technologie verwendet haben, ohne Zeit für triviale Dinge wie einfache POCO-Objekte zu verschwenden .

Wichtiger ist es zu zeigen, dass Sie die Architektur verstehen und warum dies so gemacht wird. Noch besser ist es, auf Verbesserungspunkte (wenn möglich) hinzuweisen und zu erklären, warum dies so ist. Wenn Sie andererseits der Meinung sind, dass das Design „perfekt“ ist, können Sie auf einen bestimmten Teil des Designs hinweisen, der für einen Außenstehenden nicht logisch erscheint, und erklären, warum er für dieses Projekt geeignet ist.

16
Bart

Wenn Sie nicht in der Lage sind, einen allgemeinen Überblick über die Architektur Ihres Projekts zu geben oder das Projekt in 5 Minuten (geschweige denn in 15 Minuten) jemand anderem zu erklären, liegt der Grund höchstwahrscheinlich darin, dass Sie sich zu nahe am Kohleberg befinden.

Sie müssen etwas Abstand gewinnen, damit Sie Ihre eigene Arbeit so sehen können, wie andere es sehen würden. Treten Sie wie ein Maler zurück und schauen Sie sich das Ganze an. Dann sehen Sie in einer 5-minütigen Übersicht, worauf es ankommt.

13
wolfgangsz

Alle diese Antworten sind hervorragend, aber ich habe festgestellt, dass ein Komponentendiagramm auf sehr hoher Ebene, eine Auflistung des Technologie-Stacks (z. B. Java, JSF, Primefaces usw.) und ein selbstbewusstes Lächeln und eine offene Haltung die besten sind Antwort auf diese Frage.

Wenn Sie nicht lächeln oder sogar ein bisschen aufgeregt sind, wenn Sie die Architektur Ihres aktuellen Projekts erklären, sieht der Interviewer Sie möglicherweise als distanziert und uninteressiert an Ihrer harten Arbeit. Ich bin aufgeregt und spreche darüber, als ob ich denke, dass es das "coolste" Ding der Welt ist, und das bringt den Interviewer zum Lächeln und Wohlfühlen, und er beginnt, detailliertere Fragen zu stellen.

3
maple_shaft

Stellen Sie sich vor, Sie beantworten diese Frage so, wie Sie sie einem Kunden erklären würden. Ihr Kunde kümmert sich nicht um die Schrauben und Muttern, die er nur über die Gesamtstruktur wissen möchte.

Im gleichen Sinne möchte der Interviewer nur, dass die Übersicht zeigt, aus welcher Art von Umgebung Sie kommen und wie sie mit ihrem eigenen Projekt korreliert. Sie wollen nicht, dass Sie über Ihr Projekt nachdenken, und Sie sollten im Interview keine Klassendiagramme zeigen.

Geben Sie ihnen also einen Überblick über die Architektur von 10.000 Meilen. Wenn sie mehr Details zu etwas wollen, werden sie fragen. Dann gehe tiefer.

2
Tyanna

Beginnen Sie auf der höchstmöglichen Ebene und arbeiten Sie nach unten. Ich würde mit einem grundlegenden Funktionsblockdiagramm auf dem Whiteboard beginnen. Denken Sie daran, dass der Interviewer (hoffentlich) technisch versiert ist, aber nichts über Ihr Projekt weiß.

Unabhängig vom Projekt sollten Sie in der Lage sein, in wenigen (<10) Blöcken einen Überblick über die Grundoperation zu zeichnen. Sie können dann die Blöcke, die Sie gut kennen, erweitern und weitere Details hinzufügen. Zum Beispiel erwähnen Sie die Persistenz - dies kann ein einzelner Block im ersten Diagramm sein, kann aber ein ganzes Whiteboard abdecken, wenn Sie einen Drilldown in die Details durchführen müssen.

Wenn sie nach der Architektur fragen, erwarten sie eine Übersicht, um zu sehen, ob Sie tatsächlich wissen, wie sie zusammenpasst, oder ob Sie nur an einem kleinen Teil des Projekts gearbeitet haben. Stellen Sie sicher, dass Sie dies angeben, bevor Sie mit dem Drilldown auf einen kleinen Bereich beginnen.

1
Luke Graham