Wie ich das Vorstellungsgespräch bei Adobe bestanden habe

TL;DR

• Ich habe bei Adobe ein Angebot für eine Produkt-Engineering-Stelle bekommen, nachdem ich in der Runde, in der man ein selbst gebautes System erklären soll, fast durchgefallen wäre.
• Mein Prozess bestand aus einem Recruiter-Call, einem einstündigen Technical Screen und vier Onsite-Runden: praktisches Coding, ein Deep Dive in ein früheres Projekt, eine produktnahe Design-Runde und das Gespräch mit dem einstellenden Manager.
• Das Coding-Niveau lag näher an echter Arbeit als an schweren LeetCode-Aufgaben, und die Tiefe meiner Antworten zu eigenen Abwägungen zählte deutlich mehr als meine Geschwindigkeit bei Algorithmen.
• Würde ich noch einmal vorbereiten, ginge die erste Woche komplett in Entscheidungsprotokolle zu drei Projekten und erst die zweite in Code.

Einleitung

Ich habe mich an einem Dienstagabend vom Sofa aus bei Adobe beworben, mit demselben Lebenslauf, den ich in jenem Monat an elf andere Unternehmen geschickt hatte. Sechs Jahre als Softwareentwickler in einem Berliner Unternehmen mit rund 300 Leuten, hauptsächlich an der Asset-Pipeline eines Medienprodukts: Uploads, Formatkonvertierung, Vorschaubilder, Metadaten. Ich steckte im dritten Monat eines sehr disziplinierten und sehr falsch ausgerichteten Lernplans: 40 Minuten Algorithmen vor der Arbeit, 90 danach, dazu eine Tabelle mit einer Rot-Gelb-Grün-Spalte pro Aufgabentyp.

Am Ende hatte ich ein Angebot für eine Produkt-Engineering-Stelle auf mittlerer Ebene — und wäre eine Runde davor fast gescheitert, an etwas, das mit dieser Tabelle nichts zu tun hatte.

Wie ich überhaupt zum Gespräch kam

Die Online-Bewerbung passierte sechs Wochen lang nichts. Was sie in Bewegung gebracht hat, ist unspektakulär: Über eine ehemalige Kollegin habe ich eine Entwicklerin gefunden, die an genau der Produktoberfläche arbeitete, die mich interessierte. Kurze Nachricht — welcher Produktbereich, eine Sache, die ich daneben gebaut hatte, und die Frage, ob eine Empfehlung realistisch sei. Neun Tage später hatte ich eine Mail von einer Recruiterin.

Ich hatte 90 Prozent meiner Energie in „das Gespräch bestehen“ gesteckt und 10 Prozent in „das Gespräch bekommen“. Das richtige Verhältnis liegt eher bei 70 zu 30.

Zweiter Punkt, den ich falsch eingeschätzt hatte: Die vier Personen im Onsite saßen in drei Ländern, keine davon in Deutschland. Die Stelle war an ein europäisches Team angebunden, gearbeitet hätte ich hybrid aus Berlin. Wenn Sie in München oder Hamburg sitzen, ist die erste Frage nicht „gibt es ein Büro in meiner Stadt“, sondern „an welches Team und welche Zeitzone hängt die Stelle, und wie viele Tage Präsenz werden erwartet“. Ich habe zwei Wochen damit verloren, die Antwort einfach anzunehmen.

Der Recruiter-Call, 30 Minuten, Anfang April

Standard, aber keine Formalie. Es kamen zwei Fragen, mit denen ich von einer Recruiterin nicht gerechnet hatte:

• „Welches Produkt nutzen Sie täglich, bei dem Sie zu einer konkreten Designentscheidung eine klare Meinung haben?“
• „Nennen Sie etwas, das Sie gebaut haben und heute anders entscheiden würden.“

Die erste habe ich gut beantwortet, weil ich tatsächlich eine Meinung zum Undo-Verhalten eines Bildeditors habe. Die zweite habe ich vergeigt: „wir hätten mehr Tests schreiben sollen“, das Bewerbungsäquivalent zu „meine größte Schwäche ist mein Perfektionismus“. Ich habe gesehen, dass sie sich etwas notiert.

