Lehren aus rund 1.000 Interviews bei Amazon

• Basierend auf 17 Jahren Arbeit bei Amazon und rund 1.000 geführten Interviews (davon etwa 600 Bar-Raiser-Interviews) analysiert der Beitrag, welchen Einfluss Verhaltensinterviews im Vergleich zu technischen Interviews auf Einstellungsentscheidungen haben
• Der Hauptgrund, warum technisch starke Kandidaten abgelehnt werden, ist nicht mangelnde Technik, sondern die Art, wie sie sich darstellen
• Die größte Schwachstelle ist, dass 95 % der Vorbereitungszeit in technische Vorbereitung fließen, während für die Vorbereitung auf Verhaltensinterviews fast keine Zeit aufgewendet wird
• Ein Interview ist keine Prüfung, sondern eher ein Vorsprechen, bei dem beurteilt wird: „Möchte man mit dieser Person zusammenarbeiten?“
• Im Verhaltensinterview bewerten Unternehmen vor allem Rollen-Fit, Unternehmens-Fit und das Level, und wer das versteht, kann bessere Geschichten auswählen

---

Zentrale Muster aus Bar-Raiser-Interviews

• Ein Bar Raiser ist ein speziell geschulter Interviewer von außerhalb des Hiring-Teams, dessen Aufgabe es ist zu prüfen, ob eine Neueinstellung das Talentniveau bei Amazon anhebt
• Er oder sie hat bei jedem Kandidaten ein Vetorecht und nimmt an Interview-Loops aller Level teil, vom Praktikanten bis zum Principal Engineer
• Nach etwa 50 Bar-Raiser-Interviews wurde ein klares Muster sichtbar: Die meisten Kandidaten ohne Angebot scheiterten nicht an fehlender technischer Kompetenz, sondern daran, sich nicht gut darstellen zu können
• Wer die finale Runde erreicht, hat technische Screens und Aufgaben bereits bestanden; die Kernfrage in der Schlussrunde lautet daher: „Will dieses Team mit dieser Person zusammenarbeiten?“

• Lehre 1: Für die eine Interviewart wird übermäßig, für die andere zu wenig vorbereitet

  • Der durchschnittliche Kandidat investiert 95 % seiner Zeit in technische Vorbereitung und 5 % in den Rest; manche verwenden für nichttechnische Vorbereitung gar keine Zeit
  • Technische Vorbereitung ist attraktiv, weil sie konkret ist und sich Fortschritt messen lässt; bei Coding-Aufgaben kann man selbst bei unbekannten Problemen mit Hinweisen oft noch logisch weiterkommen
  • Bei Verhaltensfragen wie „Wie sind Sie damit umgegangen, als ein Projekt schieflief?“ ist spontane Improvisation dagegen unmöglich, wenn keine vorbereitete Geschichte vorhanden ist
    • Es gibt keine Hinweise, kein Denken in Echtzeit hilft weiter, und ohne Vorbereitung enden Antworten oft ungeordnet
  • Hunderte Male wurde beobachtet, wie Kandidaten Coding-Runden stark meisterten und dann bei Fragen zu ihren Erfahrungen einbrachen
    • Feedback im Debrief: „Ich konnte keine konkreten Antworten herausbekommen, alle Geschichten waren vage und nicht überzeugend.“
  • Nichttechnische Vorbereitung braucht viel weniger Zeit als technische: Von 80 bis 100 Stunden Interviewvorbereitung kann schon ein einziges Wochenende (etwa 10 Stunden) für Story-Vorbereitung das Ergebnis im Verhaltensinterview komplett verändern
  • Der Ertrag technischer Vorbereitung nimmt schnell ab, während der Ertrag aus Story-Vorbereitung nahezu exponentiell ist, weil sie kaum jemand macht

