Zwei deutsche Informatiker über ihre Arbeit in den USA und in der Cloud

Thomas Fanghänel ist als Principal Member of Technical Staff bei Salesforce.com in San Francisco, Kalifornien, tätig. Sein beruflicher Schwerpunkt dort sind Datenbanksysteme für Cloud-Anwendungen. Salesforce.com ist ein weltweit führender Anbieter von CRM-Software (Customer Relationship Management) als Cloud-Lösung, also in Form von Software as a Service (SaaS) im Internet. Fanghänel studierte ab 1997 Informatik mit einem Schwerpunkt in Datenbanken an der Friedrich-Schiller-Universität Jena. Während des Studiums war er ein Jahr in den USA als Praktikant am IBM Silicon Valley Lab in San Jose, Kalifornien, wo auch seine Diplomarbeit zum Teil entstand. Nach dem Studienabschluss 2003 trug Fanghänel, noch von Jena aus, zur Datenbanksprachnormung (SQL-Standard) bei und es folgten für ihn dann neun Jahre in der Datenbankentwicklung bei IBM (San Jose, Peking). Schwerpunkte waren dabei u.a. die Entwicklung von Datenbanksystemen für mobile Endgeräte, die Speicherung und Indizierung von XML-Daten sowie Datenkomprimierung. Seit dem Wechsel zu Salesforce.com 2012 beschäftigt sich Fanghänel vorwiegend mit den Themen Cloud und Multi Tenancy (Mehrmandantenfähigkeit) von der Datenhaltungsseite.

Wolfgang Krause ist seit 2012 ebenfalls bei Salesforce.com in San Francisco tätig. Er wurde als Performance Engineer eingestellt und leitet seit 2014 eines der Performance Testing Teams. Wolfgang Krause studierte ab 2002 Informatik an der Friedrich-Schiller-Universität Jena. Während des Studiums absolvierte er nach dem Vordiplom knapp drei Praxisjahre bei IBM: in Böblingen, in San Jose und in Toronto. Seine Diplomarbeit lief in diesem Kontext und Zeitrahmen ebenfalls in gemeinsamer Betreuung mit IBM. All diese Aktivitäten waren fachlich dem Datenbankbereich zugeordnet. Mit Diplomabschluss ging Krause 2010 zum Unternehmen MarkLogic in San Francisco, einem XML-Datenhaltungsspezialisten. 2012 wechselte er dann zu Salesforce.com ins Performance Engineering („Perfeng“). Krause ist nebenher privat seit Jahren auch aktiver Blogger unter wolfys-life.blogspot.com. 

Klaus Küspert (KK): Herr Fanghänel, Herr Krause, um mit einem Lieblingsthema von mir zu beginnen: Sie hatten beide jeweils schon während des Studiums, wie man sieht, sehr viel Praxiserfahrung mit „eingebaut": Ein Jahr bzw. sogar beinahe drei Jahre, davon das meiste in Nordamerika. Wie sehen Sie's aus heutiger Sicht zeitlich und inhaltlich: „Goldrichtig", zu viel, zu wenig? Was würden Sie heute diesbezüglich vielleicht anders machen oder sehen eventuell Dinge anders? Das interessiert sicher auch heutige Studierende und Vertreter der Praxis.

Thomas Fanghänel (TF): Ich bin nach wie vor der Meinung, dass mein Jahr 2000/01 bei IBM in San Jose zeitlich genau richtig war.  Wenn man im Studium eine Auszeit nimmt, dann geht das ja quasi nur „granular”, d.h. semesterweise.  Ein halbjähriges Praktikum wäre u.U. auch möglich gewesen, aber im Nachhinein kommt es mir so vor, dass besonders die zweite Hälfte meines Praktikums fachlich den größten Wert hatte.  Anfangs muss man sich erst einmal an die neue Umgebung, die Sprache und kulturelle Rahmenbedingungen gewöhnen.

Ehe man sich vollkommen eingelebt hat, dauert es deshalb schon einige Zeit.  Und auch im Team braucht es eine gewisse Eingewöhnungsphase und einiges an Beharrlichkeit, ehe man als Praktikant inhaltlich interessante Arbeit verrichten kann. IBM legte deshalb, zumindest damals, Wert darauf, dass solch Auslandspraktikum möglichst neun, besser zwölf Monate dauert. Das sieht man wahrscheinlich heute noch genau so.