Sie hat mir außerdem den Ablauf genannt: Technical Screen, Coding, Deep Dive in frühere Arbeit, Design-Runde, Hiring Manager. Vier bis sechs Wochen bis zur Entscheidung; bei mir wurden es fünf.

Der Technical Screen, eine Stunde, Mitte April

Geteilter Editor, ein Entwickler aus einem Nachbarteam, und das erste Anzeichen dafür, dass ich das Falsche geübt hatte. Ich hatte in der Woche davor Sessions auf Zeit über PhantomCodeAI gemacht, ausschließlich klassische Algorithmenaufgaben — also genau die falsche Generalprobe.

Der Aufgabentyp: ein kleines strukturiertes Eingabeformat parsen, in eine sinnvolle Repräsentation im Speicher überführen, zwei bis drei Abfragen darauf beantworten. Dann erweitern. Dann fehlerhafte Eingaben behandeln, an die ich nicht gedacht hatte.

Nichts davon war schwer im LeetCode-Sinn, es gab keinen versteckten Kniff. Geprüft wurde eine einzige Frage: Schreibe ich Code, den ein anderer Mensch pflegen kann? Verständliche Namen, eine Datenstruktur, die zu den Abfragen passt statt zur Selbstdarstellung, Fehlerbehandlung, die laut scheitert, statt still eine leere Liste zurückzugeben.

Ich bin durchgekommen, aber als er mich bat, den Code zu erweitern, hat mein eigener Entwurf sich gewehrt: Ich hatte auf die erste Anforderung optimiert statt auf die Form des Problems. Er hat es nicht laut angemerkt, aber ich habe es in seiner Nachfrage gehört: „Wenn Sie gewusst hätten, dass das noch kommt — was hätten Sie am Anfang anders gemacht?“

Diese Frage, in wechselnder Verkleidung, war am Ende der gesamte Prozess.

Das Onsite: vier Runden in zwei Blöcken

Wegen eines Terminkonflikts auf ihrer Seite geteilt: zwei Runden an einem Donnerstag, die beiden anderen am folgenden Dienstag. Diese fünf Tage Abstand sind der einzige Grund, warum ich ein Angebot habe.

Runde 1: praktisches Coding, 55 Minuten

Eine konkrete Aufgabe mit Produktrahmen. Der Typ: aus einem Strom von Nutzeraktionen eine abgeleitete Sicht pflegen, die eine bestimmte Frage billig beantwortet, und anschließend das Rückgängigmachen der letzten N Aktionen unterstützen.

Interessant wird der Undo-Teil. Mein erster Entwurf hat die Sicht komplett neu berechnet, was korrekt und langsam ist. Der Interviewer hat mich zu Ende arbeiten lassen und dann gefragt, was passiert, wenn N groß und das Log lang ist. Ich habe laut abgewogen: eine Inversoperation pro Aktionstyp gegen Snapshots alle K Aktionen. Ich habe Snapshots plus Wiedereinspielen gewählt, weil die Umkehrung eines Aktionstyps mehrdeutig war, und ausdrücklich gesagt, dass ich damit Speicher gegen Einfachheit tausche. Er wirkte mit der Begründung sichtbar zufriedener als mit dem Code — das ist, glaube ich heute, der eigentliche Zweck dieser Runde. Ich habe außerdem ungefragt drei Testfälle geschrieben, und beim leeren Log kam ein „gut“.

Runde 2: der Deep Dive in frühere Arbeit, 50 Minuten — die Runde, die ich vergeigt habe

Hier bin ich auseinandergefallen. Die Aufforderung war schlicht: „Suchen Sie sich etwas aus, das Sie in den letzten zwei Jahren gebaut haben, und führen Sie mich durch.“ Ich habe die Neuschreibung unserer Vorschaubild-Pipeline gewählt. Gutes Projekt, katastrophale Umsetzung im Gespräch.

Was ich geliefert habe, war eine Führung. Hier der Upload-Endpunkt, hier die Warteschlange, hier die Worker, hier der Cache, hier die Invalidierung, und nebenbei hat das ein paar Millionen Assets verkraftet. Chronologisch. In Form eines Architekturdiagramms. Ein Konferenzvortrag.

