Wie ich das NVIDIA Software-Engineer-Interview bestanden habe – ganz ohne CUDA-Erfahrung

TL;DR

• Ich habe mich ohne eine einzige Zeile CUDA im Lebenslauf auf eine systemnahe Software-Engineer-Stelle bei NVIDIA beworben und nach rund sieben Wochen die Zusage bekommen.
• Was NVIDIA von einer generischen FAANG-Loop unterscheidet, ist Hardware-Software-Co-Design: Eine saubere O(n)-Lösung ist der Anfang der Frage, nicht ihr Ende, denn die Rückfrage zielt immer darauf, wie sich der Code auf echtem Speicher und echter paralleler Hardware verhält.
• In der GPU-Runde wäre ich fast durchgefallen, weil ich einen Kernel beschrieben habe statt das Speicherzugriffsmuster – gerettet haben mich Coalescing, Occupancy und arithmetische Intensität.
• Wer aus Backend- oder Anwendungsentwicklung kommt, investiert die Vorbereitung besser in C/C++-Speichersemantik und GPU-Architekturgrundlagen als in weitere LeetCode-Aufgaben.

Einleitung

Ich hatte nicht vor, mich bei NVIDIA zu bewerben. Sechs Jahre Backend lagen hinter mir – überwiegend Go, etwas Java, viel Kafka und gelegentlich eine C++-Datei, die ich vorsichtig anfasste und schnell wieder verließ. GPUs waren das, worüber sich das Inference-Team im Slack beschwerte. Dann lief im März eine Ausschreibung an mir vorbei, so eine mit „performancekritisches C++“ und „Erfahrung mit paralleler Programmierung von Vorteil“, und ich habe mich an einem Dienstagabend beworben – mit einem Lebenslauf, in dem das Wort CUDA kein einziges Mal vorkam.

Sieben Wochen später hatte ich ein Angebot. Das hier ist die ehrliche Version dessen, was dazwischen passiert ist, inklusive der Runde, in der ich elf Sekunden lang geschwiegen habe, weil ich schlicht keine Antwort auf eine Frage hatte, die ich hätte kommen sehen müssen.

Warum überhaupt – und was das aus Deutschland heraus bedeutet

Zwei Gründe, ein vorzeigbarer und ein weniger vorzeigbarer.

Der vorzeigbare: Ich hatte zwei Jahre lang zugesehen, wie meine eigenen Services an Dingen hingen, die ich nicht erklären konnte. Ein Model-Server bei 30 Prozent Auslastung, ohne dass jemand sagen konnte, warum. Ein Batch-Job, bei dem doppelte Maschinengröße 15 Prozent Durchsatz brachte. Ich konnte einen Go-Service profilen und ein Flame Graph lesen, aber sobald das Problem unter die Runtime rutschte, habe ich geraten. Ich wollte irgendwohin, wo mich das Raten nicht mehr durchkommen lässt.

Der weniger vorzeigbare: NVIDIA hat inzwischen rund 36.000 Engineers, und alle, die ich kenne, wollten dort rein. Das ist kein guter Grund. Er hat mich aber durch sechs Wochen Stoff getragen, den ich anfangs nicht mochte, also tue ich nicht so, als hätte er keine Rolle gespielt.

Der deutsche Kontext lautet: Menge. Wirklich hardwarenahe Stellen sind hierzulande selten, und sie verteilen sich sehr ungleich. Der süddeutsche Raum um München ist historisch der Schwerpunkt für Halbleiter, Automotive-Compute und systemnahe Entwicklung; Berlin ist stärker Produkt, Daten und Forschung; Hamburg ist für diese Art Rolle dünn besetzt. Verlassen Sie sich für die konkrete Lage nicht auf einen Blogartikel, sondern filtern Sie die Karriereseite nach Land und akzeptieren Sie, dass Sie eventuell auf eine europaweit ausgeschriebene oder remote-fähige Stelle zielen.

Wie ich überhaupt zum Interview kam

Keine Empfehlung, kein Kontakt. Ich habe mich kalt über die Karriereseite beworben und elf Tage lang nichts gehört. Dann habe ich die eine Sache getan, die vermutlich den Unterschied gemacht hat: Ich habe das obere Drittel meines Lebenslaufs so umgeschrieben, dass die Performance-Arbeit die Überschrift war und nicht ein Stichpunkt unter „Microservices“.