Wolfgang Krause (WK): Bei mir waren es in der Summe 35 Monate. Das war natürlich schon etwas außergewöhnlich, von den Kommilitonen machte keiner derart viele Praktika. Erst ein bisschen in Böblingen (sieben Monate), zeitlich unmittelbar danach ein Jahr nach Kalifornien und schließlich 16 Monate (d.h. zwei  Winter!) in Toronto, Kanada, wo auch meine Diplomarbeit in jener Zeitperiode lief. Inhaltlich war „Praktikant sein” wie Vollzeitangestellter: ernsthafte Projekte und Arbeit mit verschiedenen Teams. Nur die Bezahlung war etwas geringer, aber gut nebenher auch für jede Menge Spaß und Reisen in den jeweiligen Gegenden. Die Zeit in Nordamerika war so gut, dass die GreenCard, die ich dann in der GreenCard Lottery gewann, wie gelegen kam, um als richtiger Vollzeitangestellter zurück in die San Francisco Bay Area zu gehen bzw. dort dann zu bleiben.

KK: Bei diesen Nordamerika-Aufenthalten (San Jose, Toronto): Wie „erklärungsbedürftig" war ggf. Ihr Diplomstudium bzw. nachher Ihr Diplom (wegen der anderen akademischen Grade dort)? Ich vermute, bei IBM in San Jose waren und sind die deutschen „Diplomer" recht bekannt durch ihre hohe Anzahl vor Ort, so dass nicht viel erklärungsbedürftig war und ist. Oder haben Sie ohnehin das Diplom dann begrifflich einfach in den Master „übersetzt", was man ja recht guten Gewissens tun konnte und kann?

WK: Als Praktikant in den USA hatte ich die Erfahrung gemacht, dass wenn HR (Human Resources, also die Personalabteilung) nach „University Credits” fragt, man denen lieber irgendeine Zahl gibt als versucht zu erklären, dass es so etwas in Deutschland nicht gibt (wie es ja zu meinen Diplomzeiten der Fall war). Wenn deren Formular nach Credit Points fragt, muss da nachher eine Zahl drin stehen, damit sie das Gehalt ausrechnen können: „Gibt’s nicht” oder „not applicable“ passt dort einfach nicht rein. Von dem Moment an war für mich begrifflich Diplom = Master und man lebt „near Berlin”, und wenn man komische Blicke bekommt, dann doch eben „near Frankfurt”. Für einige US-Amerikaner ist „near Kaiserslautern“ auch hilfreich, aber das ist zumindest in meinem Fall dann doch geographisch etwas daneben. Nach dem ersten, erfolgreichen Job freilich ist die zeitlich zurückliegende akademische Ausbildung ohnehin nur mehr ein superkleines Thema, das interessiert dann kaum noch einen. Ich denke, ähnlich zu jenem letzten Punkt wird es auch in Deutschland sein.

TF: Dem kann ich nur zustimmen.  Das Diplom als akademischer Grad war komplett unbekannt, und es gab schon die ein oder andere Hürde zu nehmen, auch in IBM, damit das auch wirklich als Master gewertet wurde.  Am schwierigsten was das ganze eigentlich während des Praktikums.  Das fing damit an, dass Master-Studenten ja i.d.R. schon einen Bachelor als vollwertigen akademischen Abschluss haben.  Einer Personalabteilung in den USA, selbst bei einem „wohlgesonnenen“ Unternehmen, zu erklären, dass man, wenn man ein paar Augen zudrückt, das Vordiplom als mit einem Bachelor vergleichbar einstufen kann, ist nicht gerade einfach.  Es ist aber wichtig, weil man nach vier vollen Universitätsjahren trotz noch fehlenden Abschlusses ja im Praktikum nicht in eine Kategorie mit Studienanfängern fallen möchte. Das hat auch finanziell Bedeutung und für den späteren, weiteren Karriereweg, damit die Zeit auch adäquat angerechnet wird.

Nach dem eigentlichen Uni-Abschluss gestaltet sich die ganze Anerkennung etwas einfacher.  Für das im Fall einer beabsichtigten Festanstellung in den USA notwendige Arbeitsvisum benötigt man eine individuelle Evaluierung des akademischen Abschlusses. Seit diesem Zeitpunkt besitze ich ein beglaubigtes, unterschriebenes und offiziell abgestempeltes Dokument, das die Gleichwertigkeit meines deutschen Diploms aus Jena mit einem amerikanischen M.Sc. bestätigt – „mission accomplished“ sozusagen.

