Interviewfragen für Solution Architects, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Die meisten Runden enthalten eine Designaufgabe. Stell Fragen, bevor du zeichnest: Wer nutzt es, wie viele, was darf nie verloren gehen, was darf es kosten? Dann skizzierst du einen einfachen Entwurf, sagst, was du angenommen hast, und verbesserst ihn, wenn der Interviewer eine Tatsache ändert. Bei den anderen Fragen nennst du eine Lösung, die du wirklich entworfen hast, die Wahl, die du getroffen hast, und wohin sie geführt hat.

Was ein Solution Architect können muss

• Das Handwerk: LösungsarchitekturIn 28 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Einen Bedarf des Geschäfts in einen Entwurf übersetzen, der zu den Systemen ringsum passt, und jede Wahl begründen., von den Anforderungen bis zur festgehaltenen Entscheidung.
• Die Cloud: Cloud-ArchitekturIn 5 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Für die Cloud entwerfen, mit ihren Diensten, Grenzen und Kosten, nicht ein Rechenzentrum, das unverändert umzieht. auf mindestens einer der Plattformen AWSIn 22 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Die wichtigsten AWS-Dienste gut genug kennen, um sie für einen Entwurf auszuwählen, zu kombinieren und ihre Kosten zu schätzen., AzureIn 19 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Die wichtigsten Azure-Dienste gut genug kennen, um sie für einen Entwurf auszuwählen, zu kombinieren und ihre Kosten zu schätzen. oder Google CloudIn 16 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Die wichtigsten Dienste von Google Cloud kennen und wissen, wann sie besser zu einem Entwurf passen als eine andere Wahl..
• Die Verbindungen: IntegrationIn 1 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Systeme über APIs, Events und Dateien verbinden, sodass jedes sich ändern kann, ohne die anderen zu brechen. über APIsIn 6 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Die Schnittstellen zwischen Systemen entwerfen und prüfen: Verträge, Versionen, Fehler und Sicherheit., Events und Dateien, und wann ServicesIn 6 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Wissen, wann sich ein System in Services teilen lässt und was das im Betrieb und beim Testen kostet. ihre Kosten wert sind.
• Die Menschen: StakeholderIn 7 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Fachbereiche, Engineers, Sicherheit und Lieferanten zu einem Entwurf bringen, den alle mittragen., die Verschiedenes wollen, und einen Entwurf jedem von ihnen erklärenIn 21 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Einen Entwurf einer Geschäftsführung in fünf Minuten erklären und einem Engineer im vollen Detail..

Die Diagrammwerkzeuge nennen Anzeigen nebeneinander, und keines ist Pflicht: draw.io, Lucidchart, Visio und Archi zeichnen die Bilder, Confluence oder ein Wiki hält die Entscheidungen fest. Interviewern ist wichtig, was das Diagramm sagt, nicht welches Werkzeug es gezeichnet hat; viele Teams nutzen das C4-Modell, um die Ebenen auseinanderzuhalten.

Vom Bedarf zum Entwurf

Wie machst du aus einer vagen Anfrage des Geschäfts Anforderungen, gegen die du entwerfen kannst?

Worauf sie achten: dass du beim Problem anfängst, nicht bei einer Technik.

Kurze Antwort: „Ich frage, was das Geschäft erreichen will und woran es das messen wird, wer die Nutzer sind, welche Systeme beteiligt sind und was sich nicht ändern darf. Die funktionalen Anforderungen schreibe ich als kurze Liste dessen, was die Lösung können muss, stimme sie mit dem Verantwortlichen ab und markiere, was noch unbekannt ist.“

Die ausführliche Antwort: Schreib auch die Annahmen auf. Ein Entwurf ist nur so gut wie das, was er annimmt, und eine aufgeschriebene Annahme lässt sich prüfen.

Schwache Antwort: „Ich nehme die Anforderungen, die mir der Fachbereich gibt.“ Nachfrage: „Die Verantwortliche im Fachbereich und der Vertriebsleiter wollen das Gegenteil.“ Sag, was du tust.