Vorher: „Aufbau und Betrieb von Event-Pipelines mit hohem Durchsatz.“

Nachher: „p99-Latenz eines Ingest-Pfads mit 40.000 Events/s von 180 ms auf 34 ms gesenkt – durch Umbau der Batch-Puffer und Eliminierung der Allokation pro Nachricht.“

Gleiche Stelle, gleiche Arbeit. Aber die zweite Version erzählt eine hardwarebewusste Geschichte. Die Recruiterin sagte mir später, hängengeblieben sei die Formulierung „Eliminierung der Allokation pro Nachricht“. Der Recruiter-Call kam eine Woche nach der Aktualisierung.

Zwei Dinge speziell für den deutschen Markt. Erstens: Schreiben Sie den Lebenslauf auf Englisch und lassen Sie Foto, Geburtsdatum und Familienstand weg. Ein klassisch deutsch aufgebauter Lebenslauf mit Foto wirkt in einem international besetzten Screening eher irritierend als korrekt. Zweitens: Arbeitszeugnisse spielen in diesem Prozess praktisch keine Rolle. Niemand hat danach gefragt. Was gefragt wurde, war, was ich gemessen und um wie viel ich es verbessert habe.

Runde 1 – der Recruiter-Call (30 Minuten)

Nichts Exotisches. Die Recruiterin ging den Werdegang durch, fragte, woran ich arbeiten will, wo ich sitze – und dann, womit ich nicht gerechnet hatte: wie sicher ich mich in C++ auf einer Skala von eins bis zehn fühle.

Ich sagte sechs. Das war ehrlich, und ich glaube, es hat geholfen. Sie antwortete, das Team suche Leute, die auf acht kommen können, nicht Leute, die schon zehn sind, und die Loop werde tief in systemnahes Speicherdenken gehen. Dieser eine Satz war die nützlichste Information des gesamten Prozesses, weil er mir genau gesagt hat, was ich einen Monat lang lernen musste.

Zwei sehr deutsche Punkte kamen im selben Gespräch. Die Gehaltsvorstellung wurde direkt im ersten Call abgefragt – das ist hier Standard, also legen Sie sich eine Spanne in Brutto-Jahresgehalt und einen Satz zur Begründung zurecht statt einer verlegenen Pause. Und die Kündigungsfrist: Ich habe drei Monate zum Quartalsende genannt und gleich dazugesagt, dass ich eine frühere Freigabe versuchen würde. Wer das früh sagt, erspart sich das unangenehme Gespräch sechs Wochen später, wenn ein Team längst ein Startdatum im Kopf hat.

Sie skizzierte außerdem die Form der Loop: ein technisches Screening, danach ein virtuelles Onsite. Auf eine Rundenzahl wollte sie sich vor Bestätigung durch das Team nicht festlegen, was sich als ehrlich herausstellte: Meine Loop hatte am Ende fünf Runden in etwa fünf Stunden, und ich habe seither von Loops mit vier und von Loops mit sechs Runden gehört.

Runde 2 – das technische Screening und die Frage hinter der Frage

Sechzig Minuten, geteilter Editor, ein Interviewer, der in den ersten vier Minuten erkennbar in einem anderen Fenster Code geschrieben hat. Komplett auf Englisch.

Die Aufgabe war eine Stream-Frage – der Archetyp lautet: „Halte über einem sehr großen Datenstrom effizient ein gleitendes Aggregat.“ Ich tat, wozu mich sechs Jahre Interviewkonditionierung erzogen hatten. Randbedingungen klären. Die naive Variante in O(n·k) durchsprechen. Die O(n)-Version in einem Durchlauf mit Hilfsstruktur finden. Sauber schreiben. Randfälle abgehen. Ich war vierzehn Minuten vor Schluss fertig und fühlte mich gut.

Dann sagte er: „Okay. Angenommen, das Array hat hundert Millionen Elemente und Sie haben tausend Kerne. Wie parallelisieren Sie das?“

Ich erstarrte kurz, weil ich das Problem mental als erledigt abgelegt hatte. Ich fing mich mit etwas Vernünftigem – in Blöcke teilen, Teilergebnisse berechnen, kombinieren – und er bohrte weiter. Was kostet der Kombinationsschritt? Ist die Operation assoziativ? Was passiert bei einem gleitenden Fenster an den Blockgrenzen? Welcher Anteil der Laufzeit ist am Ende tatsächlich das Kombinieren?

