Interviewfragen werden nicht am Morgen aus der Luft gegriffen. In fast jedem strukturierten Prozess hat die Person, die dich interviewt, dieselbe Stellenanzeige in die Hand bekommen, die du gelesen hast, dazu den Auftrag herauszufinden, ob du die Dinge darauf kannst, und musste sich die Fragen aus diesen Zeilen selbst ausdenken. Deshalb fühlen sich die Fragen unheimlich nah an den Stichpunkten an. Sie sind die Stichpunkte, nur umgedreht.
Damit ist eine Stellenanzeige ein getarnter Fragenkatalog, wenn du sie in die richtige Richtung liest. Aus einer Anforderung wird eine Frage nach deiner Erfahrung. Aus einer Aufgabe wird ein Szenario. Aus einer Zeile über das Arbeitsumfeld wird eine Verhaltensfrage. Lern die Umrechnung, und das Vorstellungsgespräch hört auf, eine Lotterie zu sein, und wird zum Lehrplan.
Unten stehen die sechs Regeln, ein durchgerechnetes Beispiel und was du mit dem Ergebnis anfängst. Wenn du dir den Durchgang von Hand sparen willst, füg die Anzeige in den kostenlosen Question Predictor ein, und du bekommst die zwanzig Fragen, die dieses Gespräch am wahrscheinlichsten stellt, nach Typ gruppiert, mit dem, was jede davon abklopft. Kein Account, keine E-Mail, Ergebnisse sofort.
Kann man Interviewfragen wirklich aus einer Stellenbeschreibung vorhersagen?
Größtenteils ja. Den exakten Wortlaut kannst du nicht kennen, aber du kannst hunderte mögliche Fragen auf ungefähr zwanzig eindampfen, weil dein Gegenüber mit demselben Dokument arbeitet wie du. Zu jeder Anforderung, jeder Aufgabe und jeder Kulturzeile in dieser Anzeige gehört eine offensichtliche Frage, und Interviewer greifen viel häufiger zur offensichtlichen, als Kandidaten erwarten.
Was du nicht vorhersagen kannst, ist der Rest: die Lieblingsfrage deines Gegenübers, der Abstecher, weil etwas in deinem Lebenslauf hängengeblieben ist, das Algorithmus-Rätsel aus einem gemeinsamen Fragenpool. Dieser Rest ist real, und er ist klein. Sei für die zwanzig aus der Anzeige vorbereitet, dann improvisierst du nur noch den Rest, und das ist ein völlig anderes Problem.
Warum sagen Stellenanzeigen die Fragen so zuverlässig voraus?
Weil die Anzeige meist der erste Entwurf des Bewertungsbogens ist. Eine Führungskraft schreibt auf, was die Person tun muss, das Recruiting macht daraus eine Anzeige, und dieselbe Liste kommt als Kriterienkatalog zurück, nach dem Interviewer bewerten. Niemand schreibt einen zweiten, geheimen Satz Anforderungen. Das Dokument, mit dem du entschieden hast, ob du dich bewirbst, ist genau das, mit dem sie entscheiden, ob sie dich einstellen.
Strukturiertes Hiring macht das noch enger. Wenn ein Unternehmen mit einem Raster arbeitet, hat dein Gegenüber ein Formular mit Kompetenzen auf der einen Seite und Platz für Belege daneben, und sein Job ist es, mit einem ausgefüllten Formular rauszugehen. Der schnellste Weg dahin: direkt nach jedem Kriterium fragen. Unstrukturierte Gespräche landen auf dem faulen Weg am selben Punkt. Wer nichts vorbereitet hat, überfliegt fünf Minuten vorher die Anzeige und fragt nach dem, was draufsteht.
Wie machst du aus einer Stellenbeschreibung Interviewfragen?
Geh die Anzeige Zeile für Zeile durch und wende sechs Regeln an. Jede Art von Zeile wird zu einer vorhersehbaren Art von Frage: Aus Anforderungen werden Erfahrungsfragen mit einer Tiefenbohrung dahinter, aus Aufgaben werden Szenarien, aus Sprache über das Umfeld werden Verhaltensfragen, aus Nice-to-haves werden neugierige Nachfragen, wiederkehrende Themen werden zum Schwerpunkt, und die Verben entscheiden, ob es ums Machen oder ums Entscheiden geht.
1. Aus einer gelisteten Anforderung wird "erzähl mir von deiner Erfahrung mit X", dann eine Tiefenbohrung. Aus der Zeile "4+ Jahre Backend-Erfahrung, idealerweise Python" wird "führ mich mal durch deine Python-Erfahrung", und danach "was war der unangenehmste Bug, den du je in einem Python-Service jagen musstest?" Die erste Frage prüft, ob die Behauptung existiert. Die zweite prüft, ob sie echt ist, denn vier Jahre kann jeder behaupten, und nur wer sie erlebt hat, hat eine Kriegsgeschichte parat. Halt für jede harte Anforderung ein Artefakt bereit: etwas, das du gebaut, entschieden oder repariert hast.
2. Aus einer Aufgabe wird eine Szenario-Frage. Aus der Zeile "Verantwortung für die Zuverlässigkeit der Tracking-API, inklusive Teilnahme an der Rufbereitschaft" wird "erzähl mir vom schlimmsten Incident, für den du rausgeklingelt wurdest, und was du in den ersten zehn Minuten gemacht hast". Aufgaben beschreiben, womit deine Tage gefüllt sein werden, also testen Interviewer sie, indem sie dich einen Tag nacherzählen lassen, der schon passiert ist. Aus einer Aufgabe wird selten eine Wissensfrage, sondern die Bitte um eine Geschichte, und Geschichten brauchen Details.
3. Aus einer Zeile über Kultur oder Arbeitsumfeld wird eine Verhaltensfrage. Das sind die Zeilen, die Kandidaten überfliegen, und sie gehören zu den zuverlässigsten Vorhersagen im ganzen Dokument. Aus "schnelllebiges Umfeld, in dem sich Anforderungen ändern" wird eine Frage nach Priorisierung und danach, was du schleifen lässt. Aus "Umgang mit Unklarheit" wird eine Frage nach einer Entscheidung ohne vollständiges Bild. Aus "crossfunktional" wird eine Frage danach, wie du Leute überzeugst, die dir nicht unterstellt sind. Das Unternehmen benennt die Reibung, die dort normal ist, und Interviewer bohren genau da nach.
4. Aus einem "nice to have" wird eine neugierige Nachfrage und eine Chance, Lerngeschwindigkeit zu zeigen. Aus der Zeile "Erfahrung mit Kubernetes oder Terraform von Vorteil" wird "hast du schon mal was mit Terraform gemacht?", locker gefragt, oft gegen Ende. Sie wird auch locker bewertet, und genau deshalb ist das die billigste Stelle im ganzen Gespräch, um ehrlich zu sein. Sag, was du wirklich angefasst hast, und zeig dann das Muster: das letzte unbekannte Tool, das du dir angeeignet hast, wie lange es gedauert hat, was du damit ausgeliefert hast. Hier zu bluffen ist der schlechteste Tausch überhaupt. Der Gewinn ist ein Bruchteil eines Punkts, der Verlust ist alles andere, was du behauptet hast und was still abgewertet wird.
5. Ein wiederkehrendes Wort oder Thema ist der Schwerpunkt des Gesprächs. Lies die Anzeige noch einmal mit einem Stift und zähl Substantive. Wenn "Skalierung", "Kunden", "Datenqualität" oder "Migration" drei Mal oder öfter in verschiedenen Abschnitten auftaucht, ist das kein Füllmaterial, sondern das, was die Führungskraft nachts wach hält. Daraus entstehen mehrere Fragen statt einer, es wird vermutlich das Thema jeder System-Design-Aufgabe, und dort kostet eine schwammige Antwort am meisten.
6. Die Seniority-Verben verraten dir, ob es ums Machen oder ums Entscheiden geht. Vergleich "an Code Reviews mitwirken" mit "unseren Ansatz für Code-Qualität definieren". Das erste lädt zu Ausführungsfragen ein: was du gemacht hast, wie, woher du weißt, dass es funktioniert hat. Das zweite lädt zu Urteilsfragen ein: warum dieser Ansatz und nicht der andere, was du dafür aufgegeben hast, wie du andere überzeugt hast. Unterstützen, begleiten und mitwirken zeigen aufs Machen. Verantworten, führen, definieren und treiben zeigen aufs Entscheiden, und wer eine Entscheidungsfrage mit einer Ausführungsgeschichte beantwortet, wirkt eine Stufe zu junior.
Wie sieht die Umrechnung an einer echten Stellenanzeige aus?
Hier ist ein Auszug aus einer Mid-Level-Backend-Rolle bei einem mittelgroßen Logistikunternehmen, geschrieben so, wie echte Anzeigen geschrieben sind, nicht so aufgeräumt wie Beispiele es normalerweise sind. Jede Zeile wird zu etwas. Die Tabelle darunter zeigt die wahrscheinliche Frage und, deutlich nützlicher, was wirklich abgeklopft wird.
Backend Engineer (Mid-Level)
- Bau und pflege die Python-Services hinter unserer Sendungsverfolgungs-Plattform.
- Verantworte die Zuverlässigkeit der Tracking-API, inklusive Teilnahme an der Rufbereitschaft.
- Arbeite mit dem Data-Team zusammen, damit die Event-Feeds der Frachtführer korrekt und aktuell bleiben.
- Entwirf unsere PostgreSQL-Schemas und entwickle sie weiter, während die Sendungsvolumen wachsen.
- Arbeite mit Product und Operations zusammen, um vage Lagerprobleme in ausgelieferte Features zu verwandeln.
- Wirke an Code Reviews mit und hilf, den Standard der Codebase zu heben.
Anforderungen: 4+ Jahre Backend-Erfahrung, idealerweise Python. Starkes SQL inklusive Performance-Arbeit. Erfahrung mit Message Queues (wir nutzen Kafka). Wohlfühlen in einem schnelllebigen Umfeld, in dem sich Anforderungen ändern.
Nice to have: Berührung mit Logistik- oder Supply-Chain-Systemen; Kubernetes oder Terraform.
| Zeile aus der Anzeige | Die Frage, die daraus am wahrscheinlichsten wird | Was wirklich abgeklopft wird |
|---|---|---|
| Python-Services bauen und pflegen | Führ mich durch einen Python-Service, den du end to end gebaut hast | Tiefe der Behauptung, und ob du je lange genug gepflegt hast, um eine Entscheidung zu bereuen |
| Zuverlässigkeit verantworten, Rufbereitschaft | Erzähl mir vom schlimmsten Incident, für den du rausgeklingelt wurdest | Ob du je einen Pager getragen hast, und ob du Menschen oder Systemen die Schuld gibst |
| Mit dem Data-Team an der Feed-Qualität arbeiten | Wie würdest du merken, dass ein vorgelagerter Feed kaputt ist? | Gespür für Datenkorrektheit, und Umgang mit einem Problem, das du nicht selbst beheben kannst |
| PostgreSQL-Schemas entwerfen und weiterentwickeln | Erzähl mir von einer Schema-Änderung an einer bereits großen Tabelle | Urteilsvermögen bei Migrationen, Locking und Downtime, Bereitschaft, einen Rollback zu planen |
| Mit Product und Operations an vagen Lagerproblemen arbeiten | Erzähl mir von einer Situation, in der die Anforderungen vage waren und du entscheiden musstest, was gebaut wird | Ob du widersprichst oder still das Falsche baust, und ob du Operations-Leute als Nutzer oder als Tickets behandelst |
| An Code Reviews mitwirken | Wie gibst du Feedback zu einem Pull Request, mit dem du nicht einverstanden bist? | Ton unter Reibung, und ob Standards Zeitdruck überleben |
| 4+ Jahre, idealerweise Python | Deine Python-Erfahrung, dann der härteste Bug darin | Existenz der Behauptung, dann ihre Realität |
| Starkes SQL und Performance-Arbeit | Erzähl mir von einer langsamen Query, die du gefixt hast | Ob du einen Query-Plan lesen kannst oder nur hoffnungsvoll Queries umschreibst |
| Erfahrung mit Kafka | Führ mich durch einen Consumer, der zurückgefallen ist, und was du gemacht hast | Echte Betriebserfahrung, denn die Doku hat jeder gelesen |
| Schnelllebig, Anforderungen ändern sich | Erzähl mir von einer Situation, in der sich die Prioritäten mitten im Projekt verschoben haben | Kriterien für Priorisierung, und ob du jammerst |
| Nice to have: Kubernetes oder Terraform | Hast du überhaupt schon mal Terraform angefasst? | Ehrlichkeit, und wie schnell du dir unbekanntes Tooling aneignest |
Zwei Dinge fallen dabei ab. Der Schwerpunkt ist Datenkorrektheit bei wachsendem Volumen, denn Sendungen, Feeds, Schemas, Queues und Skalierung zeigen alle auf dieselbe Sorge, und genau dort landen mehrere Fragen. Und die Verben sind gemischt: "verantworte" und "entwirf" stehen neben "wirke mit", die Rolle entscheidet also über die Tracking-API und führt bei Code-Qualität nur aus. Bereite für das Erste Urteilsantworten vor, für das Zweite Ausführungsantworten.
Wie priorisierst du, was du vorbereitest?
Bereite dich auf Themen vor, nicht auf Fragen. Zwanzig vorhergesagte Fragen sind keine zwanzig Antworten, die du schreiben musst, sondern fünf oder sechs Themen mit wechselnden Hüten. Gruppier die Fragen danach, was sie abklopfen, such dir sechs bis acht echte Episoden aus deiner Laufbahn und ordne jeder zwei oder drei Themen zu. Diese Zuordnung ist der Trick: Unter Druck willst du aus einem bekannten Satz auswählen, nicht dein Gedächtnis von vorn durchsuchen.
Nimm das Logistik-Beispiel. Diese Fragen fallen auf fünf Themen zusammen: Tiefe im genannten Stack, Verantwortung im Fehlerfall, Urteilsvermögen bei Daten und Migrationen, Zusammenarbeit mit nicht-technischen Partnern, und Verhalten, wenn sich Prioritäten verschieben. Eine gute Geschichte über eine schiefgelaufene Migration bedient Verantwortung, Urteilsvermögen und Druck auf einmal, je nachdem, mit welchem Beat du anfängst. Schreib die Zuordnung von Geschichte zu Thema auf eine Seite und lern daraus, nicht aus der Fragenliste.
Bau jede Geschichte nach STAR (Situation, Task, Action, Result), weil die meisten Bewertungsraster danach punkten und weil es dich davon abhält, deinen Beitrag unter drei Minuten Kontext zu begraben. Unser Guide zur STAR-Methode hat komplett ausgearbeitete Antworten, und der Guide zu Verhaltensfragen im Vorstellungsgespräch deckt die zwanzig ab, die unabhängig von der Rolle immer wiederkommen, die Basisschicht, auf der deine anzeigenspezifischen Fragen sitzen. Danach übst du laut und mit Stoppuhr, denn eine Geschichte, die auf Papier knackig wirkt, franst gesprochen auf vier Minuten aus.
Was werden sie mich im Vorstellungsgespräch fragen?
Ehrlich gesagt kann dir niemand die exakten Fragen nennen, und wer etwas anderes behauptet, will dir was verkaufen. Was die Anzeige leistet: Sie schrumpft das Feld auf etwa zwanzig wahrscheinliche Fragen, und das sind wenige genug, um sich ordentlich vorzubereiten. Die Methode ist mechanisch: jede Zeile mit den sechs Regeln umwandeln, danach sortieren, wie oft sich ein Thema wiederholt, und von oben nach unten vorbereiten.
Die zwanzig teilen sich immer ähnlich auf. Rechne mit fünf oder sechs Erfahrungsfragen direkt aus der Anforderungsliste, jede mit einer Tiefenbohrung dahinter. Rechne mit vier oder fünf Szenario-Fragen aus den Aufgaben, das sind Bitten um Geschichten, keine Wissenschecks. Rechne mit fünf oder sechs Verhaltensfragen aus den Zeilen zu Umfeld und Kultur, mit zwei oder drei lockeren Nachfragen zu den Nice-to-haves, und mit den zwei Fragen aus praktisch jedem Gespräch, das je geführt wurde: "Erzählen Sie etwas über sich" und "warum diese Rolle".
Mach die Umwandlung einmal von Hand, weil sie dauerhaft verändert, wie du Anzeigen liest. Danach spar dir die Stunde und füg die Anzeige in den kostenlosen Predictor ein. Er gibt dir die zwanzig wahrscheinlichsten Fragen für dieses Gespräch zurück, nach Typ gruppiert, mit einer Notiz dazu, was jede abklopft. Kein Account, keine E-Mail, Ergebnisse sofort. Er sagt vorher, er weiß nicht, und das ist die ehrliche Formulierung: eine gute Karte davon, woher die Fragen kommen, keine Kopie der Notizen deines Gegenübers.
Häufige Fragen
Kann ich technische Interviewfragen aus der Stellenbeschreibung vorhersagen?
Themen ja, Rätsel nein. Die Anzeige nennt den Stack, die Daten und die Fehlerfälle, und das sagt System-Design-Aufgaben und sprachspezifische Tiefenbohrungen zuverlässig vorher. Eine Algorithmus-Frage kann sie nicht vorhersagen, weil die meist aus einem internen Fragenpool kommt und selten etwas mit der Rolle zu tun hat. Lern den genannten Stack in die Tiefe und üb Algorithmen separat.
Was, wenn die Stellenbeschreibung vage ist?
Eine vage Anzeige ist selbst eine Vorhersage: Generische Zeilen erzeugen generische Fragen, also rechne mit dem Standard-Set an Verhaltensfragen plus einem breiten Durchgang durch deinen Lebenslauf. Füll die Lücken woanders: die Karriereseite des Unternehmens, die öffentliche Arbeit des Teams, aktuelle Engineering-Posts, und das Recruiting, das dir auf Nachfrage meist den Ablauf der Runden und die Interviewer beschreibt.
Soll ich Antworten Wort für Wort vorbereiten?
Nein. Auswendig gelernte Antworten kommen flach rüber, und sie brechen zusammen, sobald eine Frage anders formuliert ist als die Version, die du gelernt hast. Lern jede Geschichte als fünf oder sechs Beats mit einer Zahl am Ende, und sag sie so lange laut, bis die Beats auch unter Druck in der Reihenfolge bleiben. Die einzigen Sätze, die es lohnt festzuzurren, sind der erste Satz und das abschließende Ergebnis.