Welche nicht-funktionalen Anforderungen legst du zuerst fest, und wie?

Worauf sie achten: die Qualitäten, die die meisten Entwürfe entscheiden.

Kurze Antwort: „Nicht-funktionale Anforderungen beschreiben, wie gut die Lösung funktionieren muss, nicht, was sie tut: Last, Antwortzeit, Verfügbarkeit, Sicherheit, wie lange Daten aufbewahrt werden, Kosten. Aus jeder mache ich eine Zahl, der das Geschäft zustimmt, etwa die Antwortzeit für die meisten Anfragen oder die Stunden Ausfall im Jahr, die es hinnehmen kann.“

Die ausführliche Antwort: Eine Qualität ohne Zahl lässt sich nicht testen. „Schnell“ und „sicher“ beginnen einen Streit, Zahlen beenden ihn.

Schwache Antwort: „Es muss schnell und sicher sein.“ Nachfrage: „Der Verantwortliche sagt, es darf nie ausfallen.“ Sag, wie du daraus eine Zahl machst.

Erzähl uns von einem Trade-off, den du gemacht hast, und wie du die Entscheidung festgehalten hast.

Worauf sie achten: Urteilsvermögen und eine Spur, der andere folgen können.

Kurze Antwort: „Wir haben eine verwaltete Datenbank gewählt statt einer eigenen: weniger Kontrolle über das Tuning, aber kein Team in Rufbereitschaft dafür. Ich habe einen Architecture Decision Record geschrieben, eine kurze Notiz mit dem Kontext, den Optionen, der Entscheidung und ihren Folgen, damit ein neues Teammitglied sehen konnte, warum.“

Die ausführliche Antwort: Halte fest, was dich dazu bringen würde, die Entscheidung zu ändern. Wenn das eintritt, sagt das Protokoll dem Team, dass es Zeit ist.

Schwache Antwort: „Wir haben genommen, was wir immer nehmen.“ Nachfrage: „Ein Jahr später sieht die Entscheidung falsch aus.“ Sag, was du mit dem Protokoll machst.

Wie würdest du ein neues System an einen alten Kern anbinden, der sich nicht ändern lässt?

Worauf sie achten: IntegrationIn 1 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Systeme über APIs, Events und Dateien verbinden, sodass jedes sich ändern kann, ohne die anderen zu brechen. in der echten Welt.

Kurze Antwort: „Ich suche, was das Altsystem schon anbietet: Dateien, eine Sicht auf die Datenbank, eine alte Schnittstelle. Davor setze ich eine dünne Schicht, mit der das neue System spricht, sodass das alte nur an einer Stelle berührt wird. Seine Langsamkeit und seine Wartungsfenster plane ich ein.“

Die ausführliche Antwort: Die Schicht davor bereitet auch den Tag vor, an dem das Altsystem ersetzt wird: Das neue System merkt davon nichts.

Schwache Antwort: „Wir verbinden uns direkt mit seiner Datenbank.“ Nachfrage: „Das Altsystem schickt jede Nacht eine einzige große Datei.“ Sag, wie trotzdem fast Echtzeit gelingt.

Plane die Migration einer Anwendung in die Cloud: Wo fängst du an?

Worauf sie achten: Cloud-ArchitekturIn 5 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Für die Cloud entwerfen, mit ihren Diensten, Grenzen und Kosten, nicht ein Rechenzentrum, das unverändert umzieht., die mehr ist, als Server umzuziehen.

Kurze Antwort: „Ich fange damit an, was die Anwendung braucht und mit welchen Systemen sie spricht. Dann wähle ich für jeden Teil: so umziehen, wie er ist, auf verwaltete Dienste umbauen oder ersetzen. Ich plane die Reihenfolge, den Umzug der Daten und den Weg zurück, falls ein Schritt scheitert.“

Die ausführliche Antwort: Zieh zuerst einen kleinen Teil mit wenig Risiko um. Er lehrt das Team die neue Plattform, bevor der schwere Teil kommt.