In diesem Moment habe ich die Loop verstanden. In den meisten Firmen heißt „mach das schneller“: finde einen besseren Algorithmus. Hier war die O(n)-Antwort die Eintrittskarte. Das Interview begann danach. Alles Weitere drehte sich darum, wie sich die Arbeit auf Hardware abbildet, die viele Dinge gleichzeitig tut.

Ich bin durchgekommen, nach eigener Einschätzung knapp. Ich habe um Feedback gebeten und über die Recruiterin einen Satz zurückbekommen: starke algorithmische Grundlagen, wünscht sich mehr Souveränität bei paralleler Zerlegung. Höflich formuliert für: Ihnen fehlt eine Dimension.

Die vier Wochen dazwischen

Sechsundzwanzig Tage bis zum Onsite. Das habe ich tatsächlich gemacht, grob nach Ertrag sortiert.

Speicherhierarchie zuerst, GPU danach. Die erste Woche ging vollständig für CPU-Cache-Verhalten drauf: Cache Lines, räumliche und zeitliche Lokalität, warum das Durchlaufen eines 2D-Arrays zeilenweise dramatisch schneller ist als spaltenweise, False Sharing zwischen Threads. Das war die ertragreichste Woche der gesamten Vorbereitung, weil jedes GPU-Konzept danach nur eine Variation von „Wo liegen die Daten und wie weit müssen sie reisen?“ war.

C++-Semantik, bewusst und gezielt. Rohzeiger gegen Referenzen. Was ein dangling pointer auf Speicherebene wirklich ist. Objektlebensdauer und RAII. Move-Semantik und wann still und leise doch kopiert wird. std::unique_ptr gegen shared_ptr und die Kosten des atomaren Referenzzählers. Undefiniertes Verhalten, das ich benennen kann. Ich habe das gelernt, indem ich kleine Programme geschrieben und absichtlich kaputt gemacht habe – langsamer als Lesen und ungefähr viermal haltbarer.

GPU-Architekturgrundlagen. Warps und warum eine innerhalb eines Warps divergierende Verzweigung teuer ist. Occupancy und warum mehr Threads nicht automatisch besser sind. Global Memory gegen Shared Memory. Memory Coalescing – das mit Abstand wichtigste Konzept des ganzen Blocks. Host-Device-Transfers als erstklassige Kostenposition und nicht als Fußnote. Arithmetische Intensität und die Angewohnheit, vor jeder Optimierung zu fragen, ob ein Kernel rechen- oder bandbreitenlimitiert ist.

Übungsinterviews – und was sie konkret repariert haben. Ich habe in zwei Wochen vier Mock-Interviews auf PhantomCodeAI gemacht, und jedes Mal kam dasselbe Muster zurück: Ich löste die algorithmische Hälfte gut und wurde dann still, sobald die Rückfrage auf Hardware umschwenkte. Nicht falsch – still. Ich habe stumm nachgedacht und erst gesprochen, wenn ich ein Ergebnis hatte, und das liest sich in einem Interview als „weiß es nicht“. Das in drei aufeinanderfolgenden Transkripten zu sehen war überzeugender als jeder gut gemeinte Ratschlag.

Was ich nicht gemacht habe: mehr LeetCode. Rund zehn Aufgaben in vier Wochen, nur um warm zu bleiben. Wer aus einem normalen Big-Tech-Vorbereitungszyklus kommt, hat algorithmisch meist genug und einen Engpass woanders. Zum Warmhalten reicht eine strukturierte Fragensammlung wie unser Fragenbereich vollkommen aus.

Das Onsite – fünf Runden, etwa fünf Stunden

Fünf virtuelle Runden hintereinander, zwei kurze Pausen. Reihenfolge und Zusammensetzung variieren nach Team – lesen Sie das als meine Loop, nicht als die Loop.

Runde 1 – Algorithmen, gehobener Schwierigkeitsgrad. Ein Graph-/Traversierungsproblem mit einer unangenehmen Speicherrestriktion. In der Form Standard. Der Dreh kam wieder in der zweiten Hälfte: Da der Graph nicht in den Cache passt – wie würden Sie ihn im Speicher anordnen, um Misses zu reduzieren? Wir haben fünfzehn Minuten über Adjazenzlisten gegen ein flaches CSR-artiges Layout gesprochen. Einen Monat früher hätte ich dazu nichts sagen können.