Im Hinblick auf Arbeit und Praktikum im Ausland ist es also sicherlich begrüßenswert, dass sich das deutsche Hochschulsystem in den vergangenen Jahren mehr und mehr an den international gebräuchlichen akademischen Graden und Ausbildungszyklen orientiert. Inhaltlich kamen Diplomabsolventen früher durchaus als gut ausgebildet „an“ und wurden geschätzt, aber zumindest einordnungs- und HR-mäßig waren die genannten Probleme eben vorhanden.

KK: Herr Fanghänel, Sie haben Mitte der 2000er den Produkttransfer des „mobilen DB2", d.h. des IBM Datenbankprodukts DB2 Everyplace, vom Labor in San Jose ins Peking-Labor der IBM mit durchgeführt. Sagen Sie uns etwas zu jenem Aufenthalt im chinesischen Labor der IBM? Meines Wissens stand ja für Sie ein Bleiben bei IBM in China firmenseitig zur Diskussion, aber Sie entschieden sich doch für eine Rückkehr nach Kalifornien (wieder zurück ins IBM Silicon Valley Lab also).

TF: Obwohl ich damals schon ein paar Jahre lang mitten im Arbeitsleben stand, hatte das knappe Jahr, das ich in Peking verbracht habe, viele Parallelen zu meinem Praktikum in den USA. Man kommt in ein unbekanntes Land und muss sich an andere Bräuche und Gepflogenheiten gewöhnen und anpassen.  Erschwerend kommt auch noch hinzu, dass man sich in jenem Teil der Welt als vollkommener Analphabet fühlt und auch für verbale Kommunikation häufig kein kleinster gemeinsamer Nenner vorhanden ist.  Auch die kulturellen Unterschiede am Arbeitsplatz sind schon sehr eklatant.  In China sind nach meinen Erfahrungen die Strukturen sehr viel hierarchischer als ich das vom Silicon Valley her kannte – obwohl es das gleiche Unternehmen, IBM, war.

Trotz diverser Herausforderungen im täglichen Leben habe ich die Zeit in China sehr genossen. Beruflich konnte ich mein Netzwerk sehr erweitern und persönlich habe ich enorm viel gelernt.  Dennoch stand für mich eine Rückkehr nach Kalifornien nie in Frage.  Das Silicon Valley ist zu sehr das Epizentrum der Computerindustrie.  Glauben Sie mir, als Informatiker fällt die „endgültige“ Entscheidung zwischen Peking und San Francisco, wenn sie einem denn abverlangt wird, nicht besonders schwer – außer natürlich, man ist gebürtiger Chinese oder hat solche Wurzeln.

KK: Herr Krause, Sie waren nach dem Diplom 2010 in den USA in Bewerbungsprozessen u.a. bei „Promis“ wie Google, Microsoft, MarkLogic und anderen. Es sind ja teils recht aufwändige und vor allem zeitaufwändige Bewerbungsprozesse dort: für den Bewerber und für die Firma. Schildern Sie uns mal ein paar Aspekte hiervon? In Deutschland ist das ja nach wie vor doch meist „leichtgewichtiger" prozesstechnisch, selbst bei den großen Playern wie SAP, IBM etwa.

WK: Ich dachte immer, in Deutschland sind solche Dinge komplizierter? D.h. man muss oft Assessment Centers mit den Personal- und Fachabteilungen machen? Ich habe mich ja nie in Deutschland für einen Job beworben. Hier in den USA bewirbt man sich, kennt jemanden oder wird gefunden. Das mag ähnlich wie in Deutschland sein. Danach folgen meist mehrere Telefoninterviews und, wenn die gut laufen, dann vier bis sechs oder mehr Interviews an einem Tag vor Ort beim Unternehmen. Große Unternehmen, wie Microsoft, mit Zehntausenden und mehr Bewerbern jährlich, haben dafür hier in den USA ein sehr ausgefeiltes Verfahren, um das alles prozesstechnisch abwickeln zu können. Ich kann mir vorstellen, dass es bei SAP in Deutschland beispielsweise auch erforderlich ist und nicht ganz anders abläuft.