Schwache Antwort: „Wir ziehen alles auf einmal um.“ Nachfrage: „Die Datenbank ist zu groß, um sie an einem Wochenende zu kopieren.“ Sag, wie du sie umziehst.

Kosten, Ausfälle und Sicherheit

Wie schätzt und steuerst du die Kosten einer Lösung?

Worauf sie achten: Entwürfe, die sich das Geschäft über Jahre leisten kann.

Kurze Antwort: „Ich schätze die Total Cost of Ownership, also den Bau plus Betrieb, Lizenzen, Support und den späteren Ersatz, nicht nur die erste Rechnung. In der Cloud berechne ich die wichtigsten Dienste für die erwartete Last, vergebe Tags, damit jeder Kostenpunkt einen Verantwortlichen hat, und setze Alarme, bevor das Budget erreicht ist.“

Die ausführliche Antwort: Zeig, wie die Kosten mit der Nutzung wachsen. Ein Entwurf, der zum Start wenig kostet, kann bei zehnmal so vielen Nutzern viel kosten.

Schwache Antwort: „Um die Kosten kümmert sich die Finanzabteilung.“ Nachfrage: „Die Monatsrechnung hat sich verdoppelt.“ Sag, wo du zuerst nachsiehst.

Wie entwirfst du für Hochverfügbarkeit und Disaster Recovery?

Worauf sie achten: dass du für den Ausfall planst.

Kurze Antwort: „Hochverfügbarkeit heißt, die Lösung läuft weiter, wenn ein Teil ausfällt, zum Beispiel weil sie in zwei Zonen einer Cloud-Region läuft. Disaster Recovery heißt, sie nach einem größeren Verlust, etwa einer ganzen Region oder eines Rechenzentrums, wieder zum Laufen zu bringen, innerhalb der Zeit und des Datenverlusts, die das Geschäft vereinbart hat. Ich entwerfe auf diese beiden vereinbarten Werte hin und teste die Wiederherstellung, nicht nur das Backup.“

Die ausführliche Antwort: Jede zusätzliche Stufe an Verfügbarkeit kostet mehr. Zeig dem Geschäft den Preis jeder Stufe und lass es wählen.

Schwache Antwort: „Wir haben Backups.“ Nachfrage: „Das Backup wurde noch nie zurückgespielt.“ Sag, was du diesen Monat tust.

Wie baust du Sicherheit von Anfang an in eine Lösung ein?

Worauf sie achten: dass du mit der Sicherheit arbeitest, nicht an ihr vorbei.

Kurze Antwort: „Ich hole das Sicherheitsteam in das erste Design-Review, lege fest, wer und was jeden Teil erreichen darf, verschlüssele Daten bei der Übertragung und im Ruhezustand, halte Secrets aus dem Code heraus und plane das Logging, das nach einem Vorfall gebraucht wird. Regeln für Daten, etwa wo personenbezogene Daten liegen dürfen, kommen am ersten Tag in die Anforderungen.“

Die ausführliche Antwort: Bei einer großen oder sensiblen Lösung prüft ein Security Architect den Entwurf. Bitte früh um dieses Review, solange Änderungen noch günstig sind.

Schwache Antwort: „Die Sicherheit testet es vor dem Go-live.“ Nachfrage: „Der Test zeigt, dass jeder Mitarbeiter die Kundendaten sehen kann.“ Sag, was du änderst.

Wie nutzt du die Well-Architected Frameworks der Cloud-Anbieter in einem Design-Review?

Worauf sie achten: ein strukturiertes Review statt Meinungen.

Kurze Antwort: „Die Well-Architected Frameworks von AWS, Microsoft Azure und Google Cloud listen jeweils Fragen zu Zuverlässigkeit, Sicherheit, Kosten, Performance und Betrieb. Ich gehe sie mit dem Team durch, notiere, worauf der Entwurf noch keine Antwort hat, und mache aus den Lücken Aufgaben mit einem Verantwortlichen.“

