Recruiting, Teamkultur und Onboarding

08. Januar 2020

Unser Entwicklungsleiter Hannes Sachsenhofer wurde von devjobs.at in einer "TechLead-Story" zum Thema Recruiting, Teamkultur und Onboarding interviewt und hat dabei einige "interne" Details ausgeplaudert.

Team

Wie groß ist das Dev-Team? Wie setzt sich das Team, in Funktionen aufgeteilt, zusammen?

Wir sind ein kleines Startup mit wenigen Mitarbeitern, die Rollenverteilung ist da oft nicht so klar zu ziehen 😉

Unser Entwicklungsteam besteht derzeit aus fĂŒnf Personen inklusive mir, und wir werden noch von einem Kollegen im Bereich Regulatory unterstĂŒtzt. Alle Entwickler programmieren auch tatsĂ€chlich, machen zum Teil aber auch PM-Aufgaben, wie Abstimmung mit den Kunden.

Wie ist euer Dev-Team organisiert und aus welchem Grund habt ihr euch fĂŒr eine bestimmte Organisation entschieden? Worin liegen die Vorteile, wo die Nachteile?

Wir entwickeln neben unserem eigenen Produkt vor allem an individuellen Projekten fĂŒr unsere Kunden. Daher ist die Organisation immer auch auf den Kunden abgestimmt, zB haben wir mit bestimmten Kunden klassische Sprints, bei anderen gehen wir viel agiler vor.

Der Vorteil ist sicher, dass wir so gut auf die Strukturen beim Kunden eingehen können. Der Nachteil ist, dass wir so auf die Strukturen beim Kunden eingehen 😉

Was macht euer Team im Vergleich zu anderen Teams besonders?

Wir sind im Vergleich mit anderen Unternehmen – wohl auch geschuldet der UnternehmensgrĂ¶ĂŸe, aber auch, weil mir das persönlich sehr wichtig ist – sehr flexibel.

Ich weiß, das behaupten alle Unternehmen von sich, die FlexibilitĂ€t betrifft bei uns aber den gesamten Arbeitsalltag: Wir arbeiten Teil-Remote, auch mit unterschiedlichen Arbeitszeiten oder Freelancern, die ins Team integriert sind. Mir ist wichtig, dass sich jede Kollegin den Arbeitsalltag an die eigenen Vorlieben anpassen kann: Wenn eine Kollegin gerne direkt mit den Kunden spricht und Dinge abklĂ€rt – perfekt. Wenn eine Kollegin das nicht so gerne hat und lieber ausschließlich am Code arbeitet – auch kein Problem. Jeder soll ein Umfeld vorfinden oder schaffen können, in dem er oder sie gerne arbeitet.

Recruiting

Wie ist eure Dev-Abteilung in den Recruiting-Prozess integriert?

Wir sind ein Startup – die Dev-Abteilung MACHT das Recruiting 😉

Gibt es ein konkretes Prozedere fĂŒr neue Kollegen? Wie werden diese integriert?

Das hĂ€ngt stark davon ab, ob die neue Kollegin bereits mit unserem Tech-Stack und Tools vertraut sind, oder ob hier eine lĂ€ngere Einarbeitungsphase notwendig ist. Idealerweise sollte eine neue Kollegin so schnell wie möglich mit der Arbeit an einem konkreten Kundenprojekt starten. Denn ich halte nichts davon, jemanden mit „Willkommen, lies dir die ersten zwei Wochen mal unser Confluence durch, dann schauen wir weiter“ zu beschĂ€ftigen.

Neben der fachlichen Qualifikation, worauf legt ihr noch Wert, wenn ihr nach Entwicklern fĂŒr euer Team sucht?

Eine gewisse fachliche Qualifikation ist natĂŒrlich wichtig. Dabei ist fĂŒr mich weniger relevant, ob eine Kandidatin bereits Erfahrung mit unserem Tech-Stack hat, sondern vielmehr, dass Lernbereitschaft und Neugier auf Neues bestehen. Eine neue Programmiersprache lernt man innerhalb von Tagen oder Wochen – da macht es keinen Sinn, eine Entwicklerin von vornherein auszuschließen, nur weil sie zB bisher nur mit Java anstelle von C# gearbeitet hat. Ich bin deshalb auch kein Fan von „Programmiertests“ im BewerbungsgesprĂ€ch, sondern rede viel mehr ĂŒber allgemeine Konzepte oder Learnings aus frĂŒheren Projekten.

Sehr wichtig ist mir aber auch, dass die Chemie stimmt. Die Person muss einfach persönlich ins Team, zu unseren AblÀufen und zu unserer Art Projekte abzuwickeln passen.

Technologien

Welchen technischen Herausforderungen seht ihr Euch gegenĂŒber?

Eine Herausforderung in unserem medizinischen Umfeld, ist stets die Integration anderer Systeme. Manchmal muss man mit uralten Legacy-Systemen kommunizieren, wo man von REST oder gRPC nur trÀumen kann und recht behÀbige Kommunikationsprotokolle aus den 90ern einhalten muss.

Viel komplexer als die technischen Herausforderungen sind aber die Regulatorischen: Software als Medizinprodukt unterliegt im Prinzip denselben gesetzlichen Vorgaben wie medizinische Hardware, beispielsweise ein Herzschrittmacher oder ein RöntgengerĂ€t. Bei vielen Projekten ist also nicht die Technik die HĂŒrde, sondern die Einhaltung der strengen regulatorischen Vorgaben.

Mit welchen Technologien arbeitet ihr?

Wir machen primĂ€r Web-Anwendungen mit .NET Core. Das heißt natĂŒrlich Full Stack:

Datenbank/Storage, Backend mit C#, Frontend mit HTML, CSS oder JavaScript. Das klingt jetzt nicht wahnsinnig aufregend, aber je nach Projekt kommen dann immer wieder herausfordernde Anforderungen, wie zB Echtzeitsteuerung von LaborgerĂ€ten ĂŒber Websockets hinzu.

Der Betrieb erfolgt fast bei jedem Projekt ĂŒber Cloud-PaaS wie Azure. Tickets und CI/CD lĂ€uft ĂŒber Azure DevOps.

Manchmal bauen wir auch SPA-Anwendungen, zB Angular oder Vue.js, Smartphone-Apps, zB Ionic, oder Windows-Anwendungen, zB Winforms. Im Prinzip wÀhlen wir jene Technologie aus, die am Besten zu den Kundenanforderungen passt. Der Fokus liegt aber bei Web Anwendungen, da haben wir definitiv das meiste Know-How.

Wie hat sich die Technologie des Unternehmens seit der GrĂŒndung verĂ€ndert?

Bei unserer GrĂŒndung war .NET Core noch in der Beta-Phase. Wir sind damals schon auf den Zug aufgesprungen, was sich im Nachhinein als Fehler erwiesen hat, weil es bis zur fertigen Version 1.0 doch viele Änderungen gab, die unsere Migration erschwert haben.

Seitdem hat sich .NET Core extrem gut entwickelt – sowohl was die Plattform selbst, aber auch das Umfeld oder Ökosystem betrifft. Es wird gefĂŒhlt immer besser und schneller. Ich bin froh, dass unsere Entscheidung damals auf diese Plattform gefallen ist.

Wir setzen Cookies zur Bereitstellung der Website und zur Reichweitenmessung ein. Ohne Ihre Zustimmung verwenden wir keine nicht-essentiellen Cookies, Details finden Sie in der DatenschutzerklÀrung.