Er hat mich immer wieder aus dieser Führung herausgezogen, mit Fragen, die ich schlecht beantwortet habe:

• „Warum synchron beim Upload rendern statt bei der ersten Anfrage?“
• „Was haben Sie aufgegeben, als Sie sich für ein einziges Vorschauformat entschieden haben?“
• „Wer hat sich nach dem Rollout zuerst beschwert, und worüber?“
• „Was haben Sie gemessen, bevor Sie entschieden haben, dass das die richtige Abwägung ist?“

Auf zwei der vier Fragen hatte ich eine belastbare Antwort, und die war nachträglich zusammengebaut. Die ehrliche Wahrheit: Ein Teil dieser Entscheidungen fiel in einem Meeting, in dem ich saß, ohne zu widersprechen, und ich hatte die Begründung nie rekonstruiert. Also habe ich die Lücken glattgebügelt und sehr oft „wir haben entschieden“ gesagt. Als er fragte, was ich heute anders machen würde, kam ich wieder mit Tests, und ich habe schon beim Sprechen gehört, wie dünn das klingt.

Nach vierzig Minuten hörte er auf nachzufragen und begann zu erklären, wie sein Team ein ähnliches Problem löst. Ich habe es richtig gelesen: Er war mit dem Bewerten fertig. Ich habe aufgelegt und wusste es.

Die fünf Tage dazwischen

Ein Wochenende und drei Abende, ohne eine einzige Algorithmusaufgabe. Zwei Dinge.

Erstens habe ich für drei Projekte geschrieben, was ich seitdem Entscheidungsprotokoll nenne. Eine Seite pro Projekt, bewusst starres Format: die Entscheidung, die zwei nicht gewählten Alternativen, der konkrete Grund, der bezahlte Preis, die gemessene Größe und das, was ich heute ändern würde. Drei bis fünf Entscheidungen pro Projekt. Wo ich eine Zeile nicht ehrlich füllen konnte, habe ich nachgesehen: ein altes Konzeptdokument, ein Slack-Thread von vor vierzehn Monaten, zwei Dashboard-Kurven, damit ich Zahlen statt Adjektive habe. Die Vorschaubild-Pipeline hat vier Stunden gebraucht, die Hälfte davon für die Erkenntnis, dass ich eine ihrer Abwägungen nie wirklich verstanden hatte.

Zweitens habe ich vier komplette Übungsloops auf PhantomCodeAI gemacht, ausschließlich zu diesem einen Rundentyp. Die Transkripte haben das Muster peinlich deutlich gemacht: In den ersten Minuten jeder Antwort habe ich Chronologie erzählt — „also zuerst haben wir X gebaut, dann ist uns Y aufgefallen“ — statt mit der Entscheidung und ihrem Preis zu beginnen. Im Schnitt über zwei Minuten, bevor ich etwas gesagt habe, das ein Interviewer bewerten kann. Beim vierten Durchlauf begann ich mit einem Satz der Form: „Die interessante Entscheidung war A gegen B, wir haben A genommen, und es hat uns C gekostet.“

Kleine Änderung. Sie war den ganzen Prozess wert.

Runde 3: Design und Architektur, 60 Minuten

Produktnah, nicht infrastrukturnah. Nicht „entwerfen Sie einen URL-Shortener“, sondern: Entwerfen Sie das Offline-Verhalten und das Synchronisationsmodell für ein Bearbeitungswerkzeug, bei dem Nutzer erwarten, dass ihre Arbeit einen mitten im Satz zugeklappten Laptop überlebt. Zwei Unterschiede zum FAANG-System-Design.

Die Randbedingungen betrafen die Nutzererfahrung, nicht den Durchsatz. Die Nachfragen: „Was sieht der Nutzer, während abgeglichen wird?“, „Was, wenn zwei Geräte widersprechen und eines das Handy des Nutzers ist?“, „Welche Fehlerfälle sind akzeptabel genug, um damit live zu gehen?“ Niemand hat nach Anfragen pro Sekunde gefragt. Als ich ungefragt Kapazitätsabschätzungen anbrachte, hat sie mich neunzig Sekunden reden lassen und dann zur Konfliktsemantik zurückgelenkt.