Runde 2 – C++ und Speicher. Die direkteste Runde der Loop und merkwürdigerweise die, die mir am meisten Spaß gemacht hat. Archetypen: Hier ist eine kleine Klasse, nennen Sie jede Stelle, an der sie leaken oder doppelt freigeben kann. Was ergibt diese Zeigerarithmetik und warum. Was unterscheidet Übergabe by value, by reference und by pointer im erzeugten Verhalten. Wo lebt dieses Objekt und wann stirbt es. Wann würden Sie bewusst einen Rohzeiger wählen. Nirgendwo ein Trick – eine geradlinige Kompetenzprüfung, und vollständig lernbar.

Runde 3 – die, die es fast beendet hätte. GPU und Parallelität. Die Aufgabe war eine massive Datentransformation, und die Frage lautete, wie ich sie auf eine GPU bringen und schnell machen würde.

Ich begann, einen Kernel zu beschreiben. Thread-Indizierung, Block-Dimensionen, die Mechanik. Der Interviewer ließ mich etwa neunzig Sekunden reden und sagte dann freundlich: „Sie erzählen mir, wie man es schreibt. Ich möchte wissen, wie sich der Speicher verhält.“

Danach habe ich geschwiegen – laut meiner Aufzeichnung elf Sekunden lang.

Gerettet hat mich eines der Konzepte, die ich eingeschliffen hatte: Coalescing. Ich habe von den Daten aus neu angesetzt. Ich sagte langsam und laut, die eigentliche Frage sei, ob benachbarte Threads benachbarte Adressen lesen – wenn ja, kann die Hardware die Ladeoperationen eines Warps in wenigen Transaktionen bedienen, wenn nein, wird aus derselben logischen Arbeit ein Vielfaches an Speicherverkehr. Dann sagte ich, das Zugriffsmuster der naiven Variante sei gestridet, ich würde also das Datenlayout umbauen – von Array of Structs zu Struct of Arrays – bevor ich den Kernel überhaupt anfasse. Und dann fragte ich, ob die Last bandbreitenlimitiert sei, denn wenn ja, hilft kein Kernel-Tuning, solange die Transfers nicht geklärt sind.

Er entspannte sich sichtbar. Den Rest der Runde verbrachten wir mit Shared-Memory-Tiling und der Frage, ob der Host-Device-Kopiervorgang bei einem einzigen Durchlauf über die Daten den gesamten Gewinn auffrisst – die Antwort ist ja, und genau deshalb hält man die Daten entweder resident oder lässt es ganz.

Ich glaube nach wie vor, dass ich in dieser Runde Punkte verloren habe. Ich glaube ebenso, dass der laut ausgesprochene Neustart auf einer anderen Abstraktionsebene sie gerettet hat. Interviewer beobachten, wie Sie sich fangen, und „lassen Sie mich das von der Speicherseite her angehen“ ist eine deutlich bessere Erholung, als weiter über Thread-Indizes zu reden.

Runde 4 – Design. Kein klassisches Web-System-Design. Näher an Pipeline-Architektur: wie Daten durch ein heterogenes System fließen, wo gepuffert und wo gebatcht wird, wie man einen Beschleuniger beschäftigt hält statt ihn leerlaufen zu lassen, wo die Durchsatzgrenze liegt und welche Komponente sie setzt. Wenn Ihre Designvorbereitung aus Load Balancern und Sharding besteht, erweitern Sie sie: Die Grundlagen gelten weiter, aber der Druck liegt auf Datenbewegung statt auf Service-Topologie.

Runde 5 – Hiring Manager. Verhaltensfragen, weicher als erwartet, mit einer scharfen Frage: Erzählen Sie mir von einem Performance-Problem, das Sie nicht gelöst haben. Ich habe die Wahrheit über den Model-Server bei 30 Prozent Auslastung erzählt, dessen Ursache ich nie gefunden habe – inklusive des Teils, in dem ich Netzwerk vermutet hatte und falsch lag. Das interessierte ihn erkennbar mehr als jede Erfolgsgeschichte. Ein kultureller Hinweis: Deutsche Sachlichkeit hilft hier, deutsche Untertreibung nicht. Nennen Sie die Diagnose und Ihren Anteil daran präzise, aber verkleinern Sie den Beitrag nicht bis zur Unsichtbarkeit.

Debrief, Angebot und Verhandlung

Neun Tage Funkstille, in denen ich überzeugt war, Runde 3 hätte mich versenkt. Dann ein Anruf: insgesamt positive Loop, eine Runde als gemischt markiert. Die Recruiterin sagte nicht, welche. Ich weiß, welche.

