Zwischen Python, SQL und „Zombie Tasks“: Aino arbeitet seit Juli 2025 als Junior Software Ingenieurin Business Intelligence im Team der Lösungsfinder. Doch was macht man in diesem Job eigentlich genau? Und wie ist es, Lösungsfinderin zu sein? Im Interview gibt sie Einblicke in ihren Arbeitstag, ihren Start bei der FI-SP und das, was ihren Job besonders für sie macht.

Hallo Aino! Wie bist du auf das Team der Lösungsfinder aufmerksam geworden und zu uns gekommen?

Nach meinem Informatikstudium an der TU Darmstadt bin ich über meinen Freund auf die FI-Gruppe aufmerksam geworden. Er hatte kurz vor mir seinen Master abgeschlossen und bei der Finanz Informatik (FI) angefangen. Dadurch habe ich mich selbst gezielt bei der FI und der FI-SP umgeschaut und bin schließlich bei der FI-SP auf zwei interessante Junior-Stellen gestoßen: Java-Entwicklerin und Data Engineerin. Die Rolle als Data Engineerin hat mich direkt angesprochen. Die versprach einen abwechslungsreichen Arbeitsalltag, was ich sehr mag. Der Bewerbungsprozess lief schnell und unkompliziert. Gleich nach dem ersten Gespräch hatte ich ein gutes Gefühl. Heute bin ich im Bereich EIM (Enterprise Information Management) eingesetzt und arbeite im Projekt „Kundenreise Datenbestand“, kurz KRDB.

Wie hast du deinen Einstieg bei der FI-SP erlebt? Wie wurdest du von deinem Team unterstützt?

Der Einstieg war am Anfang ehrlich gesagt ziemlich überwältigend. Es gab viele neue Informationen, und ich musste mich erst einmal in viele Themen einfinden. Gleichzeitig habe ich mich aber sehr gut aufgehoben gefühlt. Fast zeitgleich sind noch weitere Junior-Kolleginnen und -Kollegen gestartet, und es war schön zu sehen, wie viel Unterstützung sie von den erfahrenen Teammitgliedern bekommen haben. Niemand von den Erfahrenen war genervt, wenn Fragen kamen, im Gegenteil: Die Kolleginnen und Kollegen haben sich wirklich Zeit genommen. 

Was hat dir den Einstieg erleichtert?

Vor allem der Austausch mit den anderen Berufseinsteigerinnen und Berufseinsteigern. Wir konnten gemeinsam Aufgaben bearbeiten, Fragen stellen und uns gegenseitig unterstützen. Auch das Team hat es mir leicht gemacht: Alle sind offen und hilfsbereit. Ich bin eher introvertiert – trotzdem komme ich richtig gern ins Büro, weil wir dort gemeinsam arbeiten, viel voneinander mitbekommen und schnell als Team zusammengewachsen sind.

Was können wir uns unter deinem Job als Junior Software Ingenieurin bzw. als Junior Data Engineerin im Bereich Business Intelligence vorstellen? Welche Aufgaben hast du und wie sieht ein typischer Arbeitstag aus?

Mein Job ist sehr vielseitig. Aktuell bin ich viel im Application Management unterwegs. Das heißt, montags schaue ich immer erst einmal, ob bei unseren Programmen über das Wochenende Themen aufgetreten sind, um die ich mich als Erstes kümmern muss. Darüber hinaus arbeite ich an unterschiedlichen Aufgaben rund um Datenbanken, Kennzahlen und SQL. Zu Beginn ging es zum Beispiel viel darum, SQL-Abfragen von einem Dialekt in einen anderen zu übersetzen. Außerdem war ich an einer Automatisierung beteiligt, mit der Datenbankobjekte wie Tabellen und Views einfacher angelegt werden können. Ich teste Code, schreibe Tests und übernehme inzwischen auch längerfristige Aufgaben. Gerade diese Mischung gefällt mir: Mal geht es um Fehleranalyse, mal um Entwicklung, mal darum, bestehendes Wissen im Team weiterzugeben. 

Nach etwa sechs Monaten wurde ich gefragt, welche Art von Aufgaben ich künftig übernehmen möchte. Meine Präferenzen wurden berücksichtigt.

Mit welchen Technologien und Programmiersprachen arbeitest du in deinem Job?