Zuschnitt wurde ausdrücklich geprüft. Etwa in Minute 40: „Sie haben einen Entwickler und sechs Wochen. Was ist in v1?“ Ich habe echtes Offline-First gestrichen, die Absturzwiederherstellung aus einem lokalen Puffer behalten und v1 auf „letzter Schreiber gewinnt“ mit sichtbarem Konflikthinweis gelegt, weil eine stille falsche Zusammenführung schlimmer ist als eine ehrliche hässliche. Sie hat nachgehakt, ob der Hinweisbanner nicht eine Ausrede sei. Ich habe gesagt: doch, ist er, und für sechs Wochen ist er die richtige Ausrede, und ich möchte Telemetrie darüber, wie oft er auslöst, bevor ich entscheide, ob v2 echtes Zusammenführen braucht.

Das war der Moment, in dem der Prozess gekippt ist. Es war keine Prüfung mehr, sondern zwei Leute, die über eine Produktentscheidung stritten. Ich habe weiter argumentiert, statt ihr zuzustimmen — dazu hätte mir einen Monat früher der Mut gefehlt.

Runde 4: der einstellende Manager, 50 Minuten

Kaum technisch, und mit erheblichem Gewicht. Er hat gefragt, was ich in zwei Jahren tun will, welche Art von Feedback ich schlecht annehme, und was ich tue, wenn eine Designerin und ich uns uneinig sind, ob ein Feature fertig ist. Dann hat er mir eine echte Situation aus seinem Team gegeben — ein Feature, das mit einer bekannten Schwachstelle ausgeliefert wird — und gefragt, was ich streichen, behalten oder verschieben würde.

Ich habe die Gewohnheit aus dem Entscheidungsprotokoll benutzt, ohne es geplant zu haben. Statt einer allgemeinen Haltung habe ich benannt, was ich streiche, warum der Schnitt billig ist, und was ich nach dem Ausliefern messen würde, um zu erkennen, ob ich falsch lag. Er hat einer meiner Entscheidungen widersprochen. Ich habe zwei Punkte gehalten, den dritten aufgegeben und gesagt, warum.

Gegen Ende: „Was machen wir gerade, wogegen Sie argumentieren würden?“ Diese Frage lohnt Vorbereitung. Ich habe ein konkretes Verhalten des Produkts benannt, erklärt, warum es die falsche Voreinstellung ist, und dann gesagt, was ich wissen müsste, um meiner eigenen Meinung dazu zu trauen. Er hat gelacht und gesagt, die Hälfte seines Teams sehe das genauso.

Dann fragte er nach meinen Fragen, und ich hatte sechs aufgeschrieben. Das ist keine Charaktereigenschaft, das ist Vorbereitung, und es ist das billigste Signal, das man kaufen kann.

Das Warten und der Anruf

Elf Tage Stille. An Tag acht habe ich der Recruiterin eine kurze Nachricht geschickt und gefragt, ob ihr etwas fehlt — die maximal zulässige Menge Nachhaken.

Der Anruf kam an einem Freitagnachmittag. Angebot für die Produkt-Engineering-Stelle, im Team, mit dem ich gesprochen hatte, unter dem Manager, mit dem ich gestritten hatte. Das Detail aus dem Debrief, an das ich oft denke: Der Deep Dive ging als schwächstes Signal meines Prozesses ein, und die Design- sowie die Manager-Runde haben es getragen. Hätten diese beiden am selben Donnerstag stattgefunden wie der Deep Dive, würde ich das hier nicht schreiben.

Die Verhandlung, aus deutscher Perspektive

Zahlen veröffentliche ich nicht: Ein einzelner Datenpunkt aus einem einzelnen Prozess ist schlechter als gar keiner. Die Form dessen, was ich gefragt habe, überträgt sich aber, und ein Teil davon ist spezifisch deutsch.