Jetzt, seitdem ich für mein eigenes Team einstelle, sieht man die Dinge noch von einer ganz anderen Seite: „Hiring is complicated“. Denn man will die Stelle ja am besten morgen besetzen, hat nur einen sehr kleinen Pool an guten Bewerbern und weiß nie, ob man jetzt die Person xyz einstellt oder lieber noch zwei Wochen wartet, bis sich jemand Neues bewirbt. Lebensläufe lesen macht man aus Aufwandsgründen in weniger als zwei Minuten. Telefoninterviews sind mehr beidseitiges „Vorstellen” und ein paar technische Fragen. Nach sechs telefonisch vorselektierten Interview-Partnern (Bewerbern) nun vor Ort hat man vielleicht drei davon mit Ergebnis „super, einstellen” und drei mit „nein, nicht qualifiziert”.

Im Allgemeinen sehe ich die Prozesse hier von Bewerberseite als „man trifft das Team”, stellt fest, ob man in der Firma arbeiten möchte und ob man genug Kenntnisse und Motivation hat, den Job zu bekommen. Wie gesagt, ich sehe, dass es diesbezüglich in deutschen und US-amerikanischen Bewerbungsprozessen gar nicht so unterschiedlich abläuft.

KK: Herr Fanghänel, Sie hatten ja, die Praktikumszeit mitgezählt, zehn IBM Jahre (San Jose, Peking), als Sie das Unternehmen verließen und zu Salesforce.com wechselten. Was waren die Gründe, warum geht „man" nach zehn Jahren von IBM weg (ich meine jetzt nicht einen Weggang etwa an die Uni.)?

TF: In der heutigen Zeit und in den hiesigen geografischen Breiten im Silicon Valley gilt man schon als Inventar, wenn man zehn Jahre bei ein und demselben Unternehmen tätig ist.  Insofern könnte man die Frage auch anders stellen:  Wieso ein Wechsel nicht schon viel früher?

Die schiere Größe eines Unternehmens wie IBM gestattet es, dass man über die Zeit an Projekten mit den unterschiedlichsten Schwerpunkten arbeiten kann.  Obwohl ich den Bereich Datenbankentwicklung eigentlich nie verlassen habe, konnte ich eine große technologische Bandbreite abdecken.  Genannt seien hier nur die Erfahrungen mit mobilen Endgeräten, Verschlüsselung, Komprimierung und Hardware-Software-Codesign.  Man kann sich also durchaus vorstellen, dass man es recht lange bei IBM aushalten kann, ohne dass es fachlich öde wird. Aber Interesse an der Abwechslung, auch mal einen anderen Arbeitgeber „auszuprobieren“, war dann bei mir gegeben, wie man sieht.

KK: Herr Krause, nennen Sie uns ein paar „Besonderheiten" des Arbeitens bei Salesforce.com? Bzw. vielleicht ist ja manches davon sogar unternehmensübergreifend typisch in vergleichbaren Unternehmen in der Region San Francisco und dem Silicon Valley. Man hört ja etwa aus Unternehmen wie Google von einer sehr weitgehenden Betreuung der Mitarbeiter und „Firmenfürsorge", inkl. der Wäscherei und anderer privater Dienstleistungsangebote im Unternehmen. Kennen Sie das auch so aus eigener momentaner Tätigkeit?

WK: Also die Salesforce-Firmenkultur „erlaubt” auch ein Leben außerhalb der Arbeit. Hier gibt es keine vierundzwanzigstündige Betreuung. Niemand bringt seine schmutzige Wäsche mit zur Arbeit – auch nicht im übertragenen Sinn des Wortes – und niemand soll hier 24 Stunden am Tag verbringen. Deshalb gibt’s wohl auch kein Frühstück, Mittagessen und Abendessen. Andere Firmen hier im Valley haben in der Tat solche Dinge, wo es dann Abendessen ab 19:30 Uhr gibt und anschließend geht’s munter und stets agil weiter im Büro. Teams bei Salesforce.com arbeiten hart, aber trotzdem gibt’s mehr als nur Arbeit. Das ist mir auch wichtig, etwa aufgrund meiner ausgeprägten privaten Reiselust und -leidenschaft.

KK: Herr Fanghänel, da wir ja laut Überschrift über das „Leben in der Cloud" reden wollen, auch an Sie entsprechend zum heutigen Arbeitgeber: Ein wesentlicher Unterschied im Arbeiten dürfte ja auch darin liegen, dass Sie jetzt in einem relativ jungen und stark wachsenden Unternehmen tätig sind. Das Vorherige bei Ihnen (IBM) zog und zieht hingegen als großes Schlachtschiff schon lange seine Bahnen, mitarbeitermäßig scheint dort eher Konsolidierung angesagt als Wachstum. Äußern sich solche Unternehmensunterschiede auch direkt im Tagesgeschäft für die Mitarbeiter?