Ich arbeite hauptsächlich mit Python. Das kam mir sehr entgegen, weil ich damit schon vorher gerne programmiert habe. In meinem Job geht es aber nicht nur ums Programmieren selbst, sondern auch darum, Daten aus verschiedenen Systemen zusammenzuführen und nutzbar zu machen. Dafür arbeiten wir mit vielen unterschiedlichen SQL-Dialekten, weil die Daten aus verschiedenen Datenbanken kommen.

Du hast vom Projekt KRDB gesprochen. Was macht ihr in dem Projekt, was macht es besonders?

Im Projekt Kundenreise Datenbestand – kurz KRDB – führen wir vorhandene Daten aus den Sparkassen an einem zentralen Ort zusammen und machen sie für alle teilnehmenden Sparkassen nutzbar. Welche Daten berücksichtigt werden, entscheiden die Sparkassen selbst. Die Daten werden pseudonymisiert und anonymisiert, damit sie sicher verarbeitet werden können. So entsteht eine gemeinsame Datenbasis, auf deren Grundlage übergreifende Auswertungen beauftragt werden können, zum Beispiel zum Nutzungsverhalten bestimmter Kundengruppen. Da die Systeme ausschließlich in der Infrastruktur des Digitalisierungspartners der Sparkassen, der FI, laufen, haben wir deren Sicherheitsrichtlinien zu beachten. Wir können beispielsweise nicht überall direkt zugreifen. Das ist manchmal herausfordernd, macht die Arbeit aber auch besonders.

Wie würdest du die Zusammenarbeit in deinem Team beschreiben? Was macht euren Teamspirit aus?

Die Zusammenarbeit im Team ist offen und unkompliziert. Wir haben großzügige Homeoffice-Regelungen, aber an typischen Bürotagen wie Dienstag und Donnerstag sind viele vor Ort. Dann sitzen wir oft zusammen und gehen zum Beispiel auch gemeinsam in die Kantine.

Im Frühling hat unser Bereich ein After Work organisiert, neulich waren wir als Projektteam gemeinsam essen, und im letzten Herbst haben wir zusammen gegrillt. Solche Momente machen viel aus, weil man sich auch persönlich besser kennenlernt.

Und natürlich gehört auch unser Meme-Channel in Teams dazu. Dort werden witzige Bilder geteilt, und manchmal merkt man fast schon daran, wie stressig es gerade ist: Wenn weniger Memes kommen, ist wahrscheinlich viel los. Für mich macht genau das unseren Teamspirit aus: Wir unterstützen uns fachlich, verbringen gern Zeit miteinander und nehmen uns selbst nicht immer ganz so ernst.

Gab es einen Moment bei der FI-SP, auf den du stolz bist?

Ein Moment, auf den ich besonders stolz war, hatte mit einem Code-Test zu tun. Eigentlich sollte der Code nur Anweisungen aus einer Tabelle lesen, alte Daten löschen und neue einfügen. Nach außen sah es aber so aus, als hätte er gar keine Anweisungen gefunden. Gleichzeitig wurden neue Daten eingefügt, während die alten stehenblieben. Das war erst einmal ziemlich verwirrend.

Am Ende waren es mehrere Kleinigkeiten, die ungünstig zusammenspielten: eine leere Anweisung, eine überholte Debug-Meldung und alte Testdaten mit anderer Groß- und Kleinschreibung. Da hätte ich mich leicht auf eine falsche Spur bringen lassen können. Stattdessen habe ich die Ursache relativ schnell gefunden. Das war ein schöner Moment, weil ich gemerkt habe, dass ich technische Probleme inzwischen gut durchdringen und systematisch lösen kann.

Gab es auch eine Situation, die dir besonders in Erinnerung geblieben ist?

Ja, eine ziemlich skurrile Situation hatten wir im Application Management. Unsere Programme laufen am Wochenende, und montags prüfen wir, ob alles richtig durchgelaufen ist. Bei einer Pilotierung geriet ein Programm durch einen Fehler in eine Art Endlosschleife. Wir wollten deshalb bestimmte Aufgaben aus der Warteschlange beenden. Nur: Sie kamen immer wieder zurück. Kurz waren sie weg, eine Minute später standen sie wieder da.

Später haben wir erfahren, dass dahinter ein interner Status steckte, den wir noch nicht kannten. Wenn Aufgaben schon wirklich bereit zur Ausführung sind, lassen sie sich nicht mehr einfach beenden. Das haben wir dann „Zombie Task“ genannt, weil die Aufgaben trotz Beendigung immer wieder „auferstanden“ sind.