1. Die Bandbreite und meine Position darin. Nicht „geht da noch was“, sondern „wie ist die Spanne für diese Stufe und diesen Standort, wo liegt dieses Angebot darin, und was genau würde es bewegen?“
2. Die Kündigungsfrist, sofort und nicht am Ende. Bei mir drei Monate zum Quartalsende. Ich habe sie im ersten Call genannt, und das Startdatum war anschließend der am leichtesten verhandelbare Punkt.
3. Der Vesting-Plan, nicht nur die Aktiensumme. Aktienpakete sind außerhalb der US-Konzerne in Deutschland selten, deshalb können viele Bewerber sie schlecht einordnen. Ich habe nach Sperrfristen, Auszahlungsrhythmus und Refresh-Praxis gefragt — und danach, was passiert, wenn ich vor der ersten Tranche gehe.
4. Urlaubstage, Homeoffice-Tage und der Zuschnitt des ersten Projekts. Die 30 Urlaubstage, die hier als selbstverständlich gelten, stehen in Verträgen internationaler Arbeitgeber nicht automatisch drin. Den Projektzuschnitt habe ich mir schriftlich geben lassen — nicht als Vertragsbestandteil, sondern als Klarheit. Die Antwort war konkret, was mir gezeigt hat, dass das Team über den Bedarf nachgedacht hatte.

Eine Komponente hat sich bewegt. Die anderen nicht. Normales Ergebnis.

Der Zwei-Wochen-Plan, den ich wieder so machen würde

Mit vierzehn Tagen würde ich sie genau so verteilen. Beachten Sie, wie wenig davon Code ist.

Tag 1 bis 3: Entscheidungsprotokolle. Drei Projekte, je eine Seite, das Format von oben. Wenn eine Zeile leer bleibt, suchen Sie die Antwort in alten Konzeptdokumenten, Tickets und Dashboards. Mindestens eine echte Zahl pro Projekt. Der wirkungsvollste Punkt der Liste, und fast niemand macht ihn.

Tag 4: die Einstiegssätze proben. Sagen Sie für jede der etwa zwölf Entscheidungen den ersten Satz laut, bis er mit der Abwägung beginnt und nicht mit der Zeitachse.

Tag 5 bis 7: praktisches Coding im echten Editor, kein Rätselpauken. Nehmen Sie Aufgaben, an die Sie nach dem Fertigwerden eine zweite und dritte Anforderung anhängen. Schreiben Sie die Tests. Benennen Sie sauber. Wenn Ihre gesamte Vorbereitung auf einer Plattform mit versteckten Testfällen stattfindet, trainieren Sie den falschen Reflex — der Leitfaden für Senior-Stellen und die Full-Stack-Aufschlüsselung gehen auf dieses Erweitern des eigenen Codes genauer ein.

Tag 8 bis 10: produktnahes Design. Nehmen Sie drei Werkzeuge, die Sie benutzen, und entwerfen Sie je eine schwierige Teilfunktion: Rückgängigmachen über eine Netzwerkgrenze hinweg, Offline-Bearbeitung, Versionierung, Rechte auf geteilten Assets. Beantworten Sie „was ist in v1 mit einem Entwickler und sechs Wochen“ und „was sieht der Nutzer, wenn es schiefgeht“. Lassen Sie die Kapazitätsrechnung weg, dort lebt diese Runde nicht. Wenn Sie an der Frontend-Seite solcher Systeme arbeiten, ist der Frontend-Leitfaden die passendere Grundlage.

Tag 11: die Manager-Runde. Schreiben Sie auf: warum dieses Team, was Sie in zwei Jahren wollen, eine Meinungsverschiedenheit, die Sie verloren haben, und was Sie danach getan haben, und eine Sache am Produkt, der Sie widersprechen würden. Dann schreiben Sie Ihre sechs Fragen. Wenn Ihre Verhaltensantworten noch schwammig sind, funktionieren die Archetypen unter Verhaltensfragen als Checkliste.

Tag 12 und 13: zwei vollständige Übungsloops hintereinander. Meine liefen über PhantomCodeAI, weil ich das Transkript dringender brauchte als eine freundliche Einschätzung, und geprüft habe ich genau eine Sache: ob ich unter Druck wieder in die Chronologie rutsche. Machen Sie einen Durchlauf müde, denn in diesem Zustand sind Sie in Runde vier.

Tag 14: nichts. Entscheidungsprotokolle noch einmal lesen.

Was ich mir im März sagen würde