• Lehre 2: Wie eine Geschichte erzählt wird, ist genauso wichtig wie die Geschichte selbst

  • Selbst die beeindruckendste Leistung kann durch schlechte Vermittlung völlig verpuffen; das häufigste Scheitermuster ist „ramble and stumble“
    • Also wenn Kandidaten so wirken, als würden sie ihre Geschichte erst während des Erzählens zusammenbauen, oder nach fünf Minuten Kontext noch vergessene Details nachreichen
  • Für wichtige Präsentationen im Job bereiten Menschen Struktur, Ablauf und Kernpunkte vor und proben sie, aber im Interview improvisieren viele
  • Viele empfinden vorbereitete Interviewgeschichten als „unnatürlich“ oder „unehrlich“, doch wie ein Musiker vor einem Konzert probt, hat Üben nichts mit fehlender Authentizität zu tun
  • Praktischer Einstieg: mit den zwei Fragen „Erzählen Sie etwas über sich“ und „Warum möchten Sie bei diesem Unternehmen arbeiten?“ beginnen
    • Antworten aufschreiben, aufnehmen und die Aufnahme ansehen, um zu erkennen, wo man ausschweift oder unnötige Füllwörter benutzt
    • So lange wiederholen, bis der Eindruck entsteht: „Mit dieser Person möchte ich zusammenarbeiten.“
  • 30 Minuten dieser Übung können die Interviewleistung stärker verbessern als 20 Stunden Coding-Training

• Lehre 3: Ein Interview ist ein Vorsprechen dafür, wie die Zusammenarbeit aussehen würde

  • Die meisten Kandidaten betrachten Interviews als Prüfung, dabei gibt es keinen Lösungsschlüssel; vielmehr bilden Interviewer einen Eindruck
  • Die konkrete Aufgabe eines Bar Raisers ist es zu beurteilen, ob ein Kandidat besser ist als die oberen 50 % der bereits in dieser Rolle beschäftigten Mitarbeiter
  • Die Coding-Fragen im Interview unterscheiden sich von der realen Arbeit, aber Verhaltensfragen testen Alltagssituationen direkt: Meinungsverschiedenheiten lösen, auf Projektkrisen reagieren, mit unvollständigen Informationen entscheiden
    • Wenn nach einer Erfahrung gefragt wird, in der man einem Stakeholder widersprochen hat, stellen sich Interviewer die Person in der nächsten Planungsrunde vor
    • Wenn jemand erklärt, wie er mit Konflikten im Team umgeht, fragen sie sich: „Möchte ich mit dieser Person in einem Raum sein?“
  • Kandidaten, die Interviews wie Prüfungen angehen, raten oft, was Interviewer hören wollen, und liefern glatte, kantenlose Antworten
    • Das Ergebnis: Unsicherheit nach dem Motto „Ich kann überhaupt nicht einschätzen, wie es wäre, mit dieser Person tatsächlich zu arbeiten“ → meist ein „No“
  • Praktische Methode: Geschichten nicht danach vorbereiten, was Interviewer hören wollen könnten, sondern danach, was man selbst von jemandem hören möchte, der dem eigenen Team beitreten will
    • Die echte Version ehrlich erzählen, inklusive schwieriger Momente und knapper Entscheidungen

Zentrales Fazit aus rund 1.000 Interviews

• Eingestellt werden Menschen, die den Raum betreten und klare Geschichten über ihre Arbeit und ihre Fähigkeiten erzählen, sodass Interviewer denken: „Mit dieser Person möchte ich zusammenarbeiten.“
• Die Fähigkeit, Geschichten gut zu vermitteln, ist eine durch Übung verbesserbare Kompetenz, aber die meisten trainieren sie nicht, weil sie sie nicht als vorbereitbaren Bereich ansehen
• Schon ein wenig Vorbereitung hat einen größeren Effekt als fast alles andere, was man in seiner Karriere tun kann

Worauf Unternehmen in Verhaltensinterviews achten

• Technische Stärke allein entscheidet nicht über ein Angebot; Unternehmen beantworten im Verhaltensinterview zwei zentrale Fragen: „Passt diese Person zur Rolle und zum Unternehmen?“ und „Auf welchem Level ist sie am wirksamsten?“
• Wenn der Fit nicht stimmt, scheitert man trotz starker Technik; wenn das Level falsch eingeschätzt wird, folgt ein Downleveling oder eine Absage wegen mangelnder Eignung