TF: Natürlich gibt es große Unterschiede zwischen ehemaligem und derzeitigem Arbeitgeber, die sich direkt aufs Tagesgeschäft auswirken.  Die Entwicklungsprozesse für Software unterscheiden sich signifikant, hauptsächlich bedingt durch die Unterschiede zwischen Cloud- und Lizenz-Modell.  Die Entwicklungszyklen für Cloud-Software sind kurz und genau definiert.  Bei IBM konnten klassischerweise durchaus ein bis zwei Jahre zwischen dem Ende eines Projekts in der Entwicklung und der Markteinführung des fertigen Produktes vergehen.  Für Cloud-Software rechnet man da schon eher in Monaten oder gar Wochen.

Auch in der Unternehmenskultur gibt es signifikante Unterschiede.  Bei Salesforce.com wird Transparenz sehr groß geschrieben.  Kommunikation findet weniger per E-Mail statt und mehr in internen Foren, die für jedermann einsehbar sind.  Das mag für den Außenstehenden nicht besonders revolutionär klingen, hat aber einen enormen Einfluss auf Arbeitsklima und interpersonelles Miteinander.

KK: Herr Krause, Salesforce.com scheint ein Unternehmen zu sein, das den Mitarbeitern auch viele Freiräume gewährt hinsichtlich der Wahl ihres Arbeitsorts und der Arbeitszeiten. Sehe ich das in etwa richtig so? Und Sie haben ja als Teamleiter nun seit einiger Zeit dort Personalverantwortung: Bedeutet das somit für Sie dann doch mehr erforderliche Präsenz am Bürostandort oder bleibt das Arbeiten weiter auch „flexibel in der Cloud"?

WK: Im Großen und Ganzen gilt natürlich: Wenn Mitarbeiter „happy“ sind, sind sie produktiver und bleiben länger bei der Firma. Der Jobmarkt ist ja so gut hier im Valley, dass fast jeder im nächsten Monat einen neuen Job haben kann bei Interesse am Wechsel. Und die Firma arbeitet hart daran, den „Best company to work for”-Status zu behalten. Letztes Jahr waren wir auf Platz 7 in jener Liste der „FORTUNE’s 100 Best Companies to Work For“ – nicht schlecht also.

Zum Thema Arbeitsflexibilität: Donnerstag ist „no meeting Thursday”, welchen fast alle nutzen, um von zu Hause zu arbeiten. Je nach Arbeitsweg arbeiten mache mehr und andere weniger an den anderen Tagen von zu Hause aus. Wenige sind 100% im Home Office. 

Als Teamleiter hat man so viele Meetings, da komme ich lieber ins Büro. Die Kommunikation ist besser and der direkte Kontakt macht einfach mehr Spaß. Klar, wenn ich alle zwei Wochen von meiner Freundin in New York aus arbeite oder meine Eltern und Freunde in Deutschland besuche, dann geht das „working from home” schon. Vollzeit fern des Büros, das geht in meiner Rolle als Teamleiter natürlich nicht mehr. Wenn persönliche Gründe das Vollzeit-Home-Office eine Zeit lang erfordern, dann sind solche Dinge in Absprache möglich. Aber es ist eben nicht die Regel. So hat z.B. Thomas Fanghänel mehr als ein Jahr von Boston aus gearbeitet und ist regelmäßig in San Francisco vorbeigekommen. Solche Dinge belasten dann das Team-Budget mit vielen „Reisekostendollars“ pro Besuch, aber dies ist alles besser, als einen neuen Thomas Fanghänel zu finden. Man geht deshalb mit all den Dingen bei uns im Unternehmen pragmatisch um, wahrscheinlich pragmatischer als in Deutschland, wo etwa Betriebsräte und andere mit entscheiden – was oftmals hilfreich sein mag, aber sicher nicht immer – und Arbeitszeitregelungen auch genauere Rahmenbedingungen vorgeben meines Wissens, mehr als das in den USA der Fall ist.

