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.
Keine Kommentare:
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.