Die drei Monate Algorithmen waren nicht verschwendet: Sie haben die Coding-Runden ruhig gemacht, und Ruhe ist viel wert. Aber die Gewichtung war absurd. Mein Prozess hat Tiefe zu einem System belohnt, das ich tatsächlich gebaut hatte, und die Fähigkeit, eine Produktentscheidung gegen höflichen Widerspruch zu verteidigen. Für beides hatte ich fast keine Zeit aufgewendet.

Wenn Sie seit Monaten nach dem FAANG-Muster üben und bei einem Unternehmen antreten, dessen Geschäft handwerkliche Produktqualität ist, lautet die Korrektur nicht „mehr vorbereiten“. Sie lautet: anders vorbereiten, gezielt auf den Teil Ihrer Erfahrung, den Sie noch nie einem Fremden erklären mussten, der so lange weiter „warum“ fragen darf, wie er will.

Schreiben Sie zuerst das Entscheidungsprotokoll. Das ist die ganze Lektion, und ich musste beinahe ein Angebot verlieren, um sie zu lernen.

Häufige Fragen

Aus wie vielen Runden besteht der Adobe Prozess?

Meiner bestand aus einem 30-minütigen Recruiter-Call, einem einstündigen Technical Screen im geteilten Editor und vier Onsite-Runden, verteilt auf zwei Tage. Das Format hängt von Team und ausgeschriebener Stelle ab, das hier ist also die Erfahrung einer einzelnen Person. Als ich nach dem genauen Ablauf gefragt habe, hat meine Recruiterin mir die Rundennamen und ihren jeweiligen Schwerpunkt ohne Zögern geschickt.

Ist das Coding-Niveau schwerer als LeetCode?

Es ist nicht schwerer, es ist anders. Die Aufgaben in meinem Prozess waren kleine realistische Arbeitsaufträge, an die während der Runde zwei weitere Anforderungen angehängt wurden, keine Rätsel mit einem einzigen cleveren Trick. Ich sollte sauber benennen, fehlerhafte Eingaben behandeln und meinen eigenen Code zweimal erweitern. Genau das bestraft die Gewohnheit, auswendig gelernte Lösungen abzurufen.

Welche Runde hätte mich fast das Angebot gekostet?

Der Deep Dive in ein früheres Projekt. Ich habe eine chronologische Architekturführung geliefert statt die drei bis vier Entscheidungen darin zu verteidigen, und ich konnte nicht erklären, warum ich die Alternativen verworfen hatte. Bei Adobe ist diese Runde ein echtes Bewertungssignal und kein Aufwärmen. Gerettet hat mich nur, dass mein Onsite in zwei Blöcke geteilt war.

Läuft der Prozess auf Deutsch, wenn man sich aus Deutschland bewirbt?

Bei mir war nur der erste Recruiter-Call auf Deutsch. Die fünf technischen Runden liefen komplett auf Englisch, mit Gesprächspartnern aus drei Ländern und keinem einzigen aus Deutschland. Das ist der Normalfall, wenn die Stelle an ein europäisches Engineering-Team angebunden ist. Üben Sie, eine technische Abwägung laut auf Englisch zu erzählen: Das ist eine andere Übung, als sie auf Deutsch zu verstehen.

Was lässt sich aus deutscher Sicht konkret verhandeln?

Ich habe nach der Bandbreite für die Stufe gefragt und danach, was meine Position darin konkret bewegen würde. Ich habe das Startdatum an meiner Kündigungsfrist ausgerichtet, die bei mir drei Monate zum Quartalsende betrug, und ich habe den Vesting-Plan der Aktien erfragt statt nur den Gesamtbetrag. Urlaubstage, Homeoffice-Tage und der Zuschnitt meines ersten Projekts standen ebenfalls auf der Liste, und den letzten Punkt habe ich mir schriftlich geben lassen.

Braucht man eine Empfehlung, um überhaupt zurückgerufen zu werden?

Meine Online-Bewerbung lag sechs Wochen unbeantwortet herum, eine Mitarbeiterempfehlung hat innerhalb von neun Tagen eine Recruiter-Mail ausgelöst. Die Empfehlung überspringt keinen Bewertungsschritt und macht keine Runde leichter, sie sorgt nur dafür, dass ein Mensch die Unterlagen öffnet. Bei rund 30.000 Beschäftigten ist genau das der Unterschied.