Das Angebotsgespräch war unspektakulär im besten Sinne. Ich habe verhandelt – höflich gefragt, ob Spielraum bestehe, und mehr über Level und Teamzuschnitt gesprochen als über die Schlagzeilenzahl, weil ich kein Konkurrenzangebot und damit keinen Hebel hatte, den ich hätte vortäuschen können. Manches bewegte sich, anderes nicht. Niemand fand das Fragen unangemessen.

Zahlen veröffentliche ich nicht, aber drei deutsche Orientierungspunkte gehören hierher. Europäische Pakete liegen für dieselbe Rolle deutlich unter US-Niveau – rechnen Sie niemals einen im amerikanischen Forum gesehenen Betrag um. Aktienpakete mit regelmäßigem Vesting sind außerhalb von US-Töchtern hierzulande selten; wenn Sie welche bekommen, ist die entscheidende Frage nicht nur der Einstiegsbetrag, sondern der Rhythmus der Refreshes. Und schauen Sie auf die Gesamtstruktur statt nur auf das Fixum: 13. Monatsgehalt oder Bonusmodell, Urlaubstage, betriebliche Altersvorsorge, Probezeit von in der Regel sechs Monaten, Kündigungsfrist. Bei einem unbefristeten deutschen Vertrag sind diese Zeilen oft mehr wert als ein paar Prozent Verhandlungsgewinn beim Grundgehalt.

Was ich wieder lernen würde – in dieser Reihenfolge

Müsste ich die vier Wochen wiederholen, würde ich sie fast identisch verbringen, mit einer Änderung: Ich würde die Übungsinterviews in Woche eins statt in Woche drei beginnen, weil sie mir gesagt haben, was mit meiner Darstellung nicht stimmte, solange ich es noch reparieren konnte.

1. Speicherhierarchie und Cache-Verhalten. Cache Lines, Lokalität, False Sharing, warum die Schleifenreihenfolge die Laufzeit um eine Größenordnung verändert. Alles Weitere baut darauf auf.
2. Memory Coalescing. Wenn Sie nur ein GPU-spezifisches Konzept lernen, dann dieses. „Greifen benachbarte Threads auf benachbarte Adressen zu?“ beantwortet einen überraschend großen Teil der NVIDIA-typischen Rückfragen.
3. Zeiger und Lebensdauern in C/C++. Dangling Pointer, Ownership, RAII, Move gegen Copy, die realen Kosten eines shared_ptr. Rechnen Sie mit direkten Fragen, nicht mit beiläufigen.
4. GPU-Ausführungsmodell. Warps, Divergenz, Occupancy, Shared Memory, Transferkosten zwischen Host und Device. Sie brauchen genug, um zu argumentieren, nicht genug, um auszuliefern.
5. Rechenlimitiert gegen bandbreitenlimitiert. Üben Sie zu sagen, welches von beiden eine Last ist und warum – bevor Sie irgendeine Optimierung vorschlagen. Das ist der Satz, nach dem Sie klingen wie jemand, der dazugehört.
6. „Mach das schneller“ richtig beantworten. In den meisten Firmen heißt das: bessere Datenstruktur. Hier meint es meistens die Maschine. Wenn Sie den Satz hören, fragen Sie sich: Will er einen anderen Algorithmus oder ein anderes Zugriffsmuster? Wenn Sie es nicht wissen, fragen Sie nach. „Soll ich den Algorithmus angreifen oder das Zugriffsmuster?“ ist eine völlig legitime Klärungsfrage und kommt gut an.

Die Gewohnheit, die am meisten gebracht hat, war das laute Erzählen der Hardware-Argumentation statt des stillen Nachdenkens. Gemerkt habe ich das nur, weil ich vor dem Onsite ein paar Übungsloops auf PhantomCodeAI aufgezeichnet und angesehen habe – und mir dabei dreimal hintereinander an exakt derselben Stelle beim Verstummen zugesehen habe.

Der Teil, an den ich immer noch denke

Ich war nicht der algorithmisch stärkste Kandidat dieser Loop. Da bin ich mir ziemlich sicher. Was ich hatte, waren vier Wochen bewusster Arbeit an einer einzigen Achse – wie sich Code auf echter Hardware verhält – und die Bereitschaft zu sagen: „Weiß ich nicht, lassen Sie mich das von der Speicherseite her herleiten“, statt zu bluffen.