• Fit verstehen: Rollen-Fit und Unternehmens-Fit

  • Rollen-Fit (Role Fit): ob jemand die spezifischen Herausforderungen und Arbeitsbedingungen der Position tragen kann
    • Eine Backend-Rolle in einem schnell wachsenden Startup und eine Backend-Rolle in einem Großunternehmen können technisch ähnlich sein, stellen aber unterschiedliche Anforderungen
  • Unternehmens-Fit (Company Fit): ob jemand in der Umgebung dieser Organisation erfolgreich sein kann
    • Bewertet wird, ob Arbeitsstil, Entscheidungsweise und Werte zur Arbeitsweise des Unternehmens passen

• Wie Unternehmen Fit-Signale erkennen

  • Eine direkte Frage wie „Passen Sie zu unserem Unternehmen?“ ist kaum möglich, daher suchen Unternehmen in Kandidatengeschichten nach Signalen von Übereinstimmung oder Nichtübereinstimmung
  • Signale für Rollen-Fit: Sicherheit im Umgang mit unklaren Anforderungen, Fähigkeit zur teamübergreifenden Abstimmung, schnelle Iteration und Aufnahme von Feedback
  • Signale für Unternehmens-Fit: zeigen sich in den Entscheidungen des Kandidaten und in der Art, wie er sie erklärt
    • Ein Unternehmen mit Fokus auf bias for action bevorzugt Geschichten, in denen trotz unvollständiger Information schnell gehandelt wurde
    • Ein Unternehmen mit Fokus auf customer obsession will Beispiele sehen, in denen tief in Nutzerbedürfnisse eingetaucht wurde
    • Ein Unternehmen, das radical transparency betont, sucht Geschichten, in denen Informationen auch dann offen geteilt wurden, wenn das unangenehm war
  • Dieselbe Geschichte sendet je nach Unternehmen unterschiedliche Signale: Ein Fall, in dem eine Lösung drei Wochen lang perfektioniert wurde, kann in einem Unternehmen als Qualitätsfokus, in einem anderen als Analyse-Paralyse gelten

• Häufige Formen von Mis-Fit

  • Unabhängigkeit vs. Zusammenarbeit: Probleme allein lösen und dann zurückkommen vs. das Team in jedem Schritt einbeziehen
    • Wenn alle Geschichten von Einzelarbeit handeln, ist das in konsensorientierten Unternehmen ein Warnsignal; wenn alle Geschichten von Gruppenabstimmung handeln, ist es umgekehrt in Unternehmen mit starkem Fokus auf Eigenverantwortung ein Warnsignal
  • Geschwindigkeit vs. Gründlichkeit: schnelle Experimente und MVPs im Startup vs. sorgfältige Validierung in Medizin oder Finanzwesen
    • Dazu gehört auch die Sicht auf Code-Qualität: zusätzliche Zeit für saubere Architektur investieren vs. eine funktionierende Lösung rechtzeitig liefern
  • Exzellenz vs. Pragmatismus: technische Perfektion und saubere Architektur zuerst vs. pragmatische Lösungen, die trotz Unvollkommenheit fristgerecht live gehen
  • Innovation vs. Stabilität: neue Lösungen schaffen und bestehende Ansätze infrage stellen vs. bewährte Systeme erhalten und optimieren
  • Direktheit vs. Diplomatie: eine Kultur der radical candor vs. eine Kultur, die Harmonie und Gesichtswahrung betont
  • Daten vs. Intuition: eine Kultur, die für jede Entscheidung Datengrundlagen verlangt, vs. eine Kultur, die erfahrungsbasierter Einschätzung vertraut
  • Spezialist vs. Generalist: tiefe Expertise in einem Bereich im Großunternehmen vs. Fähigkeit, in kleineren Firmen verschiedene Rollen zu übernehmen

Vier Dimensionen zur Bestimmung des Levels

• Das Level eines Kandidaten wird über vier Dimensionen bewertet, die in jeder Geschichte sichtbar werden und gemeinsam zeigen, wo jemand am effektivsten arbeitet

