Salesforce ist ein Unternehmen mit rund 70.000 Beschäftigten, das Software an die Administratorinnen und Administratoren anderer Unternehmen verkauft, nicht an Endverbraucher. Diese eine Tatsache verändert das Entwicklungsinterview stärker, als die meisten Bewerbenden erwarten. Die Aufgaben haben Enterprise-Zuschnitt, die Design-Runde dreht sich um Mandanten statt um Nutzerzahlen, und das Gespräch über Werte ist eine bewertete Station, kein freundlicher Abschluss.
Der Ablauf, den Bewerbende üblicherweise beschreiben, besteht aus einem Gespräch mit der einstellenden Führungskraft, einer Live-Coding-Runde, einer System-Design-Runde und einer Werte-Runde rund um das hauseigene Vokabular: Ohana für die erweiterte Gemeinschaft des Unternehmens und V2MOM, das interne Planungsrahmenwerk aus Vision, Values, Methods, Obstacles und Measures. Beides ist keine Dekoration.
Das Fehlermuster ist vorhersehbar. Gute Entwicklerinnen und Entwickler erscheinen mit wochenlangem Algorithmentraining, bestehen das Coding souverän und liefern dann in der Führungskraft-Runde und in der Werte-Runde unter Niveau — dort, wo überraschend viel von der Entscheidung liegt. Diese zehn Tipps sind um dieses Ungleichgewicht herum gebaut, und um eine Frage, die man in Deutschland zuerst klären sollte.
1. Klären Sie zuerst, ob die Stelle bei Salesforce oder im Partnerumfeld liegt
Salesforce unterhält in Deutschland unter anderem Standorte in München, Berlin, Frankfurt und Hamburg, und ein erheblicher Teil dieser Rollen liegt in Vertrieb, Solution Engineering und Professional Services. Gleichzeitig stammt ein großer Anteil der Stellenanzeigen, in denen das Wort Salesforce vorkommt, überhaupt nicht von Salesforce, sondern von Beratungen, Systemhäusern und Implementierungspartnern.
Die falsche Variante: drei Wochen verteiltes System Design büffeln für eine Stelle, in der am Ende Apex-Trigger, Governor Limits und ein CRM-Datenmodell abgefragt werden.
Die richtige Variante: Lesen Sie das ausschreibende Unternehmen im Impressum der Anzeige und fragen Sie im Erstgespräch direkt: „Gehört die Stelle zu einem Salesforce-Produktteam, oder handelt es sich um Projektarbeit beim Kunden? Wie ist das Verhältnis zwischen Entwicklung auf der Plattform und Entwicklung der Plattform?" Eine seriöse Antwort dauert einen Satz.
Warum die erste Variante scheitert: Sie optimieren die falsche Zielfunktion. Beide Wege sind legitime Karrieren, aber sie führen zu völlig unterschiedlichen Interviews — und die Produktentwicklungsstellen hängen in Deutschland häufig an internationalen Teams mit Berichtslinie in die USA, was Sie ebenfalls vorher wissen wollen.
2. Behandeln Sie das Gespräch mit der Führungskraft als Fachrunde
In den meisten Unternehmen kommt dieses Gespräch nach der technischen Hürde und dient dem gegenseitigen Abtasten. Bei Salesforce liegt es häufig früh, und die Führungskraft ist in der Regel diejenige Person, die die Stelle verantwortet und die Entscheidung im Debriefing trägt. Wer hier im Plaudermodus erscheint, verbrennt seine wertvollste Stunde.
Die falsche Variante: „Ich bin seit drei Jahren im Team für Zahlungsabwicklung und suche mehr Verantwortung." Das ist ein vorgelesener Lebenslauf. Damit kann niemand für Sie argumentieren.
Die richtige Variante: Bringen Sie zwei Projekte mit, bei denen Sie drei Ebenen tief gehen können, und steigen Sie über die Architektur ein statt über das Organigramm. „Ich verantworte die Idempotenzschicht unserer Zahlungs-Ingestion. Sie verarbeitet etwa 40.000 Webhooks pro Stunde, und der interessante Fehlerfall war eine doppelte Verbuchung, als der Anbieter während einer Netzpartition erneut zugestellt hat." Danach lassen Sie sich unterbrechen — das passiert.
Rechnen Sie außerdem damit, dass diese Runde auf Englisch stattfindet, sobald jemand außerhalb Deutschlands beteiligt ist. Ich habe vor meinem eigenen Gespräch zwei Übungsläufe dieser Runde auf PhantomCodeAI gemacht, ausschließlich um mir anzugewöhnen, mit dem System statt mit meiner Jobbezeichnung zu beginnen.
3. Hängen Sie an jede Projektgeschichte eine Messgröße
V2MOM ist das interne Planungsrahmenwerk: Vision, Values, Methods, Obstacles, Measures. Teams schreiben es, rollen es auf und streiten damit über Prioritäten. Nach dem Akronym wird niemand fragen, und wer es im Gespräch platziert, klingt nach gestern Abend gelesenem Blogartikel.
Nützlich ist trotzdem, was das Rahmenwerk über eine vollständige Geschichte verrät. Die meisten Erzählungen von Bewerbenden sind schwer an Methoden und leer an Messgrößen.
Die falsche Variante: „Wir haben den Reporting-Dienst auf eine neue Query-Engine migriert, jetzt ist er deutlich schneller."
Die richtige Variante: „Das Ziel war, dass der Kundenservice Kontofragen ohne Eskalation an die Entwicklung beantworten kann. Wir haben das Reporting auf einen spaltenorientierten Speicher umgestellt. Das Hindernis war, dass ein Drittel der Abfragen berechtigungsgefiltert ist, wir also nicht naiv vorberechnen konnten. Die Messgröße waren Eskalationen je tausend Tickets: von 18 auf 4 in zwei Quartalen."
Warum die erste Variante scheitert: „deutlich schneller" ist nicht überprüfbar, und die interne Planungskultur ist ausdrücklich messgrößenorientiert. Wer die bewegte Zahl nicht nennen kann, wirkt wie jemand, dem Tickets zugeteilt werden.
4. Veröffentlichen Sie im Live Coding erst den Vertrag, dann den Algorithmus — und schreiben Sie die Tests ungefragt
Salesforce baut Plattformsoftware, auf der andere aufsetzen. Eine Schnittstelle ist dort ein Versprechen, und sie zu brechen zerstört den Individualcode von Kunden. Entsprechend wird die Coding-Runde gelesen: Wie Sie die Grenze definieren, zählt so viel wie das, was Sie hineinschreiben.
Die falsche Variante: Aufgabe hören, „ich nehme eine Hashmap" sagen, tippen. Zehn Minuten später fragt jemand nach einem Nullwert, und die ganze Struktur muss umziehen.
Die richtige Variante: Verbringen Sie drei bis vier Minuten damit, Signatur und Randfälle als Kommentare zu schreiben. „Die Funktion nimmt eine Liste von Datensätzen und ein Konfigurationsobjekt und liefert ein Ergebnis plus eine Liste von Fehlern pro Datensatz zurück, statt eine Exception zu werfen — die Aufrufer sind Batch-Jobs, die wegen einer schlechten Zeile nicht abbrechen dürfen. Undefiniert: doppelte IDs, leere Eingabe, fehlender Sortierschlüssel." Dann codieren. Und zum Schluss von sich aus drei Testfälle formulieren.
Warum die erste Variante scheitert: Sie liefert eine isoliert korrekte Lösung, die als Plattformbaustein unbrauchbar ist. Auf einer Plattform, die für Deployments in Produktivumgebungen eine Mindestabdeckung an Apex-Tests erzwingt — historisch 75 Prozent — wirkt „Tests kann ich noch ergänzen, wenn Sie möchten" wie ein kleiner, gut lesbarer Kulturbruch.
5. Bringen Sie die Mandantentrennung in den ersten fünf Minuten aufs Whiteboard
Das ist der größte Unterschied zu den Consumer-Design-Runden, die die meisten Bewerbenden trainieren. Sie entwerfen nicht für eine Million Nutzer eines Produkts, sondern für tausende getrennte Kundenorganisationen auf gemeinsamer Infrastruktur, von denen jede überzeugt ist, dass ihre Daten privat und ihre Performance ihr eigen sind.
Die falsche Variante: Load Balancer, App-Schicht, Datenbank zeichnen, nach Nutzer-ID shardieren und mit der Cache-Strategie weitermachen. Dieser Entwurf ist still kaputt: Ein einziger Kunde mit nächtlichem Massenimport hungert alle anderen aus.
Die richtige Variante: „Bevor ich skaliere, ziehe ich die Mandantengrenze. Die Daten sind nach Organisations-ID partitioniert, jede Abfrage trägt sie, und das wird in der Datenzugriffsschicht erzwungen, nicht per Konvention. Zusätzlich will ich Quoten pro Mandant auf der Queue für asynchrone Jobs, denn der laute Nachbar ist hier der Massenimport eines Großkunden, der alle Worker belegt." Danach entwerfen Sie den Quotenmechanismus — das ist der interessante Teil.
Warum die erste Variante scheitert: Sie beantwortet eine Kapazitätsfrage, obwohl nach Isolation gefragt wurde. Unsere Sammlung von System-Design-Fragen eignet sich gut, um diese Form zu üben.
6. Behandeln Sie DSGVO und Datenresidenz als Entwurfsproblem, nicht als Häkchen
Deutsche Großkunden fragen nicht nur, wo ihre Daten liegen, sondern wer darauf zugreifen darf, unter welchem Auftragsverarbeitungsvertrag, und wie eine Löschung nachgewiesen wird. Wer das als juristische Randnotiz behandelt, übersieht eine Randbedingung, die den Entwurf tatsächlich formt.
Die falsche Variante: „Wir verschlüsseln at rest und in transit und sind DSGVO-konform." Das ist ein Satz aus einer Broschüre.
Die richtige Variante: Machen Sie daraus Architektur. „Der harte Fall ist das Löschen, weil mein Event-Log append-only ist und zugleich die Abrechnung speist. Ich würde direkte Personenbezüge in einen Schlüsselspeicher pro Mandant auslagern und im Log nur Pseudonyme führen: Wird der Schlüssel gelöscht, sind die Events unwiderruflich anonym, ohne dass ich Historie umschreibe. Der Preis ist ein zusätzlicher Join auf dem Lesepfad und eine weitere Ausfallquelle, die ich mit einem kurzlebigen lokalen Cache abfedere."
Warum die erste Variante scheitert: Sie zeigt Vokabular ohne bezahlten Preis. Die Argumentation über löschbare Schlüssel, regionale Verarbeitung und den Umfang der Unterauftragsverarbeitung ist genau das, womit Enterprise-SaaS-Teams in Europa jedes Quartal umgehen.
7. Entwerfen Sie für den Administrator, nicht nur für die Endnutzerin
Salesforce-Produkte werden umfassend von Administratorinnen auf Kundenseite konfiguriert: neue Felder, geänderte Validierungsregeln, Automatisierungen ohne Beteiligung der Entwicklung. Ein Entwurf, der ein festes Schema annimmt, ist für das gesamte Geschäftsmodell still falsch.
Die falsche Variante: ein normalisiertes relationales Schema mit fester Spaltenliste für die Kernentität vorschlagen und „der Kunde will ein neues Feld" mit einer Migration beantworten.
Die richtige Variante: Sprechen Sie Erweiterbarkeit aktiv an. „Kunden werden Felder an diesem Objekt ergänzen, also trenne ich plattformeigene Spalten von einer kundendefinierten Metadatenschicht, in der Felddefinitionen als Daten liegen und selektiv indexiert werden, statt physische Spalten pro Mandant anzulegen. Der Preis ist schlechtere Query-Planung und mühsameres Ad-hoc-Reporting, das ich mit materialisierten Sichten pro Mandant für die tatsächlich gefilterten Felder abfange."
Warum die erste Variante scheitert: Sie erzwingt ein Entwicklungs-Release für jede Konfigurationsänderung beim Kunden — also genau die Kopplung, die Enterprise-SaaS abschaffen soll. Sie müssen die interne Architektur von Salesforce nicht nachbauen; Sie müssen zeigen, dass Ihnen aufgefallen ist, dass das Schema Ihnen nicht gehört, und die Kosten Ihrer Flexibilität benennen.
8. Entwerfen Sie den Ausfall und die Kundenkommunikation, nicht nur den Happy Path
Salesforce veröffentlicht Systemstatus öffentlich, und Kunden bauen ihre Betriebsprozesse darauf auf. Verfügbarkeit ist eine kommerzielle Zusage, nicht nur ein SLO auf einem internen Dashboard. Antworten, die bei „dann machen wir einen Retry" enden, verfehlen, was diese Runde prüft.
Die falsche Variante: „Wenn die Integration ausfällt, wiederholen wir mit exponentiellem Backoff." Punkt.
Die richtige Variante: eine Ebene weiter, in Degradation und Transparenz. „Fällt die Synchronisation zum ERP aus, laufen Schreibvorgänge in eine Queue mit Obergrenze pro Mandant, Lesevorgänge liefern den letzten bekannten Stand mit sichtbarem Aktualitätszeitstempel in der Oberfläche — ein still veralteter Datensatz ist für einen Enterprise-Kunden schlimmer als ein sichtbar veralteter. Ab einer Schwelle melden wir es auf der Statusseite, statt es jede Administratorin einzeln entdecken zu lassen. Die Wiederholungen sind gejittert, damit die Erholung die Abhängigkeit nicht überrennt."
Warum die erste Variante scheitert: Retries nennt jede Person. Der unterscheidende Reflex in Unternehmenssoftware ist, dass ein Ausfall ein Publikum aus zahlenden Administratoren hat, die ihren eigenen Fachbereichen etwas erklären müssen.
9. Beantworten Sie Wertefragen mit einem Vorfall, der Sie etwas gekostet hat
Die Werte-Runde wird bewertet, und ausgerechnet vorbereitete Bewerbende klingen hier am schlechtesten. In Deutschland scheitert sie auf zwei entgegengesetzte Weisen: entweder durch nachgesprochenes Kulturvokabular oder durch eine höflich durchscheinende Distanz, die sofort auffällt.
Die falsche Variante: „Der Ohana-Gedanke spricht mich sehr an, weil ich an eine familiäre Kultur glaube, in der man sich gegenseitig unterstützt und der Kunde an erster Stelle steht." Das ist eine Umschreibung einer öffentlichen Seite und enthält keine Information über Sie.
Die richtige Variante: ein Vorfall, ein Zielkonflikt, ein benannter Preis. „Ein Kunde hing auf einem abgekündigten Exportformat fest. Die saubere technische Antwort wäre gewesen, ihn migrieren zu lassen. Ich habe drei Wochen in eine Zwischenschicht gesteckt, von der wir wussten, dass wir sie wieder löschen — dadurch verrutschte ein Feature, das ich verantwortet habe, um einen Sprint. Ich würde es wieder tun, aber in einem Punkt lag ich falsch: Ich habe meine Führungskraft erst informiert, als die Verzögerung schon eingetreten war."
Warum die erste Variante scheitert: Geprüft wird nicht, ob Sie ein Prinzip erkennen, sondern ob Sie schon einmal dafür bezahlt haben. Den eigenen Fehler zu benennen macht die Geschichte glaubwürdig. Zur allgemeinen Mechanik solcher Runden hilft unsere Sammlung von Fragen zum Verhalten im Team; das Salesforce-Spezifische ist der offengelegte Preis.
10. Stellen Sie Fragen, die zeigen, dass Salesforce kein einzelnes Unternehmen ist — und fassen Sie fachlich nach
Salesforce ist erheblich durch Zukäufe gewachsen, und die Entwicklungsrealität unterscheidet sich zwischen Produktgruppen: Sprache, Release-Kadenz, tatsächliche Abhängigkeit von der darunterliegenden Plattform. Allgemeine Fragen verschenken den einzigen Moment, in dem Sie Ihr Gegenüber ausfragen dürfen.
Die falsche Variante: „Wie sieht ein typischer Tag aus?" und „Was gefällt Ihnen hier?" Die Antworten sind vorhersehbar und signalisieren, dass Sie dieses Team von keinem anderen unterschieden haben.
Die richtige Variante, an die Führungskraft gerichtet: „Liefert Ihr Team auf dem Release-Train der Plattform oder unabhängig davon?" „Welcher Teil Ihres Stacks ist mit dem Kern geteilt?" „Wenn eine Kundenorganisation wegen einer Komponente aus Ihrem Verantwortungsbereich an ein Limit läuft, wer sitzt dann in der Runde?" „Wann liegen Ihre Teamtermine angesichts der Zeitverschiebung in die USA?" Die letzte Frage ist nicht nebensächlich: Bei einer deutschen Stelle in einem US-geführten Team entscheidet sie über Ihre Abende.
Fassen Sie danach innerhalb eines Tages bei der Führungskraft nach, nicht nur beim Recruiting, und zwar mit Inhalt: „Kurz zur Quotenfrage. Ich hatte eine Obergrenze paralleler Jobs pro Organisation vorgeschlagen; das bessere Primitiv ist vermutlich eine gewichtete faire Queue je Organisation, dann wird ein Großkunde langsamer statt blockiert." Drei Sätze, eine Idee, keine Bitte. Ein allgemeines Dankesschreiben verändert keine Entscheidung; ein fachlicher Nachtrag liefert eine Zeile fürs Debriefing.
Was Sie mit der verbleibenden Woche tun
Wenn die Zeit knapp ist, passt hier nicht die Aufteilung eines FAANG-Loops. Coding muss sitzen, beendet aber selten einen Salesforce-Prozess. Investieren Sie überproportional in die Erzählung für die Führungskraft, erzählt mit echten Messgrößen, und in einen mandantenfähigen Entwurf, den Sie von einem leeren Blatt aus aufbauen können: Quoten, konfigurierbare Schemaschicht, Degradationsverhalten und die DSGVO-Argumentation zum Löschen.
Danach sprechen Sie die Werte-Antwort laut und auf Englisch durch; sie klingt beim ersten Versuch schlecht und beim dritten richtig. Planen Sie vier bis acht Wochen Prozess ein und nennen Sie Ihre Kündigungsfrist im Erstgespräch statt am Ende.
In der Woche vor meinem eigenen Loop habe ich die Führungskraft-Runde und die Werte-Runde zweimal hintereinander auf PhantomCodeAI durchgespielt, weil das die beiden Runden waren, die ich mit Bekannten nicht üben konnte, ohne mich albern zu fühlen. Das Muster in den Transkripten war jedes Mal dasselbe: Architektur erklärte ich präzise, Ergebnisse erklärte ich vage — genau die Lücke, die ein messgrößenorientiertes Unternehmen bemerkt.