Wenn Sie eine kompetente Backend- oder Anwendungsentwicklerin sind und eine NVIDIA-Ausschreibung ansehen mit dem Gedanken, sich nicht bewerben zu können, weil Sie nie einen Kernel geschrieben haben: Die Lücke ist kleiner, als sie aussieht, und sie ist eine Lese-, keine Erfahrungslücke. Sechs Monate GPU-Arbeit hätten mir geholfen. Vier Wochen Speicherhierarchie, C++-Semantik und ein sehr gut verstandenes Konzept namens Coalescing haben in meinem Fall gereicht.

Häufige Fragen

Brauche ich CUDA-Erfahrung, um ein Software-Engineer-Interview bei NVIDIA zu bestehen?

Für die systemnahe Stelle, auf die ich mich beworben habe: nein – aber man muss laut über parallele Hardware nachdenken können. Niemand wollte, dass ich einen produktionsreifen Kernel aus dem Kopf schreibe. Gefragt wurde, was mit dem Speicherverkehr passiert, wenn benachbarte Threads nicht benachbarte Adressen lesen, und ob mein Problem rechen- oder bandbreitenlimitiert ist. Das lässt sich in Wochen lernen, zehn Jahre GPU-Praxis nicht.

Wie unterscheidet sich der NVIDIA-Prozess von einer klassischen FAANG-Loop?

Die Algorithmen- und Datenstrukturrunden fühlten sich an wie überall im Big Tech. Der Unterschied liegt in der zweiten Hälfte jeder Frage. Bei Meta oder Google bedeutet „mach das schneller“ meist eine bessere Datenstruktur. Bei NVIDIA meint es häufig die Maschine: Cache Lines, Speicherhierarchie, False Sharing, Warp-Divergenz, Durchsatz gegen Latenz. Gleiche Frage, andere gemeinte Optimierungsachse.

Laufen die Interviews auf Deutsch, wenn ich mich aus Deutschland bewerbe?

Bei mir begann das Recruiter-Gespräch auf Deutsch und wechselte spätestens beim Fachlichen ins Englische; alle technischen Runden fanden auf Englisch mit Interviewern aus mehreren Ländern statt. Das ist bei hardwarenahen Rollen in deutschen Standorten US-amerikanischer Konzerne der Normalfall. Üben Sie, eine Speicherhierarchie auf Englisch laut zu erklären – das ist etwas anderes, als sie auf Deutsch verstanden zu haben.

Was sollte ich lernen, wenn ich aus der Backend- oder Anwendungsentwicklung komme?

Drei Dinge in dieser Reihenfolge. Erstens C/C++-Semantik: Zeiger, Objektlebensdauer, Ownership, RAII, Move gegen Copy. Zweitens das Verhalten der Speicherhierarchie: Cache Lines, Lokalität, Coalescing und warum dieselbe Schleife mit vertauschten Indizes zehnmal langsamer ist. Drittens das GPU-Ausführungsmodell: Warps, Occupancy, Shared Memory, Kosten der Host-Device-Transfers. Das sind einige Wochen fokussiertes Lesen, kein Berufswechsel.

Wie lange dauerte der Prozess, und was ist mit der Kündigungsfrist?

In meinem Fall rund sieben Wochen vom Recruiter-Call bis zur mündlichen Zusage, mit zwei terminbedingt leeren Wochen dazwischen. Dazu kommt die Kündigungsfrist: bei mir drei Monate zum Quartalsende, was in deutschen Verträgen für erfahrene Entwickler verbreitet ist. Rechnen Sie realistisch mit vier bis sechs Monaten bis zum tatsächlichen Start und nennen Sie die Frist im ersten Gespräch, nicht am Ende.

Lohnt es sich, ein NVIDIA-Angebot in Deutschland zu verhandeln?

Das Gespräch war sachlich und professionell, und Nachfragen hat keinerlei Spannung erzeugt. Ich hatte kein Konkurrenzangebot und habe deshalb über Level und Teamzuschnitt verhandelt statt über die Schlagzeilenzahl, und ich habe nach dem Rhythmus der Aktien-Refreshes gefragt – ein Baustein, den deutsche Arbeitgeber außerhalb US-Töchter selten bieten. Was sich bewegt, hängt von Level, Standort und Stelle ab; aus einem Fall lässt sich keine Regel ableiten.