• Scope (Umfang)

  • Misst die Zahl der betroffenen Personen und die Reichweite der Arbeit
  • Entry Level: Steigerung der eigenen Produktivität, Hilfe für einige wenige Teammitglieder
  • Mid Level: Einfluss auf Teile der Arbeitsweise eines Teams
  • Senior Level: direkter Einfluss auf das gesamte Team, beginnende Ausweitung auf mindestens ein weiteres Team, enge Zusammenarbeit mit Product- und Design-Partnern
  • Staff Level: direkter Einfluss auf mindestens zwei Teams, Ausweitung auf die breitere Organisation, Einfluss über Engineering hinaus bis in Product, Design und Program Management
  • Principal Level: verändert, wie große Teile mehrerer Teams oder ganzer Organisationen arbeiten, mit Einfluss bis in die Geschäftsstrategie

• Contribution (Beitrag)

  • Misst was die Person tatsächlich selbst getan hat, indem die Grenze zwischen „ich“ und „wir“ klar gezogen wird
  • Entry Level: erledigt zugewiesene Aufgaben, übernimmt volle Verantwortung für klar definierte Features
  • Mid Level: besitzt komplette Lösungen vom Erkennen des Problems bis zur Umsetzung und leitet zugleich andere an
  • Senior Level: führt Initiativen, die Abstimmung erfordern, und bringt auch bei unklaren Anforderungen oder unsicherer Richtung Fortschritt
  • Staff Level: leitet teamübergreifende Initiativen, setzt technische Richtung und geht mit widersprüchlichen Prioritäten von Stakeholdern um
  • Principal Level: schafft organisatorische Fähigkeiten, etabliert neue Arbeitsweisen und arbeitet in hochgradig mehrdeutigen Umgebungen, in denen das Problem selbst erst definiert werden muss

• Impact (Wirkung)

  • Zeigt, was durch die Arbeit besser geworden ist, und wichtig sind Zahlen, die technische Ergebnisse mit Business- oder Nutzerergebnissen verbinden
  • Entry Level: höhere persönliche Produktivität, weniger Zeit für wiederkehrende Aufgaben, Vermeidung von Bugs
  • Mid Level: messbare Verbesserungen der Teamwirksamkeit in einem Bereich, etwa kürzere Deployment-Zeiten oder neue Tools
  • Senior Level: verändert, wie ein ganzes Team arbeitet, breitet sich auf benachbarte Teams aus und beeinflusst Produktergebnisse, User Experience oder Betriebskosten
  • Staff Level: verbessert die Arbeit mehrerer Teams und lässt sich mit Business-Kennzahlen wie Umsatz, Kundenbindung oder Release-Geschwindigkeit verbinden
  • Principal Level: schafft organisatorische Fähigkeiten, treibt strategische Veränderungen und wird an Geschäftsergebnissen und strategischer Wirkung gemessen

• Difficulty (Schwierigkeit)

  • Spiegelt Komplexität, Einschränkungen und Trade-offs des gelösten Problems wider; ein schwierig gelöstes Problem ist beeindruckender als ein leichtes Problem mit großer Wirkung
  • Entry Level: geradlinige Probleme innerhalb etablierter Muster, etwa neue Technologien lernen oder unbekannten Code debuggen
  • Mid Level: Probleme mit mehr beweglichen Teilen und weniger offensichtlichen Lösungen, inklusive widersprüchlicher Anforderungen oder neuer technischer Komplexität
  • Senior Level: Umgang mit Einschränkungen in mehreren interagierenden Systemen, Architekturentscheidungen auf Teamebene, Berücksichtigung technischer und geschäftlicher Faktoren
  • Staff Level: Abwägung widersprüchlicher Trade-offs über mehrere Teams hinweg, wenn Teams tatsächlich kollidierende Bedürfnisse haben und verschiedene technische Ansätze ausbalanciert werden müssen
  • Principal Level: Umgang mit grundlegenden Trade-offs zwischen organisatorischen Bedürfnissen, Lösung neuartiger Probleme ohne etablierte Muster oder Präzedenzfälle und Entscheidungen auf Unternehmensstrategie-Ebene mit Zustimmung des Top-Managements

Recherchieren, was Unternehmen wirklich wichtig ist

• Perfekte Information ist unmöglich, aber mit etwas fokussierter Recherche lassen sich Einsichten gewinnen, die die meisten anderen Kandidaten verpassen

