Kurz gesagt
- Ein Software-Engineer-Interview hat meist mehrere Runden, und jede prüft etwas anderes. Bereite dich pro Runde vor, nicht mit einer langen Liste.
- In Coding- und System-Design-Runden kann dein Gegenüber nur bewerten, was du laut erklärst. Eine richtige Lösung ohne Worte sagt wenig.
- Verhaltens- und Teamfit-Runden zählen genauso. Bereite echte Geschichten mit klarem Ergebnis vor, so sorgfältig wie Algorithmen.
Inhalt
- So ist ein Software-Engineer-Interview aufgebaut
- Fragen im Recruiter-Gespräch
- Fragen im Coding-Interview
- Fragen im System-Design-Interview
- Verhaltensfragen für Engineers
- Fragen zu Team und Kultur
- Software-Engineer-Interviews in Deutschland
- Übe jede Runde laut
- Häufige Fragen
Zu Hause löst du die Aufgabe in zwanzig Minuten. Im Interview schaut jemand zu, die Uhr läuft, und du sagst fünf Minuten lang nichts, bevor die erste Zeile steht. Das Wissen war da. Dein Gegenüber konnte es nur nicht sehen.
Dieser Leitfaden ordnet die häufigsten Software-Engineer-Interviewfragen nach Runde: Recruiter-Gespräch, Coding, System Design, Verhalten und Teamfit. Zu jeder Runde bekommst du typische Fragen, was jede Frage prüft und wie du dich vorbereitest. Drei beispielhafte Antworten zeigen, wie eine starke Antwort klingt.
So ist ein Software-Engineer-Interview aufgebaut
Anzahl und Reihenfolge der Runden unterscheiden sich je nach Unternehmen, Teamgröße und Erfahrungsstufe. Das Muster unten ist verbreitet, aber kein fester Ablauf. Frag die Recruiterin oder den Recruiter, welche Runden dich erwarten. Diese Frage ist normal und erspart dir Rätselraten.
| Runde | Typisches Format | Was geprüft wird |
|---|---|---|
| Recruiter-Gespräch | Telefonat, 20 bis 30 Minuten | Motivation, grundsätzliche Passung, Gehaltsrahmen, Verfügbarkeit |
| Coding | Live-Coding oder Take-home-Aufgabe | Problemlösung, Datenstrukturen, Codequalität, Kommunikation |
| System Design | Whiteboard oder Online-Diagramm | Architektur, Trade-offs, Skalierung, Umgang mit unklaren Anforderungen |
| Verhalten | Gespräch mit Manager oder Senior Engineer | Verantwortung, Zusammenarbeit, Konflikte, Lernen aus Fehlern |
| Team und Kultur | Treffen mit dem Team oder einer Leitung | Arbeitsweise im Alltag, was du brauchst, deine Fragen |
Bei Junior-Rollen liegt der Schwerpunkt oft stärker auf Coding. Bei Senior-Rollen wiegen System Design und Verhaltensfragen zu Entscheidungen und Einfluss meist mehr.
Fragen im Recruiter-Gespräch
Das Recruiter-Gespräch ist kurz und oft nicht technisch. Es entscheidet aber, ob du weiterkommst. Nimm es also ernst.
| Frage | Was geprüft wird |
|---|---|
| Erzählen Sie etwas über sich. | Ob du deinen Werdegang in zwei Minuten auf diese Rolle zugeschnitten zusammenfassen kannst |
| Warum interessiert Sie diese Stelle? | Ob du die Anzeige gelesen hast und einen konkreten Grund nennst |
| Mit welchem Tech-Stack haben Sie am meisten gearbeitet? | Ob deine Erfahrung zu den Kernanforderungen passt |
| Was sind Ihre Gehaltsvorstellungen? | Ob du im Budget der Stelle liegst |
| Wann könnten Sie anfangen? | Kündigungsfrist und Verfügbarkeit |
Bereite eine Zwei-Minuten-Version deines Werdegangs vor, die damit endet, warum diese Stelle der logische nächste Schritt ist. Halte einen recherchierten Gehaltsrahmen für Rolle und Ort bereit.
Fragen im Coding-Interview
Coding-Runden prüfen mehr als lauffähigen Code. Dein Gegenüber achtet auf den Weg: Klärst du das Problem, wählst du einen sinnvollen Ansatz, nennst du die Komplexität und testest du deinen eigenen Code?
| Frage | Was geprüft wird |
|---|---|
| Kehre eine verkettete Liste um. | Umgang mit Zeigern, Edge Cases wie leere Liste oder einzelner Knoten |
| Finde Duplikate in einem Array. | Zeit gegen Speicher abwägen, etwa verschachtelte Schleife gegen Hash-Set |
| Prüfe, ob zwei Strings Anagramme sind. | Den einfachsten korrekten Ansatz wählen, nach Groß- und Kleinschreibung fragen |
| Erkenne einen Zyklus in einer verketteten Liste. | Die Technik mit schnellem und langsamem Zeiger kennen und wissen, warum sie Speicher spart |
| Finde das k-größte Element. | Das passende Werkzeug wählen, etwa einen Heap, statt alles zu sortieren |
So gehst du eine Coding-Frage an
- Formuliere das Problem in eigenen Worten.
- Frag nach Eingaben, Randbedingungen und Edge Cases, bevor du Code schreibst.
- Nenne zuerst einen einfachen Ansatz, dann einen besseren, jeweils mit Zeit- und Speicherkomplexität.
- Schreib den Code und erkläre dabei jeden Schritt.
- Geh einen normalen Fall und einen Edge Case von Hand durch.
Fragen bleiben oft absichtlich unklar. Nachfragen gehört zur Aufgabe und ist keine Verzögerung.
Dein Gegenüber kann nur bewerten, was du laut erklärst.
Beispielantwort: Duplikate in einem Array finden
Das folgende Beispiel ist beispielhaft. Es zeigt, wie eine starke gesprochene Antwort klingt, und ist kein Text zum Auswendiglernen.
„Bevor ich anfange: Darf das Array verändert werden, und ist der Speicher begrenzt? Eine verschachtelte Schleife funktioniert in O(n²), wird bei großen Eingaben aber langsam. Mit einem Hash-Set schaffe ich O(n) Zeit bei O(n) zusätzlichem Speicher. Ist kein Zusatzspeicher erlaubt, kann ich zuerst sortieren: O(n log n) Zeit ohne zusätzliche Struktur. Welche Bedingung ist hier wichtiger?"
Die Antwort nennt drei Optionen, ihre Kosten und lässt das Gegenüber entscheiden.
So bereitest du dich auf Coding-Runden vor
Lerne keine einzelnen Aufgaben auswendig. Lerne die wiederkehrenden Muster: zwei Zeiger, Sliding Window, Hashing, binäre Suche, Breiten- und Tiefensuche, Heaps und dynamische Programmierung. Wenn du das Muster erkennst, sind die meisten Aufgaben Varianten davon.
Übe beim Sprechen. Stilles Lösen am Schreibtisch trainiert eine andere Fähigkeit als die, die im Interview bewertet wird.
Fragen im System-Design-Interview
System-Design-Runden sind absichtlich offen. Es gibt nicht die eine richtige Antwort. Dein Gegenüber will sehen, wie du ein unklares Problem strukturierst und wie du Trade-offs abwägst.
| Frage | Was geprüft wird |
|---|---|
| Entwirf einen URL-Shortener. | Anforderungen klären, Schlüsselerzeugung, Wahl des Datenspeichers, Skalierung für viele Lesezugriffe |
| Entwirf einen News-Feed. | Fan-out beim Schreiben oder beim Lesen, Caching, Accounts mit vielen Followern |
| Entwirf einen Rate Limiter. | Algorithmen wie Token Bucket, Platzierung, gemeinsamer Zustand über mehrere Server |
| Wie skalierst du einen Dienst von 1.000 auf 1.000.000 Nutzer? | In Stufen denken und den Engpass jeder Stufe benennen |
| Entwirf ein Chat-System. | Echtzeitverbindungen, Reihenfolge von Nachrichten, Zustellung im Offline-Fall |
Ein Rahmen in fünf Schritten für jede Design-Frage
- Anforderungen klären: Wer nutzt es, was muss es können, welche Größenordnung?
- Grobes Design skizzieren: Hauptkomponenten und Datenfluss.
- Bei ein bis zwei Teilen in die Tiefe gehen: Datenmodell, API, die schwierigste Komponente.
- Trade-offs besprechen: Konsistenz gegen Verfügbarkeit, Kosten gegen Latenz.
- Fehlerquellen benennen und sagen, was du überwachen würdest.
Beispielantwort: einen Rate Limiter entwerfen
Das folgende Beispiel ist beispielhaft und gekürzt. Eine echte Antwort dauert deutlich länger und enthält ein Diagramm.
„Zuerst ein paar Fragen: Begrenzen wir pro Nutzer oder pro IP, und wie viele Anfragen pro Minute? Geht es um einen Dienst oder um viele? Ich würde mit einem Token Bucket anfangen, weil er kurze Spitzen erlaubt, aber die Durchschnittsrate festhält. Platzieren würde ich ihn am API-Gateway, damit alle Dienste an einer Stelle geschützt sind. Bei mehreren Gateway-Instanzen brauchen die Zähler einen gemeinsamen Zustand, etwa in einem In-Memory-Speicher. Das kostet pro Anfrage einen Netzwerkaufruf, der Trade-off ist also Genauigkeit gegen Latenz. Sind ein paar Anfragen zu viel akzeptabel, wären lokale Zähler mit regelmäßigem Abgleich schneller."
Im System Design zählt der Trade-off, den du benennst, mehr als die Technologie, die du wählst.
Verhaltensfragen für Engineers
Viele Engineers üben wochenlang Algorithmen und einen Abend lang Verhaltensfragen. Das ist riskant: Diese Fragen zeigen, wie du mit Menschen arbeitest, mit Druck umgehst und Verantwortung übernimmst. Am besten beantwortest du sie mit der STAR-Methode: Situation, Aufgabe, Handlung, Ergebnis.
| Frage | Was geprüft wird |
|---|---|
| Erzählen Sie von einer technischen Meinungsverschiedenheit im Team. | Mit Fakten überzeugen, die Zusammenarbeit erhalten |
| Beschreiben Sie einen Produktionsvorfall, bei dessen Lösung Sie geholfen haben. | Ruhe bewahren, Vorgehen beim Debugging, Maßnahmen gegen Wiederholung |
| Erzählen Sie, wie Sie schnell eine neue Technologie gelernt haben. | Lernweg und wie schnell du produktiv wurdest |
| Wann waren Sie mit einer Deadline oder Produktentscheidung nicht einverstanden? | Bedenken professionell äußern und die Entscheidung danach mittragen |
| Erzählen Sie von einem Fehler, den Sie gemacht haben. | Ehrlichkeit, Verantwortung, was du danach geändert hast |
Beispielantwort: eine technische Meinungsverschiedenheit
Das folgende Beispiel ist beispielhaft und stammt nicht von einer echten Person.
- Situation: Ein Kollege und ich waren uns uneinig, ob wir eine Message Queue zwischen zwei Diensten einführen.
- Aufgabe: Wir brauchten vor dem Design-Review in derselben Woche eine Entscheidung.
- Handlung: Ich habe einen kleinen Benchmark beider Ansätze unter der erwarteten Last gebaut und die Ergebnisse im Review gezeigt, auch die Punkte, an denen meine Option schwächer war.
- Ergebnis: Das Team hat sich für die Queue entschieden. Ich habe einen kurzen Entscheidungsvermerk geschrieben, damit spätere Engineers das Warum nachlesen können.
Stark ist die Handlung: konkret, mit Daten statt Meinung, und das Ergebnis zeigt, was sich geändert hat.
Bereite vor dem Interview fünf bis sieben echte Geschichten vor: ein Konflikt, ein Vorfall, Verantwortung, ein Fehler und etwas Neues, das du gelernt hast. Dann passt du eine Geschichte an die Frage an, statt unter Druck eine zu erfinden.
Fragen zu Team und Kultur
Diese Runde fühlt sich oft wie ein lockeres Gespräch an. Sie zählt trotzdem. Das Team will wissen, wie du im Alltag arbeitest und ob die Zusammenarbeit passt.
| Frage | Was geprüft wird |
|---|---|
| Wie gehen Sie an Code-Reviews heran? | Feedback konstruktiv geben und annehmen |
| Wie arbeiten Sie mit Produktmanagement und Design zusammen? | Zusammenarbeit über das Engineering hinaus |
| In welchem Teamumfeld arbeiten Sie am besten? | Selbstkenntnis und Passung zur Arbeitsweise des Teams |
| Wie gehen Sie mit unklaren Anforderungen um? | Früh nachfragen, Annahmen sichtbar machen |
| Was möchten Sie in Ihrer nächsten Rolle lernen? | Motivation und ob die Rolle das bieten kann |
Am Ende wirst du meist gefragt, ob du noch Fragen hast. Bereite zwei oder drei konkrete vor, zum Beispiel: „Wie entscheidet das Team, was refaktoriert wird?" oder „Wie sieht der erste Monat in dieser Rolle typischerweise aus?"
Deine Fragen am Ende sind Teil des Interviews, keine Formalität.
Software-Engineer-Interviews in Deutschland
Die Runden oben gelten auch in Deutschland. Einige Themen kommen hier häufiger vor oder brauchen extra Vorbereitung:
- Gehaltsvorstellung: Du wirst oft früh nach einer Zahl gefragt, manchmal schon in der Bewerbung. Nenne einen recherchierten Bruttojahresrahmen.
- Kündigungsfrist: Deutsche Arbeitsverträge haben oft Kündigungsfristen von mehreren Wochen oder Monaten. Kenne deine, denn sie bestimmt dein Startdatum.
- Probezeit: Eine Probezeit, oft bis zu sechs Monaten, ist in deutschen Verträgen Standard. Sie ist kein Zeichen von Misstrauen.
- Sprache: Viele Tech-Teams arbeiten auf Englisch. Sei trotzdem bereit, ehrlich zu sagen, wie gut dein Deutsch ist und wie du es im Job nutzt.
- Arbeitserlaubnis: Wenn du ein Visum brauchst, sag es klar und früh. Dann kann das Unternehmen damit planen.
Übe jede Runde laut
Fragen lesen bereitet dein Wissen vor. Das Interview prüft, ob du dieses Wissen klar erklären kannst, während jemand zuhört. Diese Lücke schließt du nur, indem du laut antwortest.
Ein Mock-Interview bei TalentVP hat sieben Fragen. Die erste ist eine Einstiegsfrage, in der letzten stellst du die Fragen. Die fünf dazwischen entstehen aus dem Jobtitel, deiner Erfahrungsstufe, der Stellenanzeige und deinen bisherigen Antworten. Du kannst tippen oder sprechen. Gesprochene Antworten werden in Text umgewandelt und so bewertet. Interviews laufen auf Deutsch, Englisch oder Türkisch.
Nach jeder Antwort bekommst du eine Punktzahl von 0 bis 100, Stärken, Verbesserungspunkte und eine Musterantwort. Als Antwortstruktur kannst du STAR, PAR oder CARL wählen. Dein Dashboard zeigt frühere Interviews und wie sich deine Punktzahlen entwickeln. Mit einem kostenlosen Konto ist dein erstes Mock-Interview enthalten.
Ein kurzer Vorbereitungsplan
- Frag nach, welche Runden dich erwarten.
- Übe für Coding die Muster beim Sprechen und nenne jedes Mal die Komplexität.
- Geh ein komplettes System Design laut durch, von den Anforderungen bis zu den Trade-offs.
- Schreib fünf bis sieben STAR-Geschichten auf und übe sie, bis jede etwa zwei Minuten dauert.
- Bereite zwei Fragen an das Team vor.
Für Verhaltensrunden im Detail: Wie man Verhaltensfragen im Vorstellungsgespräch mit der STAR-Methode beantwortet erklärt jeden Schritt mit Beispielen.