KK: Herr Krause, ich möchte an die Erörterung Ihrer jetzigen Tätigkeit direkt noch mal kurz anknüpfen, nachgefragt also: Was macht ein Performance Testing Team bei Salesforce.com „genau“? Wie grenzen sich verschiedene Performance Testing Teams inhaltlich ab? Bzw. wo liegen etwa die Unterschiede im Performance Testing für klassische, nicht cloudbasierte Anwendungen zu jenem Testing von Cloud-Angeboten? Das mag sich ja durchaus in manchem unterscheiden.

WK: Performance wird bei uns natürlich „per Cloud” getestet. So wie man sich das von einer Cloud Company vorstellt. Sales Cloud, Service Cloud, Chatter Cloud ... sind hier vorliegende Unterscheidungen und Abgrenzungen. Inhaltlich arbeiten die Performance Testing Teams mit ihren jeweiligen Development Teams eng zusammen. Arbeitet man mit einem Team, das Mobile/UI-basierende Funktionen, also Benutzerschnittstellenaspekte, testet, dann spezialisiert sich das Team auf Mobile & UI. Arbeiten die Teams eher an Database Access, dann verbringt man seine Zeit mit dem. Im Großen und Ganzen kann man die Arbeit und unsere Aufgaben so zusammenfassen:

(1)  Stelle sicher, dass jeder Kunde schnelle Antwortzeiten hat. Das ist recht spannend bei zwei Milliarden Transaktionen pro Tag.

(2)  Stelle sicher, dass Kunde A nicht die Ressourcen von Kunde B aufbraucht und Kunde B nichts von Kunde A merkt. Jeweils Tausende Anwender, also verschiedene Kunden („tenants“), teilen sich die gleiche physische Hardware und haben ihre Daten in den gleichen Tabellen, so dass Ressourcenverbrauch und Lastverteilung entscheidend sind. Kunden können alles mögliche anpassen, eigenen Java-Code ausführen und Geschäftslogik bei uns implementieren. D.h. Kunden können sehr kreativ sein und dürfen trotzdem andere nicht beeinflussen und ihre eigenen Antwortzeiten oder die anderer bewusst oder unbewusst verlangsamen. Da müssen wir also ständig ein Auge drauf haben und Performance-Probleme möglichst im Vorfeld verhindern.

KK: Zum Schluss unseres Interviews, Herr Fanghänel: Wenn Sie auf Ihr, nun gut zehn Jahre zurückliegendes, Studium blicken, was davon hat geholfen oder nicht geholfen im Berufsleben, was hätte die Universität Ihnen eventuell „anders“ angedeihen lassen sollen? Sagen Sie uns und mir also mal bitte die Meinung!!

TF: Alles in allem finde ich, dass ich an der Universität eine hervorragende Ausbildung genossen habe. Der Mix aus praxis- und theoriebezogenen Themen war wohl ziemlich genau richtig. Jedenfalls finde ich nichts daran auszusetzen.  Das einzige, was ich im Nachhinein sehe, das etwas zu kurz gekommen ist, hat mit einem praktischen Thema zu tun. In der Praxis verbringt man mehr Zeit damit, Code zu lesen, als welchen zu schreiben. Und das sowohl zum Zweck von Code Reviews, als auch manchmal aus Gründen fehlender oder lückenhafter Dokumentation.  In der Lage zu sein, effizient Programmcode zu studieren, Zusammenhänge zu erfassen und Korrektheit zu verifizieren ist eine in der Praxis unabdingbare Fähigkeit, die ich mir selbst über die ersten Berufsjahre mühsam erarbeiten musste und die in der Uni-Ausbildung zumindest zu meiner Zeit nur am Rande erwähnt wurde. Vielleicht ist es auch recht schwer lehrbar und muss teils in der Praxis „mit Hand am Arm“ erarbeitet werden. Im weitesten Sinne also all solches, was stark mit Software QA (Quality Assurance, Qualitätssicherung) zusammenhängt. Da könnte und sollte die Hochschulausbildung viel Wert drauf legen, denn es ist im Berufsleben essentiell natürlich.

KK: Herr Fanghänel. Herr Krause, herzlichen Dank für die informativen Antworten. Es sind bestimmt Aspekte darunter, die Praxis- und auch Hochschulvertreter interessieren werden und die studentischen Blog-Leser hoffentlich auch. Ihnen sei ein weiterhin so erfolgreicher Berufsweg in den USA gewünscht und vielleicht kommt ja auch mal wieder die berufliche Rückkehr nach „Old Europe“ in Betracht.