• Recruiter nutzen

  • Die meisten Kandidaten behandeln Recruiter nur als Torwächter, in Wirklichkeit sind sie aber oft die beste interne Informationsquelle
  • Der Erfolg von Recruitern basiert auf der Zahl der angenommenen Angebote, deshalb wollen sie, dass Kandidaten erfolgreich sind
  • Direkt fragen: „Was sind aktuell die Herausforderungen des Unternehmens?“, „Welche Fähigkeiten sind in dieser Rolle am wichtigsten?“ und „Können Sie Materialien zur Interviewvorbereitung teilen?“
  • Beispielhafte Fragen in Vorbereitungsunterlagen sind mit hoher Wahrscheinlichkeit nah an echten Interviewfragen

• Öffentliche Informationen nutzen

  • Wiederkehrende Wörter in Stellenausschreibungen verraten, was ein Unternehmen wichtig findet: „fast-paced“ und „compliance“ senden sehr unterschiedliche Signale
  • Orte zum Nachsehen: Engineering-Blogs (welche Erfolge gefeiert werden), Tech Talks und Konferenzen (Themen der Vorträge), Open-Source-Beiträge (was veröffentlicht wird), technische Dokumentation (Qualität öffentlich zugänglicher API-Dokumente), Status Pages und Postmortems (ob es eine Kultur des Lernens aus Fehlern gibt)
  • Auch ohne Engineering-Blog lassen sich Prioritäten an Release-Mustern (Entwicklungsgeschwindigkeit) und Technologieentscheidungen (Innovation vs. Stabilität) erkennen

• Diskussionsmuster analysieren

  • Auf Glassdoor, Blind und Reddit einzelne Beschwerden ignorieren und stattdessen Muster über mehrere Beiträge hinweg suchen
  • Beschwerden wie „zu viele Meetings“ können auf eine stark kollaborative, konsensorientierte Kultur oder auf Produktivitätsverlust durch Meeting-Übermaß hindeuten
  • Lob für „Autonomie“ deutet auf ein Umfeld hin, in dem man bei Entscheidungen Vertrauen ohne ständige Rückversicherung erhält

• Mit aktuellen Mitarbeitern sprechen

  • Statt oberflächlicher Kulturfragen sind konkrete Fragen nötig
    • „Wofür werden Menschen hier befördert?“
    • „Welches Verhalten führt zu negativem Feedback?“
    • „Wie trifft das Team Entscheidungen, wenn Meinungen auseinandergehen?“
    • „Was hat Sie an der Arbeit hier am meisten überrascht?“
  • Aktuelle Mitarbeiter liefern Wahrheiten, die auf keiner Unternehmenswebsite stehen: customer obsession kann in der Praxis bedeuten, vor dem Schreiben von Code zuerst Nutzungsdaten zu prüfen, und ownership kann heißen, um 2 Uhr nachts für Produktionsprobleme bereitstehen zu müssen

• Das eigentliche Ziel der Recherche

  • Jede Recherche dient einem Zweck: herauszufinden, welche Geschichten im Interview Resonanz erzeugen
  • Wenn Geschwindigkeit zählt, sollten Geschichten betont werden, in denen schnell ausgeliefert und iteriert wurde; wenn technische Tiefe zählt, Geschichten über Ursachenanalyse; wenn Zusammenarbeit zählt, der Fokus auf teamübergreifender Arbeit
  • Recherche hilft auch bei der Entscheidung, ob ein Unternehmen überhaupt passt: Wenn eine Firma Verhaltensweisen wertschätzt, die man weder natürlich zeigt noch entwickeln möchte, lohnt sich die Rolle womöglich nicht

Zusammenfassung

• Unternehmen bewerten nicht nur, ob jemand die Arbeit erledigen kann, sondern auch die Wahrscheinlichkeit von Erfolg in einem bestimmten Umfeld und das am besten passende Level
• Fit zu verstehen hilft dabei, Erfahrungen auszuwählen, die am stärksten mit den Werten des Unternehmens verknüpft sind
• Das Verständnis von Levels hilft beim richtigen Positionieren von Geschichten: Dasselbe Projekt kann je nach tatsächlichem Beitrag und Framing wie Entry-Level-Ausführung, Mid-Level-Ownership oder Senior-Level-Leadership wirken
• Das Ziel ist nicht irgendein Angebot, sondern das richtige Angebot im richtigen Unternehmen auf dem richtigen Level, das Erfolg wahrscheinlich macht