Die ausführliche Antwort: Sie sind Checklisten, keine Entwürfe. Nutze sie, um zu finden, was du übersehen hast, und entscheide dann für dieses Geschäft.

Schwache Antwort: „Wir haben jeden Punkt bestanden.“ Nachfrage: „Zwei Punkte widersprechen sich: Kosten und Zuverlässigkeit.“ Sag, wie du entscheidest.

Optionen, Menschen und Umsetzung

Wann machst du einen Proof of Concept, und was macht ihn nützlich?

Worauf sie achten: dass du die riskanteste Annahme günstig testest.

Kurze Antwort: „Ein Proof of Concept ist ein kleiner Bau mit fester Zeit, der prüft, ob ein riskanter Teil eines Entwurfs funktioniert, etwa die Performance eines Produkts mit unseren Daten. Ich mache einen, wenn eine Entscheidung auf etwas beruht, das noch niemand funktionieren gesehen hat, mit Erfolgskriterien, die vor dem Start vereinbart sind.“

Die ausführliche Antwort: Wirf den Code danach weg. Ein Proof of Concept, der still zum Produkt wird, überspringt alles, wofür der Entwurf da war.

Schwache Antwort: „Wir bauen die erste Version und schauen.“ Nachfrage: „Der Anbieter will den Proof of Concept für dich durchführen.“ Sag, worauf du bestehst.

Make or Buy: Wie entscheidest du, und wie vergleichst du Anbieter?

Worauf sie achten: eine faire Entscheidung, mit der das Geschäft leben kann.

Kurze Antwort: „Ich baue selbst, was das Geschäft von anderen abhebt, und kaufe, was für alle gleich ist. Beim Kauf vergleiche ich Anbieter nach den Anforderungen, der Passung zu unseren Systemen, den Gesamtkosten, dem Ausstieg, falls wir wechseln, und der Stabilität des Anbieters selbst, mit einer Bewertung, die vor den Demos vereinbart ist.“

Die ausführliche Antwort: Stell jedem Anbieter dieselben Fragen schriftlich. Demos zeigen, was ein Anbieter zeigen will.

Schwache Antwort: „Wir kaufen das Produkt, das alle nutzen.“ Nachfrage: „Das günstigste Angebot sperrt die Daten ein.“ Sag, wie das die Bewertung ändert.

Zeichne uns die Lösung: Welche Diagramme nutzt du, und für wen?

Worauf sie achten: dass du einen Entwurf verschiedenen Menschen erklären kannst.

Kurze Antwort: „Ein Kontextdiagramm für das Geschäft, das die Lösung zeigt und mit welchen Systemen sie spricht; ein Container-Diagramm für die Teams; ein Deployment-Diagramm für Betrieb und Sicherheit. Das C4-Modell gibt diesen Ebenen Namen. Das Werkzeug ist weniger wichtig; draw.io, Lucidchart, Visio oder Archi können es alle.“

Die ausführliche Antwort: Ein Diagramm für alle passt zu niemandem. Halte jedes auf der Ebene, die seine Leser brauchen.

Schwache Antwort: „Ein großes Diagramm mit allem.“ Nachfrage: „Der CFO hat zwei Minuten.“ Sag, welches Bild du zeigst.

Wie sieht eine gute Übergabe an das Umsetzungsteam aus, und wie bleibst du beteiligt?

Worauf sie achten: ein Entwurf, der den Kontakt mit dem Bau übersteht.

Kurze Antwort: „Die Übergabe ist ein gemeinsamer Durchgang durch den Entwurf, die Entscheidungsprotokolle und die offenen Fragen mit den Menschen, die es bauen und betreiben werden, kein Dokument per E-Mail. Danach bin ich bei den Reviews dabei, beantworte Fragen innerhalb eines Tages und ändere den Entwurf, wenn der Bau zeigt, dass er falsch war.“

Die ausführliche Antwort: Bitte das Team, dir den Entwurf zurückzuerklären. Was es nicht erklären kann, hast du nicht übergeben.

Schwache Antwort: „Nach dem Entwurf ist meine Arbeit getan.“ Nachfrage: „Das Team hat es still und leise anders gebaut.“ Sag, was du tust.

Ein Kunde will ein Feature, das dein Entwurf nicht tragen kann. Was tust du?

Worauf sie achten: Ehrlichkeit gegenüber Kunden und Urteilsvermögen im PresalesIn 18 % der Anzeigen für Solution Architect gefragt (Stand 05.11.2026).Eine Lösung vor dem Vertrag mit einem Kunden formen und nur versprechen, was das Team liefern kann..

Kurze Antwort: „Ich finde heraus, was der Kunde hinter dem Feature braucht, zeige, was der Entwurf stattdessen kann und was das Feature an Zeit und Risiko kosten würde, und vereinbare eine Entscheidung mit dem Account-Team, bevor etwas versprochen wird.“

Die ausführliche Antwort: Ein Versprechen, das das Umsetzungsteam nicht halten kann, kostet mehr als ein verlorener Auftrag. Sag es früh.

Schwache Antwort: „Wir sagen Ja und lösen es später.“ Nachfrage: „Der Vertrieb hat es schon versprochen.“ Sag, was du als Nächstes tust.

Wie würdest du eine Lösung entwerfen, die KI nutzt oder große Datenmengen hält?

Worauf sie achten: die Entwürfe von heute, mit ihren Risiken.

Kurze Antwort: „Ich fange bei den Daten an: woher sie kommen, wer sie nutzen darf und wie gut sie sind. Bei KI entscheide ich, ob das Modell eines Anbieters, ein Modell, das wir selbst betreiben, oder gar kein Modell passt. Wo eine falsche Antwort schadet, prüft ein Mensch mit; ich logge Eingaben und Ausgaben und plane die Kosten pro Anfrage.“

Die ausführliche Antwort: Regeln für Daten und für KI sind von Land zu Land verschieden. Die Anforderungen nennen die Regeln, die gelten, gemeinsam mit der Rechtsabteilung der Firma.

Schwache Antwort: „Wir bauen KI ins Produkt ein.“ Nachfrage: „Das Modell gibt Kunden manchmal falsche Antworten.“ Sag, wie der Entwurf sie abfängt.

Runden für Senior-Rollen

Wie würdest du als Senior Solution Architect einen Associate Solution Architect coachen und die Standards des Teams prägen?

Worauf sie achten: dass du andere wachsen lässt und Entwürfe einheitlich hältst.

Kurze Antwort: „Einem Associate Solution Architect gebe ich einen Teil eines echten Entwurfs mit meinem Review, dann eine ganze kleine Lösung. Für das Team halte ich wenige Standards kurz: wie Entscheidungen festgehalten werden, welche Diagramme jeder Entwurf hat, welche Muster wir wiederverwenden, und ein Review, in dem jeder Architekt um einen zweiten Blick bitten kann.“

Die ausführliche Antwort: Einen Senior oder Principal Solution Architect misst man an den Entwürfen der Menschen um ihn herum, nicht nur an seinen eigenen.

Schwache Antwort: „Ich prüfe alles selbst.“ Nachfrage: „Zwei Architekten haben dasselbe zweimal entworfen.“ Sag, wie du das verhinderst.

Dein Lebenslauf für diese Fragen

Jeder Job in deinem Lebenslauf lädt zu den Fragen oben ein: welche Lösung, welcher Trade-off, was sie gekostet hat und wie sie sich gehalten hat. Gib diesen Geschichten je eine Zeile, so geschrieben, dass eine Architekturleitung mehr hören will:

Leg deinen Lebenslauf mit der kostenlosen Bewertung neben einen Job als Solution Architect, den du willst. Den Bereich, den sie als dünn erkennt, übst du zuerst, mit einem Entwurf, den du aus dem Gedächtnis